I'm curious about the technical details of the CSRF bypass vulnerability. Anyone know what the "combinations of browser plugins and HTTP redirects" that lead to it are?
Same here. Based on the changes made in the patch, it seems like the attack involves being able to make cross-domain requests but not being able to read back the response. I didn't think that was the way Java and Flash behaved.
run 'bundle update rails' instead of 'bundle update'. If you're like me, you'd like to only update the rails gem.
EDIT: If you run bundle update with no parameters, bundler will ignore any previously installed gems and resolve all dependencies again based on the latest versions of all gems available in the sources.
* In mail_to :encode => :javascript, they weren't sanitizing email addresses, just catting them into the tag.
* There were using Enumerable#reject (ie, default allow) with a strict filter to decide which controllers/actions to route requests to, but case-insensitive filesystems aren't similarly strict.
* (Worst of all) ActiveRecord::QueryMethods#limit/limit_value wasn't sanitized while building queries (try Foo.limit("1,,0") for the flavor).
I don't know what the CSRF thing was either, but it looks like a headachey fix.
Django released a similar fix. According to their changeset, we'll see a release from them shortly as well. Maybe they'll shed some more light on the issue.
Since I have the announcement right in front of me (I'm revising it in preparation for the final post), I can tell you there's not really any more detail in it than in the Rails post.
I don't know yet when the full full disclosure will happen; I just know that right now I'm really not at liberty to do that.
Flash and Java both disallow cross-domain requests unless specifically allowed by a crossdomain.xml file (or you use a DNS rebinding attack on Java). Furthermore, to the best of my knowledge, if you can make an HTTP request in Java or Flash you can read back the result.
To be perfectly clear, Sam is not wrong. Flash and Java both let you issue requests with that header. However, if you try and make a cross-origin request, they'll both throw exceptions unless you have permission (in the form of a crossdomain.xml file). I assume that's where the redirects come into play, although I can't imagine how you redirect someone's POST request to a different domain.
Is there any reason to reset the session on a CSRF failure vs. just failing the request? Seems like you could have fun DOSing people from their sessions on other sites with that default behavior.
I don't have any inside information on this, but my guess is that this is going to come down to confusion about 302/303/307 redirects. In theory, clients receiving a 302 in response to a POST are supposed to re-send the POST wherever the redirect leads; in practice, clients do all kinds of different things. This feels like just the kind of weird edge case that defeats fragile security mechanisms like crossdomain.xml.
I probably shouldn't have phrased that so definitively: I don't have any evidence that Flash is to blame here. In fact, given that this problem required a framework-level fix (rather than, eg, a simple patch from Adobe) I suspect that this affects a lot of things.
In my tweet, I just meant to say that Rails checked for something very simple: a header that Flash's addRequestHeader() can trivially fake out. As Neal points out, that can't be the whole story — but I suspect it's part of it.
Briefly, when both frameworks got an "X-Requested-With" header, they assumed that it was coming from a browser XmlHttpRequest, and that the same-origin policy was in effect. So, they skipped CSRF checks.
However, it turns out that there is a way (details still not disclosed, other than that plugins and redirects are involved) for an attacker to force arbitrary headers onto a web request. Ooops.
Both frameworks are now applying CSRF checks strictly, with no exceptions for apparent XHR.
19 comments
[ 3.0 ms ] story [ 41.6 ms ] threadhttp://groups.google.com/group/rubyonrails-security/browse_t...
EDIT: If you run bundle update with no parameters, bundler will ignore any previously installed gems and resolve all dependencies again based on the latest versions of all gems available in the sources.
* There were using Enumerable#reject (ie, default allow) with a strict filter to decide which controllers/actions to route requests to, but case-insensitive filesystems aren't similarly strict.
* (Worst of all) ActiveRecord::QueryMethods#limit/limit_value wasn't sanitized while building queries (try Foo.limit("1,,0") for the flavor).
I don't know what the CSRF thing was either, but it looks like a headachey fix.
Django released a similar fix. According to their changeset, we'll see a release from them shortly as well. Maybe they'll shed some more light on the issue.
I don't know yet when the full full disclosure will happen; I just know that right now I'm really not at liberty to do that.
http://twitter.com/emerose/status/35169573590409216
Flash and Java both disallow cross-domain requests unless specifically allowed by a crossdomain.xml file (or you use a DNS rebinding attack on Java). Furthermore, to the best of my knowledge, if you can make an HTTP request in Java or Flash you can read back the result.
Resetting sessions on CSRF failures is going to suck for us.
In my tweet, I just meant to say that Rails checked for something very simple: a header that Flash's addRequestHeader() can trivially fake out. As Neal points out, that can't be the whole story — but I suspect it's part of it.
Briefly, when both frameworks got an "X-Requested-With" header, they assumed that it was coming from a browser XmlHttpRequest, and that the same-origin policy was in effect. So, they skipped CSRF checks.
However, it turns out that there is a way (details still not disclosed, other than that plugins and redirects are involved) for an attacker to force arbitrary headers onto a web request. Ooops.
Both frameworks are now applying CSRF checks strictly, with no exceptions for apparent XHR.
http://news.ycombinator.com/item?id=2196214