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