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.
1) Who hosts the flash app? The site owned by the attacker? Or must the flash app be maliciously uploaded to the site being attacked?
2) And seriously, the final result of this scheme to to make a post to "www.victim.com". Doesn't "victim" mean someone who is exploited? I would expect that data would be taken from a victim, not posted to a victim.
1. It doesn't matter where the SWF is, as long as it can make requests to a redirecting script. That's the point of the attack: you can make cross-domain requests via a redirect.
2. Victim is referring to a victim domain. Pretend victim.com is your bank, and the POST is to send some cash to my account.
No. Let me try explaining the simplest possible version of this attack.
Your bank (http://victim.com) is running its external-facing web application on Ruby on Rails. If you send a POST request to http://victim.com/transfer, you can transfer money to another person (the recipient is specified in the POST body).
The attacker sets up the following things on attacker.com:
1. A page that replies with 307 redirects to a specified destination
2. A Flash applet that makes POST requests
3. A page embedding that applet
The attacker sets the applet as if it were making a POST request to http://victim.com/transfer, setting the X-Requested-With header to bypass CSRF protection. But instead of POSTing directly to victim.com, the attacker POSTs to the redirect script.
So the end result looks something like this:
1. Flash checks to make sure that it can make requests to attacker.com (via crossdomain.xml, or by the same origin policy). It can.
4. Flash says "OK" and makes the same request but now directed at victim.com
5. After the request has been made, Flash checks the crossdomain.xml file and says "whoops, shouldn't have made that request: you can't see the response."
The part I don't understand is the POST hitting the victim app. I don't know django but rails apps require an authenticity token to be included in all non-GET requests. How does the attacking app satisfy this token check?
The bug was that Rails didn't check for the authenticity token in case of requests that were labeled as XmlHttpRequest (i.e., Ajax), and the redirect-from-flash game allows the attacker to forge the label. The fix makes it check in all cases; this is why it comes with stuff that you're supposed to patch into your layouts and application.js to put authenticity tokens into all your Ajax calls.
Rails WAS configured to accept the token OR a custom header, relying on the fact that custom headers can't be created cross domain. The patch fixes this, by requiring BOTH. Hmmm... So how do they know what the custom header is? Are they typically static?
The CSRF token is generated and stored in the user session, so rather than just X-Requested-With: XMLHttpRequest, you now also get an X-CSRF-Token: <some token stored in the user session>.
Rails doesn't check for XRW anymore; it just cares that you passed a valid CSRF token through, either as a POST variable (normal POST/PUT/DELETE) or in the X-CSRF-Token header (AJAX).
In case you're wondering, yes, this does make caching with Varnish a bitch and a half.
I want know how the exploit works. The Flash app has to write a custom header. How does it know the value to put in the header, unless it's always the same for all sessions across all users.
That's the point of the fix. The header is custom per user now. Before, the presence of the "X-Requested-With: XmlHttpRequest" header was enough to let Rails assume the request was legit. Since Flash doesn't respect the victim's crossdomain.xml, this is no longer a valid assumption, and you have to use a unique header per session.
This means writing this unique value out into the page somewhere, to be included with any AJAX requests, which means that you cannot cache these pages as you might before, since AJAX calls would fail for everyone except the person who populated the cache.
That's the point of the fix: X-CSRF-Token requires the CSRF token, which is per-user, as its value. X-Requested-With, the old way of doing things, just had to be present in the request.
My reading is that it's not necessarily phishing because they wouldn't need to ask the user for any information. All that would be required is for the user to be signed into the targeted webapp.
It could be totally automated. But, since the attacker doesn't get the response, they couldn't necessarily do anything with that. That doesn't make this any less dangerous, as in the bank example, you don't necessarily need to see that your transfer was successful in order to get the money.
is all that you need to execute this attack in your browser. An attacker can hide the applet via CSS and put it on a legitimate looking page. All the target needs to do is be logged in.
If you want to be super evil about it you could also embed the evil POSTing code in a swf that looks like an unevil ad and then let an unsuspecting ad network distribute it for you.
Correct. Put it up using Google Adwords or a similar network, make sure attacker.com has a proper crossdomain.xml file (because the SWF won't be served from attacker.com), and you have a working exploit that can be deployed all over the Internet.
It's basically a bug in Flash. It works like this:
Attacker hosts a flash file, which attempts a cross-domain request to a server controlled by the attacker.
Flash checks crossdomain.xml on the attacker-controlled server. It says "Allow everything". Flash makes the request to the attacker-controlled server.
Server issues a 307 redirect to a www.victim.com that manipulates the user's account in a malicious way. The particular manipulation depends on what www.victim.com does, but changing the e-mail address to spoof the automated password recovery system would be a common one.
Flash does not check the crossdomain.xml on www.victim.com.
The attacker has now manipulated the user's account on www.victim.com in a malicious way.
Flashblock would probably not save you. It doesn't actually prevent Flash content from being downloaded and run; it just hides it with CSS.
I use NoScript myself, but that tends to break too much by default for most people. When I set up a flash blocker for other people, I give them NoScript in "Allow Scripts Globally" mode.
Are you sure about that? Because that's not the way Flashblock describes itself:
Flashblock is an extension for the Mozilla, Firefox, and Netscape browsers that takes a pessimistic approach to dealing with Macromedia Flash content on a webpage and blocks ALL Flash content from loading. It then leaves placeholders on the webpage that allow you to click to download and then view the Flash content.
It would be pretty useless if all it did was hide the content via CSS.
I just tested the extension and I can confirm that Flashblock only downloads and runs the content when the placeholder is explicitly clicked on. So, Wikipedia is wrong. ;)
Edit: If I browse to an SWF directly, it does appear to load the content. If I create the SWF via SWFObject, it does not load until I explicitly click on the placeholder.
That question is poorly worded. It's referring to blocking Flash cookies in general. Flashblock will not prevent the use of Flash cookies by applets that you allow to run.
* 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!