4

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

2.Medium——跨站请求伪造

风险:可能会窃取或操纵客户会话和 cookie,它们可能被用来冒充合法用户,允许黑客查看或更改用户记录,并以该用户身份执行交易修复:验证价值“Referer”标头,并为每个提交的表单使用一次性随机数

对原始请求应用了以下更改:

将标头设置为“ http://bogus.referer.ibm.com

推理:

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

请求/响应:

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 Book Definitive Guide)

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

寻找反馈和一些见解。

4

1 回答 1

8

这在 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);

也可以看看:

于 2020-05-10T10:13:04.700 回答