Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Flash + 307 redirect = Game Over

lists.webappsec.org

Post reply on HN
Print view View original

21–30 of 37 posts

Re: Flash + 307 redirect = Game Over

#21

Post by tptacek »

paulhammond wrote: post #3
tptacek wrote: post #2

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 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?

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

Re: Flash + 307 redirect = Game Over

#22

Post by cheald »

euroclydon wrote: post #19
ben_h wrote: post #14

Earlier quoted context omitted.

Good explanation, thanks. 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?

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: .

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.

Re: Flash + 307 redirect = Game Over

#23

Post by euroclydon »

cheald wrote: post #22
euroclydon wrote: post #19

Earlier quoted context omitted.

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: . 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.

P.S. You cache POST/PUT/DELETES?

Re: Flash + 307 redirect = Game Over

#24

Post by smunz »

paulhammond wrote: post #3
tptacek wrote: post #2

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 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?

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.

Re: Flash + 307 redirect = Game Over

#25

Post by nbpoole »

euroclydon wrote: post #23
cheald wrote: post #22

Earlier quoted context omitted.

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: . 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. P.S. You cache POST/PUT/DELETES?

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.

Re: Flash + 307 redirect = Game Over

#26

Post by SoftwareMaven »

euroclydon wrote: post #23
cheald wrote: post #22

Earlier quoted context omitted.

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: . 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. P.S. You cache POST/PUT/DELETES?

The exploit SWF just puts in that it is an Ajax call:

X-Requested-With: XMLHttpRequest

which says "I'm an AJAX request". Since the value is static, it is easy to use in an exploit.

Re: Flash + 307 redirect = Game Over

#27

Post by jbri »

euroclydon wrote: post #23
cheald wrote: post #22

Earlier quoted context omitted.

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: . 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. P.S. You cache POST/PUT/DELETES?

If you cache the page from which a user submits a POST/PUT/DELETE, how are they going to get their CSRF token?

Re: Flash + 307 redirect = Game Over

#28

Post by amalcon »

euroclydon wrote: post #5

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.

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.

Re: Flash + 307 redirect = Game Over

#29

Post by amalcon »

wnoise wrote: post #18

Hooray flashblock.

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.

Post reply on HN