Hi, A description of this exploit has been posted here: http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/2011-February/007533.html
[I presume any bad guys will have seen that post, so didn't see why not to point people to it on this mailing list.] Jon On Thu, 2011-02-10 at 10:06 +1300, Michael Koziarski wrote: > > 1. Where is the complete Advisory? The Impact section is very unclear. > > Looking at the comment in the 2.3 patch mentions "Flash animations and > > Java applets" - does the whole thing deserve a bit more explaining? > > We've been deliberately vague in the description of the exploit so as > not to provide ready-made exploit kits to attack other frameworks and > rails applications which haven't been upgraded. We've been contacted > since by a browser vendor and a few other frameworks requesting > details. I'm sure the full details of how this can be exploited are > already available in some circles but for now we're not going to make > that job any easier. > > I don't think providing any more details here will help anyone, it > affects your users and is easily exploitable. > > > > 2. Lines 40-48 in the 2.3 patch changes the CSRF protection to only > > allow get requests and requests with the correct form authenticity > > token through - is this not going to break stateless web service and > > ActiveResource post requests that does not maintain state on the > > client side? - line 228 in the 2.3 patch tests that xml requests > > should be validated for authenticity token. This is going to break > > quite a few things. > > > > Should Rails by default (still) support authenticated stateless > > requests (for the sake of web services)? Or should we handle this by > > overriding handle_unverified_request (line 31 patch 2.3)? > > > > What am I missing? > > You don't need to override anything. The behaviour of > handle_unverified_request is to reset the session, this should not in > any way affect your API clients (or anything else stateless). However > if you've already overridden verify_request_token in your app you'll > need to remove that. > > API requests will indeed cause handle_unverified_request to be called, > however it won't affect them at all as they won't notice that the > session cookie has 'changed' as they didn't use it in the first place. > > If you have API requests which *do* rely on the session, then you're > fucked as that's a CSRF request by definition. > > > > -- > Cheers > > Koz > -- http://jonathanleighton.com/
signature.asc
Description: This is a digitally signed message part
