Ruby on Rails Web applications versions 2.0 through 4.0 are by default vulnerable to an oft-overlooked Web application security issue: Session cookies are valid for life. The fix is to configure your Rails app to store most session information on the server side in the database.
Should this receive more attention in the Rails Guides, or maybe there should be a post on the Riding Rails blog explaining what the view of the Rails core team is on this matter (and the reasoning behind it)?
I know that there’s little that can be done about this on the code side of things without changing away from using CookieStore as the default session storage mechanism…
Isn’t this a common problem with every other framework that uses cookies for sessions? I find it a bit hard on Rails given that point.
I remember doing some successful tests on Facebook (PHP) with FireSheep, and I believe (please tell me if I’m wrong) that it gets fixed by using SSL to prevent the session data to be retrieved in the first place.
Ruby on Rails Web applications versions 2.0 through 4.0 are by default vulnerable to an oft-overlooked Web application security issue: Session cookies are valid for life. The fix is to configure your Rails app to store most session information on the server side in the database.
Should this receive more attention in the Rails Guides, or maybe there should be a post on the Riding Rails blog explaining what the view of the Rails core team is on this matter (and the reasoning behind it)?
G.S wrote to the security list with this shortly after publishing his blog post, I responded to him there but can do it here too. The behaviour mentioned is a limitation of the underlying storage mechanism that the CookieStore uses, there’s simply no way to do server side invalidation when there’s no server side storage. Most applications have the same or similar issues with values stored in signed cookies such as remember-me tokens.
There are certainly applications where the lack of server-side invalidation is severely problematic, which is why we ship with several alternative session stores. However it’s true that we could probably do a better job of documenting those limitations in the guides and the api documentation.
I know that there’s little that can be done about this on the code side of things without changing away from using CookieStore as the default session storage mechanism…
Switching the default store to something else is definitely something we could consider, however each of the alternative stores has their own set of downsides. The AR Store generates huge tables and the memcache store requires a separate long-running process.
In terms of changes to the CookieStore we could include expiry information in the payload and refuse to accept cookies which have expired. However this will have other issues as people’s sessions which previously never expired will suddenly start expiring.
So I guess in short, yes we should improve the documentation to make the risk clearer, we should also try and expose a time limit that users can use to work around the issue. But if this issue is important for your application, you should switch your session store to one of the alternative stores as that’s the simplest and most reliable way to avoid the issue entirely.
