Hi there,

As you've identified, the difference between 2.3.10 and 2.3.11, and
between 3.0.3 and 3.0.4, in how they handle invalid csrf tokens is that
the former will raise ActionController::InvalidAuthenticityToken, but
the latter will reset the session.

What we are trying to protect against is the following situation:

* Alice is logged in to Facebook
* Alice visits badsite.com
* Mallory, who owns badsite.com has added some code into the page which
makes a request to facebook.com and posts on Alice's wall.
* Alice visits badsite.com and without her intending it to be, a comment
is posted on her wall

With the current CSRF protection, the following will happen:

* Alice is logged in to Facebook
* Alice visits badsite.com
* Mallory, who owns badsite.com has added some code into the page which
makes a request to facebook.com and posts on Alice's wall.
* Alice visits badsite.com and without her intending it to be, a request
is made to post on her wall
* Facebook detects that there is no CSRF token associated with the
request, and so logs her out by resetting the session
* Then, based on the authorisation rules within the application,
Facebook denies to post on the wall, because the user is not logged in

With the old CSRF protection, the following will happen:

* Alice is logged in to Facebook
* Alice visits badsite.com
* Mallory, who owns badsite.com has added some code into the page which
makes a request to facebook.com and posts on Alice's wall.
* Alice visits badsite.com and without her intending it to be, a request
is made to post on her wall
* Facebook detects that there is no CSRF token associated with the
request and so refuses to serve the request in any way (returns 500)
* So nothing gets posted on the wall

The point is, they are different but both have the effect of preventing
the wall post.

If for some reason you specifically want an exception to be raised in
this situation, you can customise handle_unverified_request, but it
doesn't compromise the aim of the CSRF protection to no raise an
exception, so long as the request is not allowed to go through as
authenticated by the existing session.

Jon

On Fri, 2011-02-11 at 11:28 -0800, Mathijs wrote:
> Hi all,
> 
> I think CSFR protection broke in rails 2.3.11.
> As in: it's turned off now.
> 
> I tried this in rails 2.3.10 and in 2.3.11 and 2.3.11 seems broken.
> 
> >rails csrftest
> >cd csrftest
> >script/generate scaffold post title:string
> >rake db:migrate
> 
> now I visit /posts/new in my browser, use firebug to delete or change
> the authenticity token, and submit the form.
> 
> rails 2.3.11: all fine, new post saved
> rails 2.3.10: ActionController::InvalidAuthenticityToken
> 
> I checked ApplicationController to see if it still contained
> "protect_from_forgery", which is the case.
> I read the announcement for the csrf changes in 2.3.11 and they talk
> about overriding handle_unverified_request for special cases where
> there are other ways for authenticating a user. In this simple case I
> demonstrated though, there is no concept of a user or logging in (or a
> session), so the default action of resetting the session is not very
> useful.
> In my opinion, CSRF protection is about verifying a request. It
> doesn't have anything to do with users/sessions/authentication.
> By default, a faulty request (unprotected/wrong token) should not
> reach the normal controller action code at all, so the main action to
> take when a non-verified request comes in, is to have the
> before_filter chain halt. nothing more, nothing less.
> Extra stuff (like destroying a session) is up to the user (or nice to
> leave in as a default).
> So I think the behavior in 2.3.11 is just wrong, because in the
> example I gave, the forms just get submitted and stuff gets persisted
> to the database.
> It's not clear from the announcement at all that you should now make
> sure the filter chain halts, or that you must protect your actions by
> something that's stored in the session (because that's all that gets
> done when a faulty request hits).
> 
> Maybe I'm just doing something wrong here, please let me know.
> Mathijs
> 

-- 
http://jonathanleighton.com/

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to