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.
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.
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.
Comments
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.
Fair enough. I guess I'll just have to work it out for myself. :P
Sam Quigley says:
http://twitter.com/emerose/status/35169573590409216
That's not it, unless I'm missing something big.
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.
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.
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.
I'm just messing with you both.
Resetting sessions on CSRF failures is going to suck for us.
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.
That's right. Of course, without knowing more details about the vulnerability, it's hard to say whether there's a benefit to ending the session.
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.