5

Need for CSRF protection that withstands an XSS attack

One of the big dangers of XSS is that it can often bypass CSRF protection and thus perform any action the victim can perform.

If it would be possible to prevent CSRF even if an XSS vulnerability exists, it seems that that would greatly mitigate the damage XSS can do. Because of httpOnly, it may not be possible to steal cookies, which would leave an attacker with phishing attacks, defacement , and reading out data that is accessible to the client.

But OWASP says that it is not possible to prevent CSRF once an XSS vulnerability exists.

Using referrer check for proper CSRF protection?

Shouldn't it be possible to use referrer checks as CSRF protection which work even if an XSS vulnerability exists?

Of course a domain check would not be enough. But wouldn't it work if the exact script is checked?

For example, if a request is sent from http://example.com/add-user.php, it would be required that the referrer is http://example.com/add-user.php.

This still means that an attacker can perform CSRF on that script, if that script contains an XSS vulnerability, but no CSRF attacks on different scripts on the same domain should be possible, as referrers cannot be set via JavaScript.

  • Referrer checks may not always be practical (for example, because the client doesn't send referrers), but if they are used, could they be used in such a way?
  • If they can be used like this, are there major downsides to this approach?
  • If not, could there theoretically be a CSRF protection that works if an XSS vulnerability exists?
Rápli András
  • 2,124
  • 11
  • 24
tim
  • 29,018
  • 7
  • 95
  • 119

2 Answers2

5

No, I don't think so. It could be circumvented by creating an iframe with display: none, containing the page add-users.php. Then all the attacker has to do is to fill in the form fields and submit the form with JavaScript, and the attacker has successfully added a user without the victim's consent or knowledge. Checking the referer header would not stop this, as it would have the correct value.

OWASP has the following to say on using the referer for CSRF protection:

Although it is trivial to spoof the referer header on your own browser, it is impossible to do so in a CSRF attack. Checking the referer is a commonly used method of preventing CSRF on embedded network devices because it does not require a per-user state. This makes a referer a useful method of CSRF prevention when memory is scarce. This method of CSRF mitigation is also commonly used with unauthenticated requests, such as requests made prior to establishing a session state which is required to keep track of a synchronization token.

However, checking the referer is considered to be a weaker from of CSRF protection. For example, open redirect vulnerabilities can be used to exploit GET-based requests that are protected with a referer check and some organizations or browser tools remove referrer headers as a form of data protection. There are also common implementation mistakes with referer checks. For example if the CSRF attack originates from an HTTPS domain then the referer will be omitted. In this case the lack of a referer should be considered to be an attack when the request is performing a state change. Also note that the attacker has limited influence over the referer. For example, if the victim's domain is "site.com" then an attacker have the CSRF exploit originate from "site.com.attacker.com" which may fool a broken referer check implementation. XSS can be used to bypass a referer check.

In short, referer checking is a reasonable form of CSRF intrusion detection and prevention even though it is not a complete protection. Referer checking can detect some attacks but not stop all attacks. For example, if you HTTP referrer is from a different domain and you are expecting requests from your domain only, you can safely block that request.

(On a side note, I would dispute that solving this problem would "greatly mitigate" the damages from XSS. An attacker could still steal passwords, in addition to the other things you list. That is still pretty bad.)

Community
  • 1
Anders
  • 64,406
  • 24
  • 178
  • 215
4

Shouldn't it be possible to use referrer checks as CSRF protection which work even if an XSS vulnerability exists?

Nope. If you are injected script, you can create a <form> pointing at the same origin, include a purloined CSRF token, and submit it with the expected Referer header. (Also referrer checks are problematic in general of course, and unlikely to be of any use if this is an application doing anything with XHR.)

But wouldn't it work if the exact script is checked?

Nope. Once inside an origin there is no internal security boundary. Injected script can open any URL within the origin (eg in an iframe or pop-up) and inject arbitrary script directly into that window, from where it will return the exact expected referrer. (And these days with HTML5 History API you can just change the URL of the current document directly anyway.)

There is almost nothing a user can do by interacting with a web page that can't be reproduced by a script on that page. So OWASP is right on this one: XSS in general gives you a more severe superset of vulnerabilities than XSRF does. There is nothing much you can usefully do to mitigate it once it has happened, which is why the emphasis is usually on getting the text handling/escaping right to avoid injections happening in the first place.

bobince
  • 12,494
  • 1
  • 26
  • 42