4 ms·
Fair enough. I guess I'll just have to work it out for myself. :P
by nbpoole 16y ago
Fair enough. I guess I'll just have to work it out for myself. :P
- tptacek 16y agoSam Quigley says: http://twitter.com/emerose/status/35169573590409216 http://twitter.com/emerose/status/35169573590409216
- nbpoole 16y agoThat'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.
- nbpoole 16y agoTo 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.
- tptacek 16y agoI'm just messing with you both. Resetting sessions on CSRF failures is going to suck for us.
- bonzoesc 16y agoIs 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.
- nbpoole 16y agoThat'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.
- emerose 16y agoI 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.
- emerose 16y agoI 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.