我们最近收到了来自IBM AppScan DAST的结果，其中一些结果没有多大意义。
2.中等--跨站点请求伪造
风险：可能会窃取或操纵客户会话和cookie，这些会话和cookie可能被用来冒充合法的用户，允许黑客查看或更改用户记录，并以该用户身份执行交易修复：验证"Referer"标头的值，并为每个提交的表单使用一个一次性nonce
以下更改适用于原始请求：
将页眉设置为'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保护为所有情况添加了一个令牌，并额外添加了对"referer"one_answers"origin"HTTP标头的检查。(参考Bauke&Arjan图书最终指南(
该报告还标记了/javax.faces.resource/like CSS、JS等字体，我认为这些字体在报告中是误报。
寻求反馈和一些见解。
这在JSF中确实是不必要的。只有当已经存在一个打开的远程代码执行漏洞(如XSS(时，这种攻击才可能在JSF中发生(因此黑客可以访问会话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);