As the HTTP protocol is stateless, a logged in client, for example, would have to provide his login name and password for every request he makes, because the server cannot maintain the state during subsequent user's requests. The idea of adding a state to requests is to save information about the exchanged data on the server (the session data), identified by a session identifier.
Rails saves the session data and identifier on the server, and advises the client side to store the same session identifier in a cookie. The cookie looks like the following:
# name = value
_session_id=16d5b78abb28e3d6206b60f22a03c8e8
The session identifier is a 32 bytes long MD5 hash value of the current time, a random number between 0 and 1, the process id number of the Ruby interpreter (also basically a (less) random number) and a constant string (foobar). This keeps the risk of colliding (i.e. occurring twice) session identifiers very low.
Session expiry
In many web applications your session stays only valid either until you log out, or after a certain time after the creation of the session. It is not a good idea to use sessions that never expire, that allows an attacker unlimited time to brute-force a session identifier.Also the number of valid session identifiers rises over time and so rises the possibility of correct guessing of session identifiers.You could limit the time how long a session stays valid by setting the expiry time stamp of the _session_id cookie. However, as cookies in the web browser can be edited by the user, this is not the safest thing to do. It is safer to control the validity of a cookie on the server side.
Every user who accesses the web application creates a new session on the server which can eventually lead to a major performance drop or fll up your disk space and make your server incapable of acting. Not only to save disk space and for performance reasons, but also to let expire old sessions, you should remove old session data from time to time. Sessions are saved to files in Rails' /tmp/sessions, by default. When deciding which session files you can remove, the simplest way is to delete those files which were not changed within the last hour. However in a situation where sessions do not become invalid when the user logs out, or the user always forgets to log out, and an attacker got hold of the session cookie,he could write an automated script to access the web application every 10 minutes, for example. In such a case, the session would never expire.
You should use an automated script (via the cron command on Unix, for example) to clear expired sessions which were not accessed for some time AND the ones which were created a long time ago. Depending on the user behavior and on how much you want to protect the application, you should clear them every 5 minutes through to no more than 20 minutes.
If you use a database to store the sessions, of course the same rules apply.
To be continued…
