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.