Security problems with CookieStore and CSRF protection

rubyonrails-talk
1

Dear Rails community, As part of a programming languages/security research group at the University of Maryland, we are building some static analysis tools for Rails applications. These tools work by taking formally specified properties of interest, and then analyzing code to verify that those properties indeed hold. Using these tools, we found some security vulnerabilities in Rails, and we would like to get a sense of how important these are in practice.

1. Using CookieStore opens the door to "replay attacks", whose importance is, we feel, underestimated. A dishonest user can replay an old session to fool the server, of course; but more critically, it may be possible for an attacker to steal a cookie from an honest user after the latter is authenticated, and replay that session. The obvious fix is to include nonce-checking for every session object to ensure its freshness, but this may require storing nonces in the database, which may go against the point of using CookieStore. Are most users of Rails aware of this problem? How many actually use ActiveRecordStore instead of CookieStore? If the latter is by far the most common mode, then we believe that default should be ActiveRecordStore, as it is much less susceptible to this problem. (Session ids are usually not stateful in a bad way.)

2. The CSRF protection, at least in Rails 2.2.2, seems too weak. Rails comes close to implementing a fix, by embedding and checking hidden tokens (for POST requests). But it is well-known that for such a fix to work, the tokens should be session-specific. Unfortunately, we found that the implementation in 2.2.2 can return the same token even if, e.g., session[:user] is different. This is bad, since an attacker may not be an outsider: it can reasonably have an account with the server, and if it gets back a token which it can then embed in forms used by other, honest users, then it can execute CSRF attacks!

The common theme behind these attacks is that it may be too simplistic to view the world as divided between a (trusted) server and an (untrusted) attacker. Users should be isolated from other users just as well, be it for protection against CSRF, or protection against session replay.

Do you, as users and developers of Rails, think these are issues important enough to worry about? We would like to hear any counter- arguments.

Best regards, Avik Chaudhuri. [http://www.cs.umd.edu/~avik\]

2

1. Using CookieStore opens the door to "replay attacks", whose importance is, we feel, underestimated. A dishonest user can replay an old session to fool the server, of course; but more critically, it may be possible for an attacker to steal a cookie from an honest user after the latter is authenticated, and replay that session. The obvious fix is to include nonce-checking for every session object to ensure its freshness, but this may require storing nonces in the database, which may go against the point of using CookieStore. Are most users of Rails aware of this problem? How many actually use ActiveRecordStore instead of CookieStore? If the latter is by far the most common mode, then we believe that default should be ActiveRecordStore, as it is much less susceptible to this problem. (Session ids are usually not stateful in a bad way.)

All true, but I've always thought that at the point where people can steal your cookies then you're a bit shafted anyway. The replayability does make it a bit worse than just stealing a session cookie, but then a lot of sites have a 'remember me' cookie, why bother stealing the session when you could steal that ?

2. The CSRF protection, at least in Rails 2.2.2, seems too weak. Rails comes close to implementing a fix, by embedding and checking hidden tokens (for POST requests). But it is well-known that for such a fix to work, the tokens should be session-specific. Unfortunately, we found that the implementation in 2.2.2 can return the same token even if, e.g., session[:user] is different. This is bad, since an attacker may not be an outsider: it can reasonably have an account with the server, and if it gets back a token which it can then embed in forms used by other, honest users, then it can execute CSRF attacks!

That's seems odd - glancing at the code it would seem that in 2.2.2 the secret is a digest of the session_id and a secret (for non cookie stores) and in the case of a cookie store a digest of a random identifier and a secret. How were you able to get it to return the same token for 2 different sessions ?

Fred

3

Hi Fred,

> 2. The CSRF protection, at least in Rails 2.2.2, seems too weak. Rails > comes close to implementing a fix, by embedding and checking hidden > tokens (for POST requests). But it is well-known that for such a fix > to work, the tokens should be session-specific. Unfortunately, we > found that the implementation in 2.2.2 can return the same token even > if, e.g., session[:user] is different. This is bad, since an attacker > may not be an outsider: it can reasonably have an account with the > server, and if it gets back a token which it can then embed in forms > used by other, honest users, then it can execute CSRF attacks!

That's seems odd - glancing at the code it would seem that in 2.2.2 the secret is a digest of the session_id and a secret (for non cookie stores) and in the case of a cookie store a digest of a random identifier and a secret. How were you able to get it to return the same token for 2 different sessions ?

According to the code for 2.2.2 (and also the current version), the token is not inherently "user-specific"; it may remain the same even when other session fields change. Thus, the app _must_ use reset_session when a different user logs in to force a different token to be computed. (In particular, just clearing out the relevant fields, e.g., session[:user_id], is not enough, since session[:_csrf_token] or session[:csrf_id] remains set.) Otherwise, we may get the following scenario, for example.

1. Attacker logs into a public computer, gets CSRF token from a page returned by the server, includes a form with that token on a popular website he controls, and leaves without logging out.

2. Honest user logs into the same computer (and say reset_session is not used, so the token field in the session remains set and doesn't change). He opens the popular site on the side, and accidentally causes the malicious form to be sent.

I discussed this issue with Michael Koziarski; he claims, perhaps rightly so, that this is ultimately a session fixation attack, and the doc already advises use of reset_session in that case. True, but I believe that the doc is inadequate in this case; clearly this attack uses CSRF, and the fact that protection in this case requires protect_from_forgery as well as reset_session is not clarified enough.

Best, -Avik.

4

Ah, with you know - thought you were saying that two completely unrelated sessions might end up with the same auth token.

Fred