通过“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 保护为所有情况添加了一个令牌，并额外添加了对“引用者”和“来源”HTTP 标头的检查。（参考 Bauke & Arjan 图书权威指南）

该报告还将 /javax.faces.resource/ 标记为 CSS ， JS ，我认为报告中误报的字体。

寻找反馈和一些见解。

Answer 1

这在 JSF 中确实是不必要的。这种攻击在 JSF 中只有在已经有一个开放的远程代码执行漏洞（例如 XSS）时才有可能发生（因此黑客可以访问其中的会话 cookie，因此可以通过网络钓鱼站点复制它们），或者当视图是无状态通过<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 = 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);

也可以看看：

• JSF 中的 CSRF、XSS 和 SQL 注入攻击预防