Flash + 307 redirect = Game Over
lists.webappsec.org
Flash + 307 redirect = Game Over
1–10 of 37 posts
Re: Flash + 307 redirect = Game Over
#2Doh! 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!
Re: Flash + 307 redirect = Game Over
#3Doh! 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 th…
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?
Re: Flash + 307 redirect = Game Over
#4Doh! 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 th…
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.
Re: Flash + 307 redirect = Game Over
#5This 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.
Re: Flash + 307 redirect = Game Over
#6This 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.
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.
Re: Flash + 307 redirect = Game Over
#7This 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.
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.
So my bank would have to already have a page which returns a 307?
Re: Flash + 307 redirect = Game Over
#8Earlier quoted context omitted.
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.
So my bank would have to already have a page which returns a 307?
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.
2. POST request to attacker.com/redirect is made
3. attacker.com/redirect says "307, the request should go to http://victim.com/transfer
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."
Re: Flash + 307 redirect = Game Over
#9Doh! 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 th…
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.
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?
Re: Flash + 307 redirect = Game Over
#10Earlier quoted context omitted.
So my bank would have to already have a page which returns a 307?
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…
The user would first have to go to the attacker.com phishing site though right?
It sounds like it makes phishing scams a lot easier.
(thanks for the explanation btw)