JSF中的CSRF，XSS和SQL注入攻击防护 [英] CSRF, XSS and SQL Injection attack prevention in JSF
问题描述
我有一个在JSF上构建的Web应用程序，其中MySQL作为数据库.我已经在应用程序中实现了防止CSRF的代码.
I have a web application built on JSF with MySQL as DB. I have already implemented the code to prevent CSRF in my application.
现在，由于我的底层框架是JSF，我想我不必处理XSS攻击，因为它已经由UIComponent处理.我没有在任何视图页面中使用任何JavaScript.即使使用，我是否真的需要实现代码来防止XSS攻击?
Now since my underlying framework is JSF, I guess I don't have to handle XSS attack as it is already handled by UIComponent. I am not using any JavaScript in any of the view pages. Even if I use do I really need to implement code to prevent XSS attacks?
对于数据库，我们在所有数据库交互中都使用准备好的语句和存储过程.
For DB we are using prepared statements and stored procedures in all DB interactions.
是否需要采取其他措施来防止这3种常见攻击? 我已经浏览过 OWASP 网站及其
Is there anything else needs to be handled for preventing these 3 common attacks? I have already been through the OWASP site and their cheat sheets.
我还需要照顾其他潜在的攻击媒介吗?
Do I need to take care of any other potential attack vectors?
推荐答案
XSS
JSF被设计为具有内置的XSS预防功能.您可以使用以下命令安全地重新显示所有用户控制的输入(请求标头(包括cookie！)，请求参数(也包括保存在DB！中的参数)和请求正文(上传的文本文件等))任何JSF组件.
XSS
JSF is designed to have builtin XSS prevention. You can safely redisplay all user-controlled input (request headers (including cookies!), request parameters (also the ones which are saved in DB!) and request bodies (uploaded text files, etc)) using any JSF component.
<h:outputText value="#{user.name}" />
<h:outputText value="#{user.name}" escape="true" />
<h:inputText value="#{user.name}" />
etc...
请注意，当您在Facelets上使用JSF 2.0时，可以在模板文本中使用EL，如下所示:
Note that when you're using JSF 2.0 on Facelets, then you can use EL in template text like so:
<p>Welcome, #{user.name}</p>
这也将隐式地转义.您不必在这里<h:outputText>.
This will also implicitly be escaped. You don't necessarily need <h:outputText> here.
仅，当您使用escape="false"明确地转义用户控制的输入时:
Only when you're explicitly unescaping user-controlled input using escape="false":
<h:outputText value="#{user.name}" escape="false" />
那么您就有潜在的XSS攻击漏洞！
then you've a potential XSS attack hole!
如果您希望将用户控制的输入重新显示为HTML，而您只希望允许特定的HTML标签子集(如<b>，<i>，<u>等)，则需要清理由白名单输入. HTML解析器 Jsoup 非常
If you'd like to redisplay user-controlled input as HTML wherein you would like to allow only a specific subset of HTML tags like <b>, <i>, <u>, etc, then you need to sanitize the input by a whitelist. The HTML parser Jsoup is very helpful in this.
较旧的Mojarra版本之前 2.2.6具有以下错误:当通过<f:selectItems var>而不是List<SelectItem>或SelectItem[]提供List<T>作为值时，<f:selectItems itemLabel>错误地使标签转义为未转义(问题3143 ).换句话说，如果要通过List<T>将用户控制的数据重新显示为项目标签，则可能会有XSS漏洞.如果不能升级到至少Mojarra 2.2.6，则需要将itemLabelEscaped属性显式设置为true来防止这种情况.
Older Mojarra versions before 2.2.6 had the bug wherein <f:selectItems itemLabel> incorrectly renders the label unescaped when provided a List<T> via <f:selectItems var> instead of List<SelectItem> or SelectItem[] as value (issue 3143). In other words, if you're redisplaying user-controlled data as item labels via a List<T>, then you've a potential XSS hole. If upgrading to at least Mojarra 2.2.6 is not an option, then you need to explicitly set itemLabelEscaped attribute to true to prevent that.
<f:selectItems value="#{bean.entities}" var="entity" itemValue="#{entity}"
itemLabel="#{entity.someUserControlledProperty}" itemLabelEscaped="true" />
CSRF
当使用服务器端状态保存时，JSF 2.x已经以javax.faces.ViewState隐藏字段的形式内置了CSRF预防功能.在JSF 1.x中，该值非常弱且太容易预测了(实际上从来没有打算将其用作CSRF预防措施).在JSF 2.0中，通过使用长而强的自动生成的值而不是相当可预测的序列值来改进此功能，从而使其成为可靠的CSRF预防方法.
CSRF
JSF 2.x has already builtin CSRF prevention in flavor of javax.faces.ViewState hidden field in the form when using server side state saving. In JSF 1.x this value was namely pretty weak and too easy predictable (it was actually never intended as CSRF prevention). In JSF 2.0 this has been improved by using a long and strong autogenerated value instead of a rather predictable sequence value and thus making it a robust CSRF prevention.
在JSF 2.2中，通过使其成为JSF规范的必需部分，以及在启用了客户端状态保存的情况下，可配置的AES密钥来加密客户端状态，甚至可以进一步改进此功能.另请参见 JSF规范问题869 和 <protected-views> .
In JSF 2.2 this is even be further improved by making it a required part of the JSF specification, along with a configurable AES key to encrypt the client side state, in case client side state saving is enabled. See also JSF spec issue 869 and Reusing ViewState value in other session (CSRF). New in JSF 2.2 is CSRF protection on GET requests by <protected-views>.
仅当您像<f:view transient="true">中那样使用无状态视图时，或者在应用程序中存在XSS攻击孔时，才有潜在的CSRF攻击孔.
Only when you're using stateless views as in <f:view transient="true">, or there's somewhere a XSS attack hole in the application, then you've a potential CSRF attack hole.
这不是JSF的责任.如何防止这种情况取决于您使用的持久性API(原始JDBC，现代JPA或优秀的Hibernate)，但所有问题归结为您应该从不将用户控制的输入连接到SQL字符串中，例如所以
This is not JSF's responsibility. How to prevent this depends on the persistence API you're using (raw JDBC, modern JPA or good ol' Hibernate), but all boils down that you should never concatenate user-controlled input into SQL strings like so
String sql = "SELECT * FROM user WHERE username = '" + username + "' AND password = md5(" + password + ")";
String jpql = "SELECT u FROM User u WHERE u.username = '" + username + "' AND u.password = md5('" + password + "')";
想象一下，如果最终用户选择以下名称，将会发生什么:
Imagine what would happen if the enduser chooses the following name:
x'; DROP TABLE user; --
您应该始终在适用的情况下使用参数化查询.
You should always use parameterized queries where applicable.
String sql = "SELECT * FROM user WHERE username = ? AND password = md5(?)";
String jpql = "SELECT u FROM User u WHERE u.username = ?1 AND u.password = md5(?2)";
在纯JDBC中，您需要使用
In plain JDBC you need to use PreparedStatement to fill the parameter values and in JPA (and Hibernate), the Query object offers setters for this as well.
这篇关于JSF中的CSRF，XSS和SQL注入攻击防护的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
