Session hijacking

The term Session Hijacking refers to the exploitation of a valid computer session - sometimes also called a session key - to gain unauthorised access to information or services in a computer system. In particular, it is used to refer to the theft of a magic cookie used to authenticate a user to a remote server. It has particular relevance to web developers, as the HTTP cookies used to maintain a session on many web sites can be easily stolen by an attacker using an intermediary computer or with access to the saved cookies on the victim's computer (see HTTP cookie theft).

Analysis

Many web sites allow users to create and manage their own accounts, logging in using a username and password (which may or may not be encryped during transit) or other authentication method. In order that the user does not have to re-enter their username and password on every page to maintain their session, many web sites use session cookies: a token of information issued by the server and returned by the user's web browser to confirm it's identity.

If an attacker is able to steal this cookie, they can make requests themselves as if they were the genuine user, gaining access to priviledged information or changing data. Of course, session hijacking is not limited to the web; any protocol in which state is maintained using a key passed between two parties is vulnerable.

Methods

There are four main methods used to perpetrate a session hijack. These are:

• Session fixation, where the attacker sets a user's session id to one known to him, for example by sending the user an email with a link that contains a particular session id. The attacker now only has to wait until the user logs in.
• Sniffing is another way to obtain illicit session keys. To perform this attack, the attacker needs priviledged access to a computer system between the two communicating parties. From here, using a packet sniffer program, they can observe the cookie being passed.
• A second way is by taking advantage of Cross-site scripting vulnerabilities in the application. By tricking the user's computer into running code which is treated as trustworthy because it appears to belong to the server, the attacker can obtain a copy of the cookie or perform other operations.
• Finally, the attacker can simply attempt to steal the session key by, for example, obtaining the file or memory contents of the appropriate part of either the user or the server's computer.

Prevention

Methods to prevent session hijacking include:

• Use of a long random number or string as the session key. This reduces the risk that an attacker could simply guess a valid session key through trial and error.
• Regenerating the session id after a successful login. This prevents session fixation because the attacker does not know the session id of the user after she has logged in.
• Encryption of the data passed between the parties; in particular the session key. This technique is widely relied-upon by web-based banks and other e-commerce services, because it completely prevents sniffing-style attacks. However, it could still be possible to perform some other kind of session hijack.
• Some services make secondary checks against the identity of the user. For example, a web server could check with each request made that the IP address of the user matched the one last used during that session. This does not prevent attacks by somebody who shares the same IP address, however, and could be frustrating for users who's IP address is liable to change during a browsing session. Therefore, a better method is to store and check a hash value of the user's browser string.
• Alternatively, some services will change the value of the cookie with each and every request. This dramatically reduces the window in which an attacker can operate and makes it easy to identify whether an attack has taken place, but can cause other technical problems (for example, preventing the back button from working properly, on the web).

Use of SecurID card, or other token based secondary authentication is useless as protection against hijacking, as the attacker can simply wait until after the user authenticates, then hijack the session.