Versions 2.0 to 4.0 of the popular open source Web framework Ruby on Rails are vulnerable to a Web security issue involving cookies that could make it much easier for someone to log in to an app as another user.
According to security researcher G.S. McNamara, Ruby on Rails’ defacto session storing mechanism, CookieStore, stores the entire session hash in the cookie. By doing this session cookies are kept valid for life because there isn’t an entry in a sessions database table the Rails app can use to delete it when logging out.
Instead, because of the way Rails is configured, the app issues a new cookie in the browser to overwrite the one that was created when the user was authenticated. Rails tells the browser to recognize that new cookie – which is all fine and good – but the old one still works, it hasn’t been invalidated and can’t be,by default.
Currently the only way to invalidate cookies would be for the user to change the password or for system administrators “to change the application secret,” neither of which are the norm, McNamara claims.
McNamara, a security researcher based in the D.C. area, detailed the vulnerability yesterday on his personal blog, MaverickBlogging. McNamara points out that the No. 1 concern here is that a malicious user can use a stolen cookie from any authenticated request by the user and log in as them at some point down the line.
As you can imagine, when a user is working on an untrusted network connection or is sharing a computer with someone else, it makes their session extremely vulnerable. Anyone snooping on the network could glean that cookie via XSS or session sidejacking, McNamara writes.
To fix this McNamara suggests users switch to another cookie storage mechanism, one that keeps session information on the server side of the database instead of on the client side. McNamara points out that ActiveRecordStore, which stores hashes in a single column, or any other mechanisms that use a cookie to store a unique ID for each session could be an alternative. In CookieStore, users’ default cookie names are “your_app_session” but after switching, their cookie “will contain a value for “session_id” which corresponds to an entry in your database’s sessions table.
Ruby on Rails introduced CookieStore in 2007 on version 2.0 boasting that it was faster because it retrieved the session hash from a cookie on the client side. The move was actually deemed “controversial” by its developers at the time because of the “security implications” involved: Saved data in a session was stored in clear text.
That was tweaked in 4.0 when Rails moved to encrypt cookies but McNamara insists this doesn’t eliminate the issue at hand.
