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 -

  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

On 9 February 2011 10:47, siebert [email protected] wrote:

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

What am I missing?

+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…

On Wed, Feb 9, 2011 at 3:11 PM, Michael P. [email protected]
wrote:

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?

On 9 February 2011 15:26, Michael P. [email protected] wrote:

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

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

Top-posted from Android

On Feb 9, 2011 2:52 PM, “Xavier N.” [email protected] wrote:

On Wed, Feb 9, 2011 at 3:11 PM, Michael P. [email protected]
wrote: >
On 9 February 2011 10:…
May I suggest posting these questions to the rubyonrails-core ML?

– You received this message because you are subscribed to the Google
Groups
“Ruby on Rails: Talk”…

On Feb 9, 10:47am, siebert [email protected] wrote:

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
-http://weblog.rubyonrails.org/2011/2/8/csrf-protection-bypass-in-ruby

  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?

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

On Wed, Feb 9, 2011 at 4:47 PM, Colin L. [email protected]
wrote:

On 9 February 2011 15:26, Michael P. [email protected] wrote:

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.

Exactly :).

On Wednesday, February 9, 2011, Michael P. [email protected]
wrote:

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.

On 9 February 2011 16:18, Xavier N. [email protected] wrote:

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:

On 9 February 2011 15:47, Colin L. [email protected] wrote:

Top-posted from Android

Excuses, excuses… :slight_smile:

yeah… I do try to not post from my phone, but sometimes you just
wanna bash out a reply. Still… knowing I’m in the wrong is no excuse
for doing it - am appropriately chastened :frowning:
Why couldn’t Google have just written a little extra functionality
into their OS? hrumph…

On 9 February 2011 21:25, Xavier N. [email protected] wrote:

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:

On 9 February 2011 21:06, Michael K. [email protected]
wrote:

If you have API requests which do rely on the session, then you’re
fucked as that’s a CSRF request by definition.

:smiley: