Rails core - Feb 2011 - 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 -
http://weblog.rubyonrails.org/2011/2/8/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

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

> 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

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

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/