通过“ Referer”标题防止跨站请求伪造

Question

我们最近收到了来自IBM AppScan DAST的结果，其中一些结果没有多大意义。

2.Medium –跨站点请求伪造

风险：可能会窃取或操纵客户会话和Cookie，这些行为可能用于冒充合法用户用户，允许黑客查看或更改用户记录，并以该用户身份执行交易修复：验证“ Referer”标头的值，并对每个提交的表单使用一次一次性]

以下更改已应用于原始请求：

将标题设置为'http://bogus.referer.ibm.com'

理由：

测试结果似乎表明存在漏洞，因为测试响应与原始响应，表示跨站点请求伪造尝试成功，甚至尽管它包含一个虚构的“ Referer”标头。

请求/响应：

POST /**/main.xhtml HTTP/1.1 -- **This xhtml only opens a default menu on page load**
User-Agent: Mozilla/4.0 (compatible; MS

推荐修复方法

验证“ Referer”标头的值，并对每个提交的表单使用一次一次性。

javax.faces.ViewState具有隐式的CSRF保护。

https://www.beyondjava.net/jsf-viewstate-and-csrf-hacker-attacks

我也可以使用保护视图来进行显式CSRF保护。这种显式的CSRF保护为所有情况添加了令牌，并另外添加了对“ referer”和“ origin” HTTP标头的检查。 （参考Bauke和Arjan的书权威指南）

该报告还标记/javax.faces.resource/，如CSS，JS，我认为在报告中为假阳性的字体。

正在寻找反馈和一些见识。

Answer 1

这在JSF中确实是不必要的。仅当存在[[已经远程代码执行漏洞（因此黑客可以访问会话cookie并因此可以通过网络钓鱼站点复制它们）时，才可能在JSF中进行这种攻击。通过<f:view transient="true">是无状态的（因为您失去了javax.faces.ViewState隐藏的输入字段作为隐式CSRF保护），或者当您使用HTTP而不是HTTPS时（因为中间人攻击者可以清楚地看到所有传输的位并提取他们的会话Cookie）。

您需要确保的是，会话cookie绝不会以某种方式暴露给外界。建议的修复程序对此毫无帮助。当您迟早引入远程代码执行漏洞时，这只会使攻击者更难进行成功的CSRF攻击。但是，除了CSRF之外，您还有[[确实要大得多]]问题。此工具建议的所有这些努力仅对减少黑客执行成功攻击的时间以及使自己有更多时间修复远程代码执行漏洞有用。

如果您只想“抑制”此警告，则创建一个Filter即可完成所需的工作。这是一个启动示例，将其映射到/*。

if (!"GET".equals(request.getMethod())) {
    String referrer = request.getHeader("referer"); // Yes, with the legendary typo.

    if (referrer != null) {
        String referrerHost = new URL(referrer).getHost();
        String expectedHost = request.getRequestURL().getHost();

        if (!referrerHost.equals(expectedHost)) {
            response.sendError(403);
            return;
        }
    }
    else {
        // You could also send 403 here. But this is more likely to affect real users.
    }
}

chain.doFilter(request, response);

另请参见：

CSRF, XSS and SQL Injection attack prevention in JSF