防止跨站脚本编写的 Java 最佳实践

Question

关闭。这个问题是 opinion-based .它目前不接受答案。

---

想要改进这个问题吗？ 更新问题，以便 editing this post 提供事实和引用来回答它.

关闭 7 年前。

Improve this question

我浏览了 OWASP 十大漏洞，发现跨站点脚本是我们必须记录的一个。几乎没有推荐的解决方案。有人说不要使用“黑名单”验证来检测输入中的 XSS 或编码输出。仅搜索和替换几个字符( < 和 > 以及其他类似字符或短语，例如 script )很弱并且已被成功攻击。即使是未经检查的 “<b>”标签在某些情况下是不安全的。 XSS 有数量惊人的变体，可以轻松绕过黑名单验证。另一种解决方案说强输出编码。确保所有用户提供的数据在呈现之前都经过适当的实体编码(HTML 或 XML，取决于输出机制)。那么，防止跨站脚本验证和替换输入或编码输出的最佳方法是什么？

Answer 1

通常的做法是在 JSP 中重新显示期间对任何用户控制数据进行 HTML 转义，而不是在 处理servlet 中提交的数据期间在数据库中存储期间也不行。在 JSP 中，您可以使用 JSTL (要安装它，只需将 jstl-1.2.jar 放入 /WEB-INF/lib 中) <c:out> 标签或 fn:escapeXml 为此发挥作用。例如

<%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>
...
<p>Welcome <c:out value="${user.name}" /></p>

和

<%@ taglib uri="http://java.sun.com/jsp/jstl/functions" prefix="fn" %>
...
<input name="username" value="${fn:escapeXml(param.username)}">

就是这样。不需要黑名单。请注意，用户控制的数据涵盖了由 HTTP 请求传入的所有内容:请求参数、正文和 header (!!)。

如果您在处理提交的数据和/或存储在数据库中的过程中对它进行 HTML 转义，那么它全部分布在业务代码和/或数据库中。这只是维护问题，当您在不同的地方执行此操作时，您将面临双重转义或更多的风险(例如，& 将变为 & 而不是 &，因此最终用户会真正看到 & 而不是 &在 View 中。业务代码和数据库反过来对 XSS 不敏感。只有 View 是。然后你应该只在 View 中就在那儿转义它。

另见:

• How does an XSS attack work? Video #1
• How does an XSS attack work? Video #2