51–59 of 59 posts
How about simply storing a logout timestamp in the database when a user logs out? Whenever a user logs in again the timestamp field is cleared and as long as that timestamp field is empty the session cookie is accepted, otherwise ignored and the user is forced to log in again. Basically we still get benefits from storing the session data client side (much less db access) and only store minimal data on the server side…
How about simply storing a logout timestamp in the database when a user logs out? Whenever a user logs in again the timestamp field is cleared and as long as that timestamp field is empty the session cookie is accepted, otherwise ignored and the user is forced to log in again. Basically we still get benefits from storing the session data client side (much less db access) and only store minimal data on the server side…
Another issue is old sessions may be deactivated once the user logs out, but all those old sessions suddenly become valid again when the user logs in again, since the time stamp field is now present. It doesn't prevent the issue the author is highlighting (that sessions can last forever).
I sincerely hope that nobody was using the CookieStore in deployment. I think everybody should know by now that cookies are not safe or secure storage for data.
What your forgetting is the reason people use frameworks such as Rails - so they don't have to care about these types of details. I agree that simply storing everything in the cookie is wrong, and Rails should never have been doing this - hell, even CodeIgniter (PHP) has DB based sessions. But most Rails devs (myself included) are just about getting shit done, we don't know everything that's going on under the bonnet…
And FYI CookieStore is just the default, because it's convenient and require no dependency. But you're juste a line of configuration away to switch the sessions inside your DB or Memcache or whatever.
This feels less like a framework bug for me than an app bug -- an impressively common app bug, I'll grant you, but an app bug nonetheless. Rails doesn't ship with user management. It's pretty upfront about that, and the docs tell you to roll your own since it is easy, and the community will tell you to use Devise since that will save you time since you'll be doing repetitive work for substantially all apps otherwise.…
So using Devise gets around this issue right?
Misleading. It's not a problem of CookieStore or Rails, it's the problem of HTTP. Changing session store to a database or memory store won't fix it: a session id is still required on the client side, then your session is still hijacked because the attacker still gets the session id. You may want to make the session id change after each request, then you are re-inventing TCP and ruining user experience. If the attacke…
I posted about this on HN originally here: https://news.ycombinator.com/item?id=6458433
This is in the Ruby On Rails Security Guide: http://guides.rubyonrails.org/security.html#session-fixation The author isn't telling people anything new, so it shouldn't take the form of an announcement.
Earlier quoted context omitted.
The solution I use in my own application is for each cookie that gets set to be a distinct, random shared secret that is mirrored in a database table. The shared secret is the combination of a near-random string of bytes generated by a hash of numerous things, plus a unique ID generated upon insert into the database table. The secret survives in the table until the user chooses to sign out, or until the cookie expire…
>..random shared secret that is mirrored in a database table. Isn't the point of using a cookiestore to avoid hitting the database and thus eliminating the need for the painful session/state maintenance across multiple nodes? Your solution looks more like a DIY security solution to me, (please correct me if I'm wrong) and I would take major precautions in gambling with security-related functions of a framework. P.S I…
If session/state maintenance across nodes is painful, the solution isn't to trust the web browser, it's to make such maintenance much less painful. For example, you can use a cache server (like ehcache) to store session state. Or you can use smarter load balancers (like haproxy) to minimize node hopping.
A cookie is an authentication credential, just like a username and password combination. If you can't invalidate an authentication credential on the server side, your solution is an instant fail.
Time to switch web hosts.