通过'Referer'头防止跨站点请求伪造。

Question

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

2.中 -- 跨站请求伪造

风险。有可能窃取或操纵客户的会话和cookies，这可能被用来冒充合法用户，使黑客能够查看或更改用户记录，并以该用户的身份进行交易。验证 "Referer "头的值，并对每个提交的表单使用一次性的 "once"。

对原始请求进行了以下修改。

将页眉设置为"http:/bogus.referer.ibm.com。'

推理。

测试结果似乎表明存在漏洞，因为测试响应与原始响应相同，表明跨站请求伪造尝试成功，即使它包含了一个虚假的 "Referer "头。

RequestResponse。

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

建议的修复方法

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

javax.faces.ViewState有一个隐式CSRF保护。

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

我也可以使用protected-views做显式CSRF保护。这种显式CSRF保护对所有情况都增加了一个标记，并额外增加了对 "referer "和 "origin "HTTP头的检查。(参考Bauke &Arjan书定指南)

报告中还标记了javax.faces.resource，如CSS，JS，字体，我相信这些都是报告中的假阳性。

希望得到反馈和一些见解。

Answer 1

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

你需要确保的是最终用户的会话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注入攻击。