Question

I’m finding myself in a situation where I could provide a much nicer user experience if I could disable CSRF token checking for an endpoint in my rails app.

The endpoint is a create action (routed to by POST /whatever), that’s behind a devise :authenticate! filter.

Would I open myself up to any additional security risks by disabling the CSRF-protection for that specific endpoint, or can I safely rely on the authentication before_filter to stop the kind of malicious requests that the CSRF token protects against?

Following is a bit more detailed explanation as to why I want to do this if anyone is interested.

My use case is that I basically want to create something very similar to the Facebook likebutton, but this button (unlike the Facebook counterpart) is commonly going to occur multiple times on the same page.

The CSRF protection works fine except for the case where the user visits the page with empty cookies.

In this case rails generates a new session for each of the X number of requests since they are all cookie-less. And, of course, for each new session a new CSRF token is generated and returned in the response to the iframe.

Since the browser only keeps one cookie for the domain, any subsequent requests from each of the iframes will be mapped to the same session, and thus all of the CSRF tokens (except one) are invalid.

The mapping to a single session is nice since the user can be prompted to log in once, and then be mapped to the same log in for each of the subsequent buttons presses – without having to reload the page.

A compromise would be to respond with a 401 Unauthorized, but preserve the session of the rejected request (by overriding handle_unverified_request). This would trigger the sign in popup again, but this time an instant redirect occurs since the user is already signed in.

It would, of course, be best to avoid that flash of the sign in popup window, and thus I’d like to disable the CSRF protection all together for just the create action.

Answer 1

Authenticated requests are precisely what CSRF is about.

What CSRF means is that the attacker convinces the user’s browser to make a request. For example you visit a page hosted by an attacker that has a form that looks like

<form action="http://www.yourapp.com/some_action">
  #for parameters here
</action>

And some javascript on the page that auto submits the form. If the user is already logged in to your app, then this request will pass any cookie based authentication checks. However the attacker doesn’t know the csrf token.

For an unauthenticated request, csrf serves no purpose – the attacker can just go ahead and make the request anyway – they don’t need to hijack the victim’s credentials.

So, short version: disabling csrf protection will leave you vulnerable to csrf style attacks.

What CSRF is really about is making sure the form contains a parameter that an attacker can’t fake. The session is an easy place to store such a value but I imagine you could come up with alternatives. For example if the user can’t control any of the parameters in the form, you could add another parameter which would be a signature of all the other parameters in the form (possibly with some sort of timestamp or nonce to prevent replay attacks). Upon receiving the request you can tell whether the request is from a form you generated by verifying the signature.

Be very careful about this sort of stuff as it is easy to get wrong (and even the big boys get it wrong sometimes.