通过“Referer”报头防止跨站点请求伪造

Question

我们最近收到了IBM的结果，其中一些结果不太合理。

2.2.Medium-跨站点请求伪造

风险:有可能窃取或操纵客户会话和cookie，这些会话和cookie可用于模拟合法用户，允许黑客查看或更改用户记录，并以该用户修补程序的身份执行事务:验证"Referer“报头的值，并对每个提交的表单使用一次零一次。

对原始请求进行了下列更改：

将标题设置为“http://bogus.referer.ibm.com”推理：

测试结果似乎表明存在漏洞，因为测试响应与原始响应相同，表明跨站点请求伪造尝试是成功的，即使它包含虚构的“Referer”标头。

请求/答复：

POST /**/main.xhtml HTTP/1.1 -*此xhtml只在页面加载**用户代理时打开默认菜单: Mozilla/4.0 (兼容；MS )

推荐的修正

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

javax.faces.ViewState具有隐性的CSRF保护作用。

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

我也可以做明确的CSRF保护使用保护-视图。这种明确的CSRF保护为所有情况添加了一个令牌，另外还添加了对“referer”和“原产地”HTTP报头的检查。(参考Bauke & Arjan图书权威指南)

该报告还标记/javax.faces.resources/类似于CSS、JS、字体，我认为这些字体在报告中是假阳性的。

寻找反馈和一些洞察力。

Answer 1

在JSF中，这确实是不必要的。在JSF中，只有当已经有一个开放的远程代码执行漏洞(例如XSS (因此黑客可以访问会话cookie，因此可以通过钓鱼站点复制它们)，或者视图通过<f:view transient="true"> (因为如果没有远程代码执行孔时，失去javax.faces.ViewState隐藏输入字段作为“正常”情况下的隐含CSRF保护)，或者使用HTTP而不是HTTPS (因为中间人攻击者可以清楚地看到所有传输的位并从中提取会话cookie)，这种攻击才有可能发生。

您需要确保的是，enduser的会话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 = new URL(request.getRequestURL().toString()).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