11–20 of 59 posts
Earlier quoted context omitted.
It's a pretty widespread practice. I think it's the Rails default.
Sure, it's the default, but don't people realize never to trust clientside data? I don't know if CookieStore is signed or not, but I generally assume even if I sign the data it's not safe. It's not that hard to just set up a Redis or whatever store to handle stuff like this, I never understood why people whouldn't bother.
>Separately, it is a good design for your Web app to require that the user supply their current password before changing sensitive fields such as password or email address. If the CookieStore-stored session were to be hijacked, the malicious user could change the user’s password:
I don't see why that's the case - presumably, if I'm requiring the user's password to perform sensitive account changes, then the hijacking user will not be able to perform those changes. It's not like the CookieStore contains a plaintext password or anything.
This is ultimately a simple replay attack, which any application using a server-side session would be equally vulnerable to. The effects of that replay attack are definitely worse with CookieStore, because a user cannot subsequently invalidate their session from the server side (although the app owner can obviously invalidate every session).
This could be solved relatively easily by providing a per-session token which can be invalidated, but at that point I guess you'd have to question why you're using a cookie-stored session anyway.
Earlier quoted context omitted.
It's a pretty widespread practice. I think it's the Rails default.
Sure, it's the default, but don't people realize never to trust clientside data? I don't know if CookieStore is signed or not, but I generally assume even if I sign the data it's not safe. It's not that hard to just set up a Redis or whatever store to handle stuff like this, I never understood why people whouldn't bother.
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.
Earlier quoted context omitted.
Sure, it's the default, but don't people realize never to trust clientside data? I don't know if CookieStore is signed or not, but I generally assume even if I sign the data it's not safe. It's not that hard to just set up a Redis or whatever store to handle stuff like this, I never understood why people whouldn't bother.
How would you do it with redis exactly?
All session stores use a cookie to store a unique ID for each session...For most stores, this ID is used to look up the session data on the server, e.g. in a database table.
(obviously you'd substitute Redis for the database table mentioned above)
Earlier quoted context omitted.
Sure, it's the default, but don't people realize never to trust clientside data? I don't know if CookieStore is signed or not, but I generally assume even if I sign the data it's not safe. It's not that hard to just set up a Redis or whatever store to handle stuff like this, I never understood why people whouldn't bother.
Cookie store has always been signed and in rails 4 it's encrypted.
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.
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 we don't want to.
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…
I guess it reduces the attack surface (the genuine user must be logged in at the same time as the attacker) but doesn't completely solve the problem.