

Understanding Rails' protect_from_forgery - rwiguna
http://blog.nvisium.com/2014/09/understanding-protectfromforgery.html

======
Someone1234
I don't LOVE the default implementation in Rails 3.2.19 or Rails 4. It seems
like they're trying to be overly clever (clearing authentication info but
letting the request go through) when, as shown here, that opens up potential
security lapses while not really offering anything.

In Microsoft's MVC they simply just throw an exception when a CSRF token
mismatch occurs. That to me is rational. It stops the request dead in its
tracks, there's no gotchas and no potential exploits in the future (that might
be application specific).

I guess it seems like Rail's approach is depending on a blacklist (i.e. "here
are things a CSRF failed request cannot contain, everything else is just
fine") whereas Microsoft's approach is just to assume the whole request is
bad, then let the application author manually write in overrides if they know
better (or to just pick up the exception and handle that).

Frankly the author's solution is what Rails should be doing:

    
    
         def handle_unverified_request
             raise(ActionController::InvalidAuthenticityToken)
         end

~~~
neerajdotname2
In Rails4 you can do

protect_from_forgery with: :exception

This is also the default value if you generate a brand new rails application.

~~~
yourmysin
You're correct. Thankfully Rails4 provides the option of doing this by
default, but in my opinion, it should still be default behavior, and should
not require an option to the protect_from_forgery method.

Unfortunately, the Rails team have stated that it was introduced as an option,
rather than default behavior for backwards compatibility reasons. It leaves me
to wonder how many applications would actually have an issue if the default
behavior was to generate an exception.

------
dmix
One of the benefits of using token-based auth over Cookies is that you don't
have to worry about CRSF:

[https://auth0.com/blog/2014/01/07/angularjs-
authentication-w...](https://auth0.com/blog/2014/01/07/angularjs-
authentication-with-cookies-vs-token/)

~~~
Someone1234
One of the drawbacks is that they only really work for specific kinds of sites
(e.g. single-page sites, or sites which are utilising a "wizard" workflow).

If a user would ever open a second tab for your site then that entire model
breaks down (as they would have to re-authenticate each and every time). Ditto
every time a user leaves and returns.

For example, if you ran a shopping site this kind of token-based tracking
would work fine for the checkout wizard-workflow, but not really for the
actual store (e.g. recommendations, shopping basket, dynamic shipping
calculation based on location, etc).

It definitely has its uses. But those uses are still highly limited.

~~~
dmix
Tokens are typically stored in localStorage, so the app doesn't have to be a
single-page app. I'd still force reauth before important events such as credit
card purchases or changing email addresses but returning users or opening a
new tab session does not require reauth.

~~~
jerf
If tokens are automatically stored in localStorage and automatically pulled
out of it, aren't you right back to being open to CSRF? That doesn't seem
meaningfully different than cookies.

~~~
dmix
How can they do that via CSRF? The attacker would need access to javascript on
the victim page to have the token pulled from localStorage, append the token
to the request in order to successfully submit a form. This is protected via
SOP. GET requests do not return the localStorage data... nor do GET request
modify any data, unless poorly programmed. Form POST requests that get
submitted by an attacker are missing the token in the request, where with
cookies it gets appended automatically.

Token auth is vulnerable to XSS attacks, but not CSRF. So additional
precautions can be added.

But I do tend to agree with Egor Homakov where XSS is a serious risk to use
auth token stored via httpOnly cookie:
[https://twitter.com/homakov/status/298744658706714624](https://twitter.com/homakov/status/298744658706714624)

------
neerajdotname2
I blogged about it at [http://blog.bigbinary.com/2012/05/10/csrf-and-
rails.html](http://blog.bigbinary.com/2012/05/10/csrf-and-rails.html) .

------
sb8244
I saw Ken present on this in Atlanta the other night and was wondering about
with: :exception in Rails 4. Great talk and article.

------
geoffroy
excellent and useful post, thanks

