如何将会话中的身份验证数据存储在较低级别？

Question

Regardless of a language and framework, how does this work in a low level -- putting a variable into a session to authentication a user?

put_session(curr_connection, :current_user, user.id)

Does user user saved in a cookie? On a client? Then what prevents a user of a browser change it by storing id of any user they desire and get authenticated on behalf on that user? Or does user.id get saved on a server and on a client we have only a loooooong session id , in a cookie or in url?

Answer 1

The short answer is it depends. All languages / frameworks have their defaults, Ruby on Rails for example stores it in a cookie by default, PHP stores it on the server, etc. But in pretty much all of these languages, you can change your cookie store to whatever you want.

Some options (there may be more):

• Cookies - In this case the cookie is encrypted before sent to the client. The key used for encryption is some sort of an application setting. This is somewhat secure, because even if session values are stored on the client, a user still cannot see or modify them, because he does not have the application key. The advantage of this is that it's very simple and requires zero setup, disadvantages include this being less secure than other solutions, and also the amount of data that can be stored in a cookie is limited.

• Server memory - In this case, a cryptographically random session id is sent to the client, all session data is stored in the application server memory, identified by the session id. The advantage is that it's not written to disk and also not sent to the client. Disadvantages include the session data being lost when the application server is restarted.

• Server Filesystem - The traditional approach (kind of), session data is stored in files so that it's persisted across application server restarts. In this case, access control to these files is key, but usually taken care of by the language or framework.

• Server SQL Database - The traditional heavy-weight approach, all session data is stored in a relational database on either the application server or a separate database server. The advantage is that you have direct control to session contents of any suer, not just the logged on one (for example it's easy to do forced logout for an admin by removing session entries from the database). This same thing can also be a disadvantage in case of an application level attack. Also operation is more expensive.

• Server NoSQL Database - About the same as a relational database, but a non-relational database like Redis can also be used. One drawback can be that access control in Redis is not very strong to say the least.

• Session Service - In some enterprise applications you may want to implement some kind of a session service (RESTful or else). Obviously this just pushes the problem one layer back, session data must still be stored somewhere with one of the options above.

Your language or environment probably already supports some of these, and if you want one that is not supported out of the box, you can implement your own. However, session management is tricky business, it's quite easy to make it vulnerable. OWASP has a nice session management cheat sheet to consult.