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. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk@googlegroups.com To unsubscribe from this group, send email to rubyonrails-talk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
