CSRF Protection Bypass in Ruby on Rails - I don't get it ...

Hi all,

My team and I are finding ourselves a little in the dark about the "CSRF Protection Bypass in Ruby on Rails" vulnerability that was announced yesterday - Ruby on Rails — CSRF Protection Bypass in Ruby on Rails

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

What am I missing?

Thanks Siebert

+1

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

May I suggest posting these questions to the rubyonrails-core ML?

I wasn’t asking a question, I was talking… this is the talk list :-/

Top-posted from Android

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.

Top-posted from Android

Excuses, excuses... :slight_smile:

Colin

Exactly :).

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

Fred

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.

Siebert

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 :smiley:

No prob, I read your wondering comment as an implicit question, but it doesn't matter, mine was just a suggestion.

Few people but Koz have the details of the exploit, that's why I suggested to ask in -core. And as I suspected the announce is vague on purpose.

Few people but Koz have the details of the exploit, that's why I suggested to ask in -core. And as I suspected the announce is vague on purpose.

He's just posted a reply to the question on core saying exactly that.

I did laugh out loud at his final comment: