Doh! Sam Quigley called it. In the 307 redirect case, which instructs the client to redirect POST data as well as the bare request, Flash can be coerced into honoring the crossdomain.xml file from the REDIRECTOR site instead of the REDIRECTEE site.
* Attackers control redirectors (they can just set up their own).
* Flash will set custom headers if crossdomain.xml allows them to.
* Rails and Django rely on the fact that attackers can't send custom headers (in particular, the XRW header that told Rails and Django "this is Ajax, don't worry about CSRF").
* So attackers can basically forge the crossdomain policy for arbitrary target sites using Flash, bypassing the CSRF security check in Rails and Django.
Fortunately, the attack is limited by the fact that the attacker can't see the response from the server. If the attacker could view the response, it would break CSRF protection based on nonces as well.
No, but that wasn't my point. My point was that this vulnerability can be (and has been) worked around by using nonces in the header. If you can see the response body, that protection becomes worthless as well (and there is no workaround for that).
I guess they forced the end of the session to allow non-session authentication, for example for an Client accessing an RESTful API.
I didn't found anything about this, but when you look at the related commit in rails (https://github.com/rails/rails/commit/66ce3843d32e9f2ac3b1da...) they also removed the white listing an all non html-requests ("content_mime_type.verify_request?"). So any (api) client modifying XML or JSON resources of an rails app would not be allowed to do so, because of the need to provide the authentication token. Which isn't available for an API client, because there is no session.
So instead of throwing an exception to prevent an CSRF-attack they just kill the session to prevent authentication by this session. For an api client this is no big deal, because normally it authenticates with per request credentials.
If you don't feel/have the need to support non session authentication, my guess is you could simply overwrite the handle_unverified_request method in your application controller to throw an exception again. But I would wait for further explanation by the rails core team.
* Attackers control redirectors (they can just set up their own).
* Flash will set custom headers if crossdomain.xml allows them to.
* Rails and Django rely on the fact that attackers can't send custom headers (in particular, the XRW header that told Rails and Django "this is Ajax, don't worry about CSRF").
* So attackers can basically forge the crossdomain policy for arbitrary target sites using Flash, bypassing the CSRF security check in Rails and Django.
So much win!