2010-11-17

What is "session hijacking"? What are its security threats? How can web developers avoid it?



Session hijacking is the act of exploiting a valid user session and gaining unauthorized access to information or services after successfully obtaining or generating an authentication session ID. Session ID and information that are unique to a particular user's Web application session are usually saved in the HTTP cookies of the user's computer and these HTTP cookies can be easily stolen by an attacker using an intermediary computer while the session is still in progress. Thus, this makes it unsafe for applications which use the stateless HTTP to store the session parameters that are relevant to the user when the user logs into the application. Before tackling the problem of session hijacking, we should first get to know the usage of session in a Web application, how session hijacking can be carried out and what its security threats are which will be discussed in the following paragraphs.

A session is a succession of interactions between two communication end points (usually between the client's computer and the Web server) that occurs during the span of a single connection. When a user logs into an application and passes through the authentication, a session is created on the server to maintain the state for other requests originating from the same user. Applications use sessions to store parameters which are specific to the user in a particular login session. The session is kept "alive" on the server as long as the user is logged on to the system and the session is only destroyed when the user logs out of the system or the session is timed out after a predefined period of inactivity. The application parameters for the user will be deleted from the allocated memory space once the session is destroyed.

Sessions are independent of each other and are uniquely identified by a session ID which is usually a long, random and alpha-numeric identification string that is transmitted between the client's computer and the server. Session IDs are commonly stored in the HTTP cookies, URLs and the hidden fields of HTML Web pages. A URL containing the session ID will usually look something like this:

http://rom1023.blogspot.com/view.do?sessionID=7AD30725112120802

In a HTML Web page, a session ID may be stored as a hidden field of a form:

<input type="hidden" name="sessionID" value="7AD30725112120802">

There are problems with the session ID. If the algorithms used to generate the session ID are based on easily predictable variables such as time or IP address and that encryption is not used (typically SSL) during transmission of session ID, the session ID may be susceptible to stealing by attackers which may then lead to session hijacking.

There are many methods for hijacking sessions:
  • Session fixation – the attacker tricks the user into using a session ID that is known to him by for example sending the user an email with a link that contains this session ID and wait for the user to log into this particular session.
  • Session sidejacking – the attacker uses packet sniffing to read network traffic between two parties to steal the session cookie especially in situation when no encryption is used in the web site to prevent attackers from viewing the session data.
  • Cross-site scripting – the attacker tricks the user's computer into executing a malicious script or code which is treated as trustworthy as it appears to belong to the server to redirect the private user's information including cookies to the attacker.
The above are just part of the many methods that can be used to hijack sessions in the modern world. Pathetically, it just demonstrates how a session can be easily hijacked even without the need to be a skillful attacker. As a result, it is important that we examine the security threats of session hijacking and develop methods and preventions to protect against the session attack by the hackers.

Some of the security threats of session hijacking are that attacker may easily gain complete access to the private data of the user whose session has been hijacked and is permitted to perform operations on behalf of the user which may be extremely harmful especially if the system deals with money. The hijacked user may suffer from financial loss if the attacker is able to perform operation such as money transfer or use the gained private data for other illegal purposes. Also, the company which supports the hijacked system may be accounted for the security bridge and required to pay a large sum of compensation.

Moreover, the system may suffer from service attack if the attacker gains authorized access to the system and starts bombarding the server with requests to consume all available system resources or by passing malformed input data that can crash an application process. Elevation of privilege may also occur during session hijacking when the attacker assumes the identity of a privileged user to gain access to a highly privileged and trusted process or account. As a result, all these unwanted security threats that may arise due to session hijacking must be prevented in order to provide a secure and trustworthy application for users to use.

There are many methods to prevent session hijacking which can be followed by web developers. Some of these methods are summarized as below:
  • Use a long, random and unpredictable alphanumeric string as the session ID as this can reduce the risk that an attack can guess a valid session ID by trial and error or brute force attacks.
  • Regenerate the session ID after a successful login to prevent session fixation since the attacker will not know the session ID of the user after logged into the system.
  • Encrypt the important data such as the session ID passed between the client's computer and the server on the network by using technology such as SSL to prevent sniffing style of attacks.
  • Make secondary check against the identity of the user for each request made on the server. The check can be based on investigating the consistency of the IP address of the user between the current and the previous requests and prevent the user from browsing if the IP address does not match with the previous one. The drawback of this method is that it does not prevent attacks by somebody who shares the same IP address.
  • Change the value in the HTTP cookies with each and every request to prevent the attackers from retrieving the session data through the HTTP cookies. However, this may not be applicable for some applications which depend on the session parameters that passed between pages.
  • Expire the session as soon as the user logs out and clear any session parameters that may have stored in the HTTP cookies.
  • Set timeout and reduce the life span of a session or a cookie to prevent accumulation of outdated session data in the HTTP cookies which may of interest to the attackers.
  • Use a third party software such as ArpON to guard against possible hijacking on the website.
All in all, although the above methods may not be possible to guard against all forms of session hijacking, they do provide some guidelines for Web developers to produce a securer system and reduce the security threats that may arise due to session hijacking. Prevention is better than cure and it will be no harm to follow the above methods especially if it does not require any dramatic change in your system. At least, it won't too late if a session hijacking does occur in your system suddenly.

References

Posted By： Roman At 1:18 AM

0 Comments:

Post a Comment