Cross Site Request Forgery prevention via 'Referer' header - jsf

Question

We recently received result from IBM AppScan DAST and some of the result don't make much senses.
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'
Reasoning:
The test result seems to indicate a vulnerability because the Test Response is identical to the
Original Response, indicating that the Cross-Site Request Forgery attempt was successful, even
though it included a fictive 'Referer' header.
Request/Response:
POST /**/main.xhtml HTTP/1.1 -- **This xhtml only opens a default menu on page load**
User-Agent: Mozilla/4.0 (compatible; MS
The recommend fix
Validate the value of the "Referer" header, and use a one-time-nonce for each submitted form.
javax.faces.ViewState has an implicit CSRF protection.
https://www.beyondjava.net/jsf-viewstate-and-csrf-hacker-attacks
I could also do explicit CSRF protection using protected-views. This explicit CSRF protection adds a token for all cases, and additionally adds checks for the “referer” and “origin” HTTP headers. (Reference Bauke & Arjan Book Definitive Guide)
The report also marks /javax.faces.resource/ like CSS , JS , fonts which i believe are false positive in the report.
Looking for feedback and some insight.

Answer 1

This is indeed needless in JSF. This kind of attack is in JSF only possible when there's already an open remote code execution hole such as XSS (and thus the hacker has access to among others the session cookies and can therefore copy them via the phishing site), or when the view is stateless via <f:view transient="true"> (because you lose the javax.faces.ViewState hidden input field as implicit CSRF protection for the "normal" case when there's no remote code execution hole), or when you use HTTP instead of HTTPS (because a man-in-middle attacker can then plainly see all transferred bits and extract the session cookies from them).
All you need to make sure is that the enduser's session cookies are never in some way exposed to the world. The advised fix is not at all helpful in that. It only makes it the attacker more difficult to perform a successful CSRF attack when you sooner or later accidentally introduce a remote code execution hole. But then you have really way much bigger problems than only CSRF. All these efforts advised by this tool are only useful to give the hacker slightly less time to perform a successful attack, and to give yourself slightly more time to fix the remote code execution hole.
If all you want is to "suppress" this warning, then create a Filter which does the desired job. Here's a kickoff example, map it on /*.
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);
see also:
CSRF, XSS and SQL Injection attack prevention in JSF