jsf - 通过 'Referer' header 防止跨站点请求伪造

Question

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

2.Medium -- Cross-Site Request Forgery

Risk(s): It may be possible to steal or manipulate customer session and cookies, which might be used to impersonate a legitimate user, allowing the hacker to view or alter user records, and to perform transactions as that user Fix: Validate the value of the "Referer" header, and use a one-time-nonce for each submitted form

The following changes were applied to the original request:

Set header to '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

推荐修复

Validate the value of the "Referer" header, and use a one-time-nonce for each submitted form.

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

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

我还可以使用 protected View 进行显式 CSRF 保护。这种显式 CSRF 保护为所有情况添加了一个 token ，并额外添加了对“引用者”和“来源”HTTP header 的检查。 (引用 Bauke & Arjan 书籍权威指南)

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

寻找反馈和一些见解。

Answer 1

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

您只需要确保最终用户的 session 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