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)?
I was looking at this last night and shaking my head trying to work
out whether (from the description) this affects any of my sites, and
if so, what to do to patch it.
Fortunately, I have a penetration test scheduled in a couple of weeks
for the app I'm working on at the moment, so I'll let those guys tell
me if I'm at risk, and see if they can decipher the fix...
I wasn't asking a question, I was talking... this is the talk list :-/
I understood the suggestion to post on core as a better way to get
clarification rather than a suggestion that it should not have been
posted here.
In fact core is not the right group in principle as the matter if of
interest to users. It may be that someone on core may be able to
answer it, however. An interesting conundrum. Those that want the
answer are on this list, those that may know the answer are on core.
My take on this is that it had been previously thought safe to ignore
CSRF on ajax requests because the only requests that could set the
headers that identify a request as xhr were javascript requests. The
browser's single origin policy means that those requests should in
theory not need the added protection of CSRF.
However flash & java applets can apparently make requests with
arbitrary headers and snarfing the session id at the same time
In fact core is not the right group in principle as the matter if of
interest to users. It may be that someone on core may be able to
answer it, however. An interesting conundrum. Those that want the
answer are on this list, those that may know the answer are on core.
For those on this list interested in the answer - the same questions
have now been posted on the core mailing list.
I understood the suggestion to post on core as a better way to get
clarification rather than a suggestion that it should not have been
posted here.
Exactly :).
Ah! Well I was confused, as you replied to my post (with no questions
asked) rather than to Siebert's OP. I was just musing back to the list
with my own considerations on the alert... and had I cross posted to
core, those guys would've got stroppy
