2

I was about the Spring Security framework's CSRF protection to see how it works. Spring doesn't use the double-submit pattern, but instead associates the CSRF token with the user's session. The documentation includes the following explaining why that is:

One might ask why the expected CsrfToken isn’t stored in a cookie. This is because there are known exploits in which headers (i.e. specify the cookies) can be set by another domain. [...] See this webappsec.org thread for details on how to perform the exploit.

The gist of what the webappsec.org thread says is:

  • Attacker puts Flash document on attacker-controlled website, user visits it
  • Flash app makes a same-origin request to the attackers website which sets the target header, and this is permitted by the crossdomain.xml on the attacker's website
  • The attackers website responds to this request with a 302 or 307 redirect to the target website
  • Flash (in "certain circumstances") ignores the target website's crossdomain.xml and makes the request to the target website with the extra header included

My question is: is this a valid concern?

I was unable to reproduce the problem by following the steps in the webappsec.org thread, and furthermore it sounds like this was a straight-up bug in Flash itself rather than any vulnerability with the double-submit cookies pattern. Although this problem resulted in at least two CVEs against web application frameworks I could not find any corresponding bug filed for Flash - but it seems like either it has been fixed since, or I was not correctly reproducing the unspecified "certain circumstances" under which this happens.

2

This issue was specific in nature, and has since been patched out of Ruby. Flash was more of an example of how one can exploit this issue with a browser plugin, a good example too given it's probably one of the most common plugins, but the actual flaw was in Ruby.

We are also talking way edge case that an attacker could pull this off.

There is really nothing to see here unless you are playing with unpatched versions Ruby.

  • I know that Ruby was vulnerable despite not using double-submit cookies because it skipped CSRF validation if a certain header was present... but wouldn't the same attack vector (attacker controls a header) mean that other frameworks that are using only double-submit cookies to defeat CSRF are still vulnerable? – ZoFreX Nov 23 '14 at 0:18
  • Not really, the flaw was in how ruby parsed that header. I have yet to see anything come up on other frameworks. What you say is true, in the sense that theoretically it's possible other frameworks could be vulnerable if that had a similar flaw in parsing, but it hasn't been shown to be an issue thus far. – atyoung Nov 23 '14 at 17:17
  • It has come up in other frameworks, I linked the Django vuln in my question. However, there's nothing in the Ruby bug that says there was a flaw in how they parsed it, the flaw was "Ruby skips validation if this header is present, and the Flash bug allows the attacker to add this header". If "attacker using Flash bug to set headers" is a reasonable attack to consider, then isn't double-submit cookie pattern insufficient to stop CSRF? – ZoFreX Nov 23 '14 at 18:17
  • Again Django patched into history as something that is not an issue. I get what you're saying, in the sense that flash shouldn't allow the problem in the first place, but then again you can't control what client applications submit, only how you deal with it. That said, my comment with regard to parsing has to do with how it skips, as in it must read the header, parse it, and make decisions based on what it parses. It skips based on it, not doing what should should have done with that portion of the header while parsing. – atyoung Nov 23 '14 at 18:31
  • I think we are crossing into who's job is it to mitigate the problem. Using flash as a vehicle for CSRF is a known thing, however the responsibly is on the receiver, and in the end it's about validating your input responsibily, which is programming 101. Most frameworks at some point have had to secure their methods against cross site of one type or another, so provided you keep your framework up to date, you should be relatively safe. – atyoung Nov 23 '14 at 18:46
1

Double submission is vulnerable to man-in-the-middle attacks when using HTTPS, because of usual same origin policy restrictions do not apply to cookies: an attacker can set a token through HTTP (by luring the victim to visiting an HTTP link and forging a response) which will be sent to the server through HTTPS.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.