4

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.

Improve this question

2 Answers 2

Reset to default
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.

Improve this answer
6
  • 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
    Commented Nov 23, 2014 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
    Commented Nov 23, 2014 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
    Commented Nov 23, 2014 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
    Commented Nov 23, 2014 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
    Commented Nov 23, 2014 at 18:46
2

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.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .