Flash + 307 redirect = Game Over

http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/2011-February/007533.html

by ssclafani • 15 years ago

72 36 15 years ago

lists.webappsec.org

tptacek2• 15 years ago

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.

So much win!

paulhammond• 15 years ago

This explains a lot, but thing it doesn't cover is why the patch for Rails ends the session when a CSRF token is missing.

I'm guessing this is just extra paranoia, but it opens an obvious attack to log people out of a site maliciously.

Any ideas on that one?

tptacek2• 15 years ago

I do not know, and I hope it's just paranoia, because that's a giant pain in the ass.

smunz• 15 years ago

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.

nbpoole10• 15 years ago

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.

bensummers• 15 years ago

What if that forged request was to a "create new account" URL, for example? Or to delete something important? Or transfer some money?

Do you need to see the response to do bad things?

euroclydon4• 15 years ago

This is so difficult to follow.

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.

nbpoole10• 15 years ago

It's actually fairly straightforward

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.

euroclydon4• 15 years ago

So my bank would have to already have a page which returns a 307?

amalcon3• 15 years ago

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.

wnoise• 15 years ago

Hooray flashblock.

amalcon3• 15 years ago

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.

nbpoole10• 15 years ago

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.

jodrellblank• 15 years ago

After a confirmation message that will be unclear to most users

i.e. it requests permission?

sdizdar• 15 years ago

I have a stupid question: Does this vulnerability exist if rails runs https?

nbpoole10• 15 years ago

Yes

EGreg• 15 years ago

Why don't they use the session nonce instead of double-submit cookies approach to CSRF prevention?

Flash + 307 redirect = Game Over

Related Stories