Understanding Rails' protect_from_forgery | Hacker News Reader

Understanding Rails' protect_from_forgery

blog.nvisium.com

58 pointsrwiguna18 comments

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

I didn't think I'd be upvoting something that compares Microsoft to Rails, but in this case I totally agree.

I wasn't aware that all this cleverness is taking place instead of raising an error.

Does this also mean that any user who is attacked with CSRF gets logged out of the website?

> Does this also mean that any user who is attacked with CSRF gets logged out of the website?

Nope. It only strips it from the specific request that fails the CSRF validator. A client shouldn't notice.

Exactly. The session information is stripped from the request, but the session is not really "destroyed."

Rails leverages client side sessions, which are signed to prevent tampering. Because of this nature, however, sessions can be constantly replayed.

But most apps move away from client-side sessions and use some kind of a session store (in memory, redis, memcache typically).

In this case, the session.destroy should really destroy the session, meaning the user will be logged out (that's as far as I can tell without actually trying it)

In Rails4 you can do

protect_from_forgery with: :exception

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

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.

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

Aren't these tokens used in addition to cookies?

That's how I've always implemented them (not using Rails). Basically a separate token which must be presented with cookies to perform certain actions. If the cookie identifies a valid session but the token does not pass verification you assume it's a forged request.

While you could use them in such a manner I believe it is more common to use tokens as a replacement for cookies. Typically this is used when you are interacting with a pure Web API/Web Service. Mobile apps, centralized web services, Angular and crew, etc...

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.

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.

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.

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

Another draw back of using tokens instead of cookies is that tokens don't offer any security mechanisms similar to the Secure and HttpOnly flags for Cookies. Without these security controls they're easier for an attacker to intercept.

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

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

excellent and useful post, thanks

Reply on news.ycombinator.com