CSRF tokens to not match what is in session (Rails 4.1)

[Jason FB]

https://stackoverflow.com/questions/45329731/csrf-tokens-to-not-match-what-is-in-session-rails-4-1

We are seeing an unfortunate and likely browser-based CSRF token authenticity problem in our Rails 4.1 app. We are posting it here to ask the community if others are seeing it too. 

Please be aware that most error reporting tools — like Honeybadger — automatically suppress ActionController::InvalidAuthenticityToken, so you don't normally see the problem in your error reporting tool unless you go out of your way to see it.

Here's the problem, and this is NOT a development issue — it is a production issue that has yet to be diagnosed. 

The exception we see is simply ActionController::InvalidAuthenticityToken on normal logins to our website. Upon careful examination of the authenticity_token sent by the form and the session's _csrf_token (we are using active_record_store as our session_store setting), they just don't match. Upon direct examination, I can conclude only that they are completely different tokens, but I don't know why. 

This is not a simple newbie developer question, please DO NOT answer with basic answers about how the CSRF token needs to be passed from the client to the server, or how to skip forgery protection on my controllers. I am not interested hearing from anyone with either of those two answers: You don't know what you're talking about and you don't understand the depth and complexity of the issue. I am only interested in hearing from people with high-traffic websites who have can confirm this is happening on a non-insignificant number of visitors (and strangely seems to affect certain browsers more often than other browsers.)

We see this problem broadly, maybe about 1-2% of our high traffic website. I see it only in Production, I am unable to reproduce it in development whatsoever. 

I see it on IE 11 and Edge browsers most (you will note Rails 4.1 was released before IE 11 and Edge), but also on Chrome on Android and occasionally mobile Safari too.

[Walter Lee Davis]

I had a similar issue with tokens, and we narrowed it down to people opening a login page and leaving that page open long enough for the token to become stale. There may be a setting to allow this to be longer, but in our case, we had to work around the issue in the controller. (Worked for us because we had another layer of security surrounding the page itself, don't recommend our solution for anyone else.)

Walter

>
> --
> You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-ta...@googlegroups.com.
> To post to this group, send email to rubyonra...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/249c094c-8049-4061-8ba3-b8c38ef1ae1d%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Frederick Cheung]

On Wednesday, July 26, 2017 at 3:24:19 PM UTC+1, Jason FB wrote:

>
> The exception we see is simply ActionController::InvalidAuthenticityToken on normal logins to our website. Upon careful examination of the authenticity_token sent by the form and the session's _csrf_token (we are using active_record_store as our session_store setting), they just don't match. Upon direct examination, I can conclude only that they are completely different tokens, but I don't know why. 

First off, it's normal for those values not to match on rails >= 4.2 ( because of csrf token masking), but that doesn't apply here

One case I've seen is race conditions creating the session: if the browser requests 2 pages at roughly the same time, before the session has been set, then both of those responses will contain a different session cookie, and one of those pages will be using the wrong one. When using the cookie session store this race condition can also happen at the point that the csrf token is first set (I believe this won't happen until you first render a page with a form)

Can you confirm from your logs whether that is a plausible explanation?

Fred