Session Hijacking

Session Hijacking Attack


Also known as man in the middle attacks, session hijacking deceives a server or a client into accepting the upstream host as the actual legitimate host. Instead the upstream host is an attacker’s host that is manipulating the network so the attacker’s host appears to be the desired destination.

Session hijacking is a method of taking over a Web user session by surreptitiously obtaining the session ID and masquerading as the authorized user. Once the user’s session ID has been accessed (through session prediction), the attacker can masquerade as that user and do anything the user is authorized to do on the network.

Session hijacking is the exploitation of a valid computer session—sometimes also called a session key—to gain unauthorized 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

A popular method is using source-routed IP packets. This allows a hacker at point A on the network to participate in a conversation between B and C by encouraging the IP packets to pass through its machine.

If source-routing is turned off, the hacker can use “blind” hijacking, whereby it guesses the responses of the two machines. Thus, the hacker can send a command, but can never see the response. However, a common command would be to set a password allowing access from somewhere else on the net.

A hacker can also be “inline” between B and C using a sniffing program to watch the conversation. This is known as a “man-in-the-middle attack“.



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.
  • Session sidejacking, where the attacker uses packet sniffing to read network traffic between two parties to steal the session cookie. Many web sites use SSL encryption for login pages to prevent attackers from seeing the password, but do not use encryption for the rest of the site once authenticated. This allows attackers that can read the network traffic to intercept all the data that is submitted to the server or web pages viewed by the client. Since this data includes the session cookie, it allows him to impersonate the victim, even if the password itself is not compromised. Unsecured Wi-Fi hotspots are particularly vulnerable, as anyone sharing the network will generally be able to read most of the web traffic between other nodes and the access point.
  • Alternatively, an attacker with physical access 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’s computer or the server.
  • Cross-site scripting, where the attacker tricks the user’s computer into running code which is treated as trustworthy because it appears to belong to the server, allowing the attacker to obtain a copy of the cookie or perform other operations.



Methods to prevent session hijacking include:

  • Encryption of the data traffic passed between the parties; in particular the session key, though ideally all traffic for the entire session by using SSL/TLS. 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.
  • 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 or brute force attacks.
  • 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 s/he has logged in.
  • 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 whose IP address is liable to change during a browsing session.
  • 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, two legitimate, closely timed requests from the same client can lead to a token check error on the server).
  • Users may also wish to log out of websites whenever they are finished using them. However this will not protect against attacks such as Firesheep.
  • Configure authentication and integrity checking between VPN endpoints.


Other methods for prevention are:

  • Virtual private networks (VPNs) allow secure access to corporate resources by establishing an encrypted tunnel across the Internet. The ubiquity of the Internet, combined with the VPN technologies of today, allows organizations to cost-effectively and securely extend the reach of their networks to anyone, anyplace, anytime.
  • IPSec is a framework of open standards developed by the Internet Engineering Task Force (IETF) that provides security for transmission of sensitive information over unprotected networks such as the Internet. IPSec acts at the network layer, protecting and authenticating IP packets between participating IPSec devices (“peers”) such as Cisco routers.

IPsec is designed to provide interoperable, high-quality, and cryptographically based security. IPsec is defined in (RFC 2401). The set of security services offered includes access control, connectionless integrity, data origin authentication, protection against replays, confidentiality (encryption), and limited traffic flow confidentiality. These services are provided at the IP layer, offering protection for IP and upper-layer protocols (ULPs). Because these services are provided at the IP layer, they can be used by any higher-layer protocol (for example TCP, User Datagram Protocol [UDP], and Border Gateway Protocol [BGP]).

IPsec provides security services at the IP layer by enabling a system to select required security protocols, determine the algorithm (or algorithms) to use for the service (or services), and put in place any cryptographic keys required to provide the requested services. IPsec can be used to protect one or more paths between a pair of hosts, between a pair of security gateways, or between a security gateway and a host.