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 预防功能.使用任何 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>

这也将被隐式转义.您在这里不一定需要 .

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>、 等，那么您需要通过白名单清理输入.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 有一个错误，其中 在提供 List 时错误地呈现未转义的标签. 通过 而不是 List 或 SelectItem[] 作为值(issue 3143).换句话说，如果您通过 List 将用户控制的数据重新显示为项目标签，那么您就有潜在的 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 和 在其他会话 (CSRF) 中重用 ViewState 值.JSF 2.2 中的新功能是 .

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:viewtransient="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 或好的 ol'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 中，您需要使用 PreparedStatement 来填充参数值，在 JPA(和 Hibernate)中，Query 对象也为此提供了 setter.

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屋！