Hacker News Reader

Comment by tptacek | Hacker News Reader

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!

View on HN

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?

I think what he's saying is if your CSRF protection is based on a nonce, this vulnerability doesn't break it.

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

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.

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.

Reply on news.ycombinator.com