在 JSP / JSPX 中转义 HTML 实体：根本不应该存在的问题没有解决方案吗？
我们使用 jspx 作为模板引擎。我们有几十个屏幕，其中有数百个 el 表达式，例如 ${user.firstName} 或“${mail.subject}”
并且默认情况下不会转义所有这些 HTML 代码。如果有一些东西与<或“在字段中 - 屏幕将失败。我们总是可以使用 fn:escapeXml 但在所有地方这样做真的很无聊。1
) 有没有办法默认转义？
我知道的唯一方法是破解 JSP 编译器（例如 tomcat 的 jasper）。但这不是一条路。
2） 为什么有人可能需要在 el 中使用未转义的 HTML？在模板之外存储 HTML（例如在数据库中）并不是一个好的做法。
3) 我确信模板引擎应该自动处理它（就像在 XSLT 中所做的那样），为什么用户应该关心它？ 手动转义 (fn:escapeXml) 闻起来像 SQL 手动转义（用于代替 JDBC setParam）：样板代码和 sql 注入的好地方（在我们的例子中是跨站点脚本）。
We use jspx as template engine. We have dozen of screens with hundreds of el expressions like ${user.firstName} or "${mail.subject}"
And all this HTML code is not escaped by default. If there would be something with < or " in field -- screen will fail. We can always use fn:escapeXml but doing so in all places really boring.
1)
Does there is a way to do escape by default?
The only way I know is to hack JSP compiler (like jasper for tomcat). But it is not a way to go.
2)
Why somebody may ever need unescaped HTML in el? Storing HTML outside of template (in database for example) is not a good practice.
3) I am sure template engine should handle it automatically (as it done in XSLT), why should user care about it?
Manual escaping (fn:escapeXml) smells like SQL manual escaping (which is used instead of JDBC setParam): boilerplate code and good place for sql-injection (cross-site scripting in our case).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在老式的 JSP 中没有。然而，它的后继 Facelets 默认情况下会避开它们。禁用转义的唯一方法是使用
#{bean.foo}。存储 净化 HTML 的做法比通常做的要多。例如，允许一小部分无辜的 HTML 标记，例如
、、等on*属性已被删除。JSP 是一个古老的视图技术。它并不是一个真正灵活的模板引擎。
通常只需使用
PreparedStatement而不是Statement（或者使用 ORM 框架而不是“原始 JDBC”）来防止 SQL 注入，就像可以防止 XSS 问题一样只需使用 MVC 框架而不是“原始 JSP”）。至于您的具体问题，您基本上可以通过四种方式解决：
咬紧牙关并用
fn:escapeXml() 替换所有重新显示用户控制输入的 EL-in-template-text 或有某种数据库拦截器，可以在插入数据库之前删除恶意 HTML。如有必要，运行数据库脚本来清理现有数据。然而，这更像是一种解决方法，而不是真正的解决方案。
将 JSP EL 解析器替换为转义所有 HTML 的自定义解析器。然而，这有一个缺点，即您永远无法在真正需要时通过 EL 显示纯 HTML。
使用具有内置 HTML 转义功能的不错的 MVC 框架。然而，这比仅仅修复各个 EL 表达式要做更多的工作。
Not in the vintage JSP. Its successor Facelets, however, escapes them by default. The only way to disable escaping is to use
<h:outputText value="#{bean.foo}" escape="false" />instead of#{bean.foo}.Storing sanitized HTML is however more than commonly done. E.g. to allow a small subset of innocent HTML tags like
<p>,<b>,<i>and on from which theon*attributes are already stripped.JSP is an ancient view technology. It's not really a flexible template engine.
SQL injections are usually to be prevented by just using
PreparedStatementinstead ofStatement(or by using an ORM framework instead of "raw JDBC", like as your XSS issue can be prevented by just using a MVC framework instead of "raw JSP").As to your concrete problem, well, you can solve this in basically 4 ways:
Bite the bullet and replace all EL-in-template-text which redisplays user-controlled input by
fn:escapeXml()or<c:out>and teach yourself and your team to pay attention to this in the future. Hint, a bit decent IDE like Eclipse has a regex based find-and-replace-in-all-files.Have sort of DB interceptor which strips malicious HTML before inserting in DB. If necessary run a DB script to sanitize the existing data. This is however more a workaround than a real solution.
Replace the JSP EL resolver by a custom one which escapes all the HTML. This has however the disadvantage that you can never show plain HTML by EL whenever really needed.
Use a decent MVC framework with builtin HTML escaping. This is however more work than just fixing the individual EL expressions.
是的，默认情况下可以转义所有 EL 表达式。这可以通过注册自定义 ELResolver 来完成。例如，请参阅此站点以获取如何完成此操作的示例：http ://pukkaone.github.com/2011/01/03/jsp-cross-site-scripting-elresolver.html
Yes, it is possible to escape all EL-expressions by default. This can be done by registrating a custom ELResolver. See for instance this site for an example of how it can be done: http://pukkaone.github.com/2011/01/03/jsp-cross-site-scripting-elresolver.html