This is the risk rating from OWASP:
|Threat Agents||Attack Vectors||Security Weakness||Technical Impacts||Business Impacts|
|Consider anonymous external attackers, as well as users with their own accounts, who may attempt to steal accounts from others. Also consider insiders wanting to disguise their actions.||Attacker uses leaks or flaws in the authentication or session management functions (e.g., exposed accounts, passwords, session IDs) to impersonate users.||Developers frequently build custom authentication and session management schemes, but building these correctly is hard. As a result, these custom schemes frequently have flaws in areas such as logout, password management, timeouts, remember me, secret question, account update, etc. Finding such flaws can sometimes be difficult, as each implementation is unique.||Such flaws may allow some or even all accounts to be attacked. Once successful, the attacker can do anything the victim could do. Privileged accounts are frequently targeted.||Consider the business value of the affected data or application functions.
Also consider the business impact of public exposure of the vulnerability.
Session fixation is an attack where the attacker is able to somehow preset the session id of antoher user. When that user logs in
the attacker already has the valid session id and can use that to log in. Typically this is happening in applications that make
the session ID a part of the URL:
This is a bad pattern. SessionIDs should never be a part of URLs. Furthermore it's important to always change the session ID when the authentication/autorization level is changing - typically during login/logout.
If the attacker steals the session of another user, the attacker can now access whatever the user has access to, because from the server side the two is the same. There are typically two ways of stealing sessions:
A few years back lots of websites like twitter and Facebook would only protect the login with https when the username and password was transferred. After the login, the connection would go back to http. This is a bad pattern. After login the session ID becomes a temporary replacement for your username and password, and thus we want to protect from anyone listening in. To achieve this we can make sure the browser never sends our session cookie over http, but setting the
Secure flag on the cookie. This will instruct the browser never to send the cookie in http requests.
The next thing we need to do is to protect the application from Cross Site Scripting as explained in A2 - Cross Site Scripting. If an attacker can
insert script into our page, the attacker could access
document.cookie and steal the session cookie from there. A secondary protection mechanism we can
docment.cookie. The browser will still send it in requests back to the server, but it will just not be available directly in JS.
It's of key importance that the server side component generating session IDs is using a cryptographically secure random function to do so. If the attacker is able to predetermine what the next session id is, the attacker could simply try different session IDs, and would at some point find a valid authenticated session, because a user logged in and got that very same session ID. I recently tested Node.js Connect's session ID generation using Burp Suite's sequencer, and Connect seems to do a decent job (the rating from Burp Suite was: Excellent).
Sessions should always time out after a certain period of time. Some sites use a sliding expiration, where the user is logged out if the user with the active session has been inactive for some time. Other sites use an absolute expiration, where the login is valid for a maximum of say 30 minutes. For high value sites like online banking it's probably a good idea to use both a sliding and absolute timeout. The rationale behind session timeout, is the fact that a session should be a temporary replacement for the username and password, not a permanent one. There are a couple of reasons why this is important.
If the user leaves his device or computer unattended for some time, a time out will make it harder for any attacker stealing the device to reuse the existing sessions. This can of course be partially mitigated by automatically locking the device or computer after a given period of inactivity, but this will not stop a determined attacker.
The second reason is if the session is somehow stolen, not having an absolute expiration, will allow the attacker to use that session as long as he wants - or at least until the user logs out (which many users rarely do).
However in my opinion the drawbacks outweigh the positive aspects. First of all we need to make sure the client side code cannot change the session data, because the server now inherently has to trust this cookie in later decisions. This could easily lead to a broken authentication scenario, where the user logs in as user "joesmith" and then changes the username in session to be "admin". What this means, is that the cookie needs to be signed by the server and only the server should be allowed to change it. And this can be a bit hard to get right. Naive approaches of using something like
MD5(secret key + data) has been proven susceptible to length extensions attacks. Typically the developer should use something like HMAC. And we have to make sure to check the signature on the server side on each and every request to the server.
The next problem is the ability to have the session timeout. A naive approach of setting a timeout for the cookies is of course insufficient. This timeout can easily be increased by the attacker. So the timeout timestamp needs to live inside the signed session data, and be checked on the server side for each and every request.
The biggest problem is however that there really is no way to log a user out. If the server side has no concept of which sessions exist, neither can it mark one as logged out. If the attacker is at some point able to steal a valid session, that session is valid in itself because of the signature, and thus the server will happily accept it until it expires. So a logout would typically mean deleting the cookie on the client side, and that's of course not sufficient if anyone else has a copy.
In addition to the logout problem mentioned in the previous section, there are other logout related problems as well. Simply deleting the session cookie on the server side is not sufficient. The session should always be terminated on the server side.
Also HTML5 allows us to store more data on the client side in the Web Storage. This can greatly improve performance, but can also lead to some problems. First of all, if I'm logged in and my private data is stored in Web Storage, what happens to that data when I log out. Will the next user on the same device or computer see my data? Typically the application will use either localStorage or sessionStorage or both. In my opinion localStorage should be used for generic data like compiled JS templates or other things you may want to cache, while sessionStorage could be use for private information. However we will still need to clear out the sessionStorage during logout (and session timeout if possible). The reason is that the sessionStorage is not tied to the authenticated session in any way. SessionStorage simply means it's deleted when the browser is shutdown or restarted, which a lot of users never do unless they have to (due to a reboot or browser upgrade).