java 跨站点伪造请求,通过“ Referer”标头防止跨站点请求伪造

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:

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.

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.

解决方案

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 (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: