Java防止跨站点脚本的最佳实践 [英] Java Best Practices to Prevent Cross Site Scripting

查看:959
本文介绍了Java防止跨站点脚本的最佳实践的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

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

I have gone through the OWASP top ten vulnerabilities and found that Cross-Site Scripting is the one we have to take notes. There was few way recommended solutions. One has stated that Do not use "blacklist" validation to detect XSS in input or to encode output. Searching for and replacing just a few characters (< and > and other similar characters or phrases such as script) is weak and has been attacked successfully. Even an unchecked "<b>" tag is unsafe in some contexts. XSS has a surprising number of variants that make it easy to bypass blacklist validation. Another solution said that Strong output encoding. Ensure that all user-supplied data is appropriately entity encoded (either HTML or XML depending on the output mechanism) before rendering. So, which is the best way to prevent cross site scripting to validate and replace the input or encoding the output ?

推荐答案

正常实践是在JSP中重新显示期间HTML转义任何用户控制的数据,而不是在处理 servlet中提交的数据期间或期间在数据库中存储。在JSP中,您可以使用 JSTL (安装它,只需在<$ c中删除 jstl-1.2.jar $ c> / WEB-INF / lib ) < c:out> 代码或 fn:escapeXml 此功能。例如

The normal practice is to HTML-escape any user-controlled data during redisplaying in JSP, not during processing the submitted data in servlet nor during storing in DB. In JSP you can use the JSTL (to install it, just drop jstl-1.2.jar in /WEB-INF/lib) <c:out> tag or fn:escapeXml function for this. E.g.

<%@ 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请求引入的所有:请求参数,正文和标题(!!)。

That's it. No need for a blacklist. Note that user-controlled data covers everything which comes in by a HTTP request: the request parameters, body and headers(!!).

如果您在处理提交的数据和/或存储在数据库中时对其进行HTML转义,那么它们将全部分布在业务代码和/或数据库中。这是唯一的维护问题,当您在不同的地方进行操作时,您将面临双重逃避或更多的风险(例如& 将变为& amp; amp ; 而不是& amp; ,以便最终用户真正看到& amp; 而不是& 在视图中。业务代码和数据库反过来对XSS不敏感。只有视图是。你应该只在那里转义它在视图中。

If you HTML-escape it during processing the submitted data and/or storing in DB as well, then it's all spread over the business code and/or in the database. That's only maintenance trouble and you will risk double-escapes or more when you do it at different places (e.g. & would become &amp;amp; instead of &amp; so that the enduser would literally see &amp; instead of & in view. The business code and DB are in turn not sensitive for XSS. Only the view is. You should then escape it only right there in view.

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

这篇关于Java防止跨站点脚本的最佳实践的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆