我已经浏览了OWASP的十大漏洞，发现跨站点脚本是我们必须记下的漏洞。推荐的解决方案很少。有人说，不要使用“黑名单”验证来检测输入中的XSS或编码输出。搜索和替换几个字符（以及其他类似的字符或短语，如）是很弱的，并且已被成功攻击。在某些情况下，即使是未经检查的标记也是不安全的。XSS具有数量惊人的变体，可以轻松绕过黑名单验证。另一种解决方案说，强输出编码。在呈现之前，请确保所有用户提供的数据都经过适当的实体编码（HTML 或 XML，具体取决于输出机制）。那么，防止跨站点脚本验证和替换输入或编码输出的最佳方法是什么？<>script“<b>”
通常的做法是在 JSP 中重新播放期间对任何用户控制的数据进行 HTML 转义，而不是在处理 servlet 中提交的数据期间或在 DB 中存储期间。在JSP中，您可以使用JSTL（要安装它，只需将jstl-1.2.jar放入）<c：out>标签或fn：escapeXml函数。例如：/WEB-INF/lib
<%@ 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请求传入的所有内容：请求参数，正文和标头（！！）。
如果您在处理提交的数据和/或存储在数据库中时对其进行了HTML转义，那么它都会分散在业务代码和/或数据库中。这只是维护问题，当您在不同的地方这样做时，您将面临双重逃逸或更多的风险（例如 将变成而不是最终用户从字面上看到而不是在视图中。业务代码和数据库反过来又对 XSS 不敏感。只有风景是。然后，您应该只在视图中逃离它。&&amp;&&&
同时使用两者。实际上，请参阅像OWASP XSS Prevention备忘单这样的指南，了解使用输出编码和输入验证的可能情况。
在某些情况下，当您不能依赖输出编码时，输入验证会有所帮助。例如，您最好验证出现在URL中的输入，而不是对URL本身进行编码（Apache不会提供URL编码的URL）。或者，验证出现在 JavaScript 表达式中的输入。
最终，一个简单的拇指规则将有所帮助 - 如果您不够信任用户输入，或者如果您怀疑某些来源尽管输出编码仍会导致XSS攻击，请根据白名单对其进行验证。
请查看 OWASP ESAPI 源代码，了解如何在安全库中编写输出编码器和输入验证程序。
