Snap! Websites make use of sessions to track the user and react accordingly.
There are currently three types of sessions:
The following describes their use. Note that the basic type of a session does not automatically mean it is used by a plugin of that name. It is viewed as a security level for the session rather than the owner of the session.
To avoid a lot of website spam, forms have to be protected. This is done by creating a session for the form. The form is then given a hidden field with that session number. If the number gets modified, is not sent back in the POST, or is being reused, then the number is considered invalid and the form POST fails.
Such sessions are used once and because there are many forms and we need to get such session numbers quickly, we do not offer as stringent randomness in these session numbers. Note that these are still very hard to crack (pretty much impossible), it is just a little less secure than the User or Secure sessions.
As users access Snap! Websites he is assigned a random session identifier which is saved in a cookie as a mean to track the user. The tracking is used to make sure that we can properly propagate some information between server accesses. For example, when you enter a verification code in the registration verification form, you get redirected to the page /verify/<session-id>. If the session identifier is not correct (i.e. you use the same link twice) then an error is generated and the system has to redirect you to the /verify form. By default, when that happens, the error generated when the invalid session identifier was discovered, is lost. The cookie allows us to save that error message in the Cassandra database and reload it on the next access where it gets displayed.
The user sessions track all anonymous users as "/user/" (object path). Anonymous users need to be tracked since the case we just described (an invalid /verify/<session-id> link) can happen to anonymous users.
Anonymous users are not associated to any account making it easier to not save data for a user in such an account when the user has better be virtual. Remember that the users plugin gives you a user key for the current user. If that key is empty, the user is the anonymous user.
User sessions can also be used for anything that needs better protection than offered by a default Form Session. For example, all the forms offered by the users plugin are all assigned the User Sessions.
The user cookie is often reset when the user access the website. Because our sessions are sorted by identifier (a row in Cassandra), it is not cheap to change the session identifier (we'd have to copy the entire row each time.) However, it is possible to generate another number which we call the session random number. That number ensures that if the session gets hacked, both the normal user and the hacker are both immediately logged out. (See Testing The Session Random Number.)
The cookie format is defined as "<session-id>/<session-random-number>". The session identifier will not change until the session times out and a new session is created (which also happens if the session random number does not match for any reason). The random number tracks nearly each access to make sure that the cookie remains as secure as possible (i.e. two people cannot make use of the same session cookie.)
See the attachment, session-fixation.pdf, for more information.
NOTE
The random number cannot change on each and every access because that prevents the client from accessing the website in an asynchroneous manner which often happens when the browser wants to load things such as images, CSS, JavaScript, etc. So instead we change the session once per HTML page access (or so). The session random number has a very short timespan (5 minutes at this time) and once that time is elapsed, it is regenerated which prevents many (long term) session fixations.
Secure Sessions should be used for anything that requires top security on the site. It can also be used for long term sessions because such are more vulnerable to hackers if weak as form sessions are.
At some point we should also look into allowing client certificates. This way we can allow some administrators, for example, to enter their websites only if the device they are using includes the certificate necessary to come in.
Source: Why is no one using certificates?
| Attachment | Size |
|---|---|
| session-fixation.pdf | 404.6 KB |
Snap! Websites
An Open Source CMS System in C++
