我已经完成了OWASP十大漏洞,发现跨站点脚本是我们必须记笔记的.建议的解决方案很少.有人说不要使用"黑名单"验证来检测输入中的XSS或编码输出.搜索和替换只有几个字符(<以及>其他类似的字符或短语script)很弱,并且已成功攻击.即使是未经检查的“<b>”标签在某些情况下也是不安全的.XSS拥有数量惊人的变体,可以轻松绕过黑名单验证.另一个解决方案是强输出编码.在渲染之前,确保所有用户提供的数据都经过适当的实体编码(HTML或XML,具体取决于输出机制).那么,这是阻止跨站点脚本验证和替换输入或编码输出的最佳方法?
Bal*_*usC 41
通常的做法是在JSP 中重新显示期间HTML转义任何用户控制的数据,而不是在servlet 中处理提交的数据期间或在DB 中存储期间.在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>
Run Code Online (Sandbox Code Playgroud)
和
<%@ taglib uri="http://java.sun.com/jsp/jstl/functions" prefix="fn" %>
...
<input name="username" value="${fn:escapeXml(param.username)}">
Run Code Online (Sandbox Code Playgroud)
而已.不需要黑名单.请注意,用户控制的数据涵盖了HTTP请求引入的所有内容:请求参数,正文和标题(!!).
如果你在处理提交的数据和/或存储在数据库中时对它进行HTML转义,那么它就会遍布业务代码和/或数据库中.这是唯一的维护麻烦,当你在不同的地方进行操作时,你将面临双重逃避或更多的风险(例如&,&amp;而不是&让最终用户真正看到&而不是&在视野中.业务代码和数据库反过来对XSS不敏感只有该视图.然后,您应该逃避它只是在那里的视图.
使用两者.实际上,请参考类似于OWASP XSS Prevention备忘单的指南,了解输出编码和输入验证的可能使用情况.
在某些情况下,当您不能依赖输出编码时,输入验证会有所帮助.例如,您最好验证URL中出现的输入,而不是自己编码URL(Apache不会提供URL编码的URL).或者就此而言,验证JavaScript表达式中出现的输入.
最终,一个简单的拇指规则将有所帮助 - 如果您不完全信任用户输入,或者您怀疑某些源可能导致XSS攻击,尽管输出编码,请针对白名单进行验证.
请查看OWASP ESAPI源代码,了解输出编码器和输入验证器如何在安全库中编写.
小智 0
我的偏好是将所有非字母数字字符编码为 HTML 数字字符实体。因为几乎(如果不是所有)攻击都需要非字母字符(如 <、" 等),这应该消除大量危险输出。
格式为 &#N;,其中 N 是字符的数值(您可以将字符转换为 int 并与字符串连接以获得十进制值)。例如:
// java-ish 伪代码
StringBuffer safestrbuf = new StringBuffer(string.length()*4);
foreach(char c : string.split() ){
if(Character.isAlphaNumeric(c)) safestrbuf.append(c);
否则 safestrbuf.append(""+(int)symbol);
您还需要确保在输出到浏览器之前立即进行编码,以避免双重编码或对 HTML 进行编码但发送到不同的位置。
| 归档时间: |
|
| 查看次数: |
91473 次 |
| 最近记录: |