> The fix: Rails 4 changed the default session store to be encrypted. Users can no longer decode the contents of the session without the decryption key, which is not available on the client side.
Seriously? So they've added a whole more complexity to the session-layer just because people abused it to store "secret" data? Newsflash: If you don't want the client to be able to read the data, DON'T SEND IT TO THE CLIENT AT ALL. Way more secure than encrypting it.
It isn’t just storing secret data that’s a potential problem:
...even if a user’s session does not contain sensitive data, it can still create risk. By decoding the session data, an attacker can gain useful information about the internals of the application that can be leveraged in an attack. For example, it may be possible to understand which authentication system is in use (Authlogic, Devise, etc.).
Of course, I agree with you that the goal should not be to add sensitive information to session cookies. But if it's possible to encrypt, and it might provide an attacker with information, why not? I'm interested in the trade-offs. Here's the pull that adds it, I believe: https://github.com/rails/rails/pull/8112/commits
You can quite happily set individual cookies[1] in a very similar way to sessions. You can also output or log the session object on any web page you want to.
If certain data being user-visible is a feature rather than a side effect, the session was the wrong place for you to be putting it.
In this case the "I" in question is the user for an arbitrary website. Obviously this is not a huge issue, but it's worth noting that this will make many sites a little harder to reverse-engineer. Of course many people might see this as a plus rather than a minus, so make of it what you will.
Session (at least ASP.NET session) and ViewState are pretty different though. ASP.NET session is on the server, and looked up via a key fom the session cookie (sent to the client). ViewState is sent to the client to allow...well to allow ASP.NET pages to be really horrible and heavy, but also to allow it to know what the 'previous' value for controls was so it can raise change events etc.. Serializing ASP.NET session out to the client is definitely weird, and would not be a normal thing to do. Is rails 'session' being discussed more analogous to ASP.NET viewstate?
nope, I think that rails session sounds probably like ASP.net session. At any rate, rails session is like PHP session (i am not familar with asp.net).
But yes, the default Rails implementation does not store the session on the server but a key in a cookie. Although you can optionally do that, storing the actual session data in the rdbms, or other server-side places. But the default Rails implementation, yes, actually stores the session info itself in cookies.
One of the benefits of this is, when you've scaled out/load balanced your app servers to multiple instances, they don't need to share a session store somewhere, they each get the entire session via cookie. There are also other disadvantages, including with synchronization.
But also including that your session data is now visible to the client when it wasn't before. So, yeah, encrypting the data is one way to change the trade-off calcuation and make it work for more (but not all) apps/use cases, why not?
It actually doesn't increase the complexity much. If you're storing session data in cookies to begin with, you already needed to crypto sign them, to avoid tampering. If you're involving crypto in there anyway, and a secret key anyway, might as well (as a configurable option, sure; which is the default configuration, why not) tell the crypto library to encrypt+sign/decrypt+verify instead of just sign/verify, why not.
Seriously? So they've added a whole more complexity to the session-layer just because people abused it to store "secret" data? Newsflash: If you don't want the client to be able to read the data, DON'T SEND IT TO THE CLIENT AT ALL. Way more secure than encrypting it.