我们使用jspx作为模板引擎。我们有数十个屏幕，包含数百个el表达式，如$ {user.firstName}或“$ {mail.subject}”
默认情况下，所有这些HTML代码都不会被转义。如果有＆lt;或“在现场 - 屏幕将失败。我们总是可以使用fn：escapeXml，但在所有地方这样做真的很无聊。
1） 默认情况下有没有办法逃脱？
我知道的唯一方法是破解JSP编译器（如tomcat的jasper）。但这不是一条路。
2） 为什么某人可能需要在el中使用未转义的HTML？在模板外部存储HTML（例如在数据库中）不是一个好习惯。
3）我确信模板引擎应该自动处理它（就像在XSLT中一样），用户为什么要关心它？ 手动转义（fn：escapeXml）闻起来像SQL手动转义（用于代替JDBC setParam）：样板代码和sql注入的好地方（在我们的例子中是跨站点脚本）。
答案 0 :(得分：11)
1）默认情况下有没有办法逃脱？
不在老式JSP中。然而，它的后继者Facelets在默认情况下逃脱了它们。禁用转义的唯一方法是使用<h:outputText value="#{bean.foo}" escape="false" />代替#{bean.foo}。
2）为什么某人可能需要在el中使用未转义的HTML？在模板外部存储HTML（例如在数据库中）不是一个好习惯。
存储sanitized HTML不仅仅是普遍的做法。例如。允许一小部分无辜的HTML标记，例如<p>，<b>，<i>以及on*属性已被删除。
JSP是一种古老的视图技术。它不是一个灵活的模板引擎。3）我确信模板引擎应该自动处理它（就像在XSLT中一样），用户为什么要关心它？手动转义（fn：escapeXml）闻起来像SQL手动转义（用于代替JDBC setParam）：样板代码和sql注入的好地方（在我们的例子中是跨站点脚本）。
通常只使用PreparedStatement代替Statement（或使用ORM框架而不是“原始JDBC”）来防止SQL注入，就像使用XSS问题可以通过使用来防止一个MVC框架而不是“原始JSP”）。
至于你的具体问题，你可以用4种方式解决这个问题：
咬住子弹并替换所有EL-in-template-text，重新显示用户控制的输入fn:escapeXml()或<c:out>，并教导您和您的团队注意这一点。未来。提示，像Eclipse这样有点不错的IDE有一个基于正则表达式的查找和替换所有文件。
有一些数据库拦截器在插入数据库之前剥离恶意HTML。如有必要，运行DB脚本以清理现有数据。然而，这是一种解决方法，而不是真正的解决方案。
用一个转义所有HTML的自定义转换器替换JSP EL解析器。然而，这样做的缺点是，无论何时真正需要，你都不能通过EL显示纯HTML。
使用内置HTML转义的体面MVC框架。然而，这不仅仅是修复单个EL表达式的工作。
答案 1 :(得分：7)
是的，默认情况下可以转义所有EL表达式。这可以通过注册自定义ELResolver来完成。例如，请参阅此网站以获取如何完成的示例：http://pukkaone.github.com/2011/01/03/jsp-cross-site-scripting-elresolver.html