Session hijacking

HTTP protocol versions 0.8 and 0.9 lacked cookies and other features necessary for session hijacking. Version 0.9beta of Mosaic Netscape, released on October 13, 1994, supported cookies.

Early versions of HTTP 1.0 did have some security weaknesses relating to session hijacking, but they were difficult to exploit due to the vagaries of most early HTTP 1.0 servers and browsers. As HTTP 1.0 has been designated as a fallback for HTTP 1.1 since the early 2000s—and as HTTP 1.0 servers are all essentially HTTP 1.1 servers the session hijacking problem has evolved into a nearly permanent security risk.^{[2][failed verification]}

The introduction of supercookies and other features with the modernized HTTP 1.1 has allowed for the hijacking problem to become an ongoing security problem. Webserver and browser state machine standardization has contributed to this ongoing security problem.

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 them, 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 side jacking, where the attacker uses packet sniffing to read network traffic between two parties to steal the session cookie. Many websites 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 them to impersonate the victim, even if the password itself is not compromised.^[3] 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.
• 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.
• Malware and unwanted programs can use browser hijacking to steal a browser's cookie files without a user's knowledge, and then perform actions (like installing Android apps) without the user's knowledge.^[4] 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.

After successfully acquiring appropriate session cookies an adversary would inject the session cookie into their browser to impersonate the victim user on the website from which the session cookie was stolen from.^[5]

Firesheep, a Firefox extension introduced in October 2010, demonstrated session hijacking vulnerabilities in unsecured networks. It captured unencrypted cookies from popular websites, allowing users to take over active sessions of others on the same network. The tool worked by displaying potential targets in a sidebar, enabling session access without password theft. The websites supported included Facebook, Twitter, Flickr, Amazon, Windows Live and Google, with the ability to use scripts to add other websites.^[6] Only months later, Facebook and Twitter responded by offering (and later requiring) HTTP Secure throughout.^[7][8]

DroidSheep is a simple Android tool for web session hijacking (sidejacking). It listens for HTTP packets sent via a wireless (802.11) network connection and extracts the session id from these packets in order to reuse them. DroidSheep can capture sessions using the libpcap library and supports: open (unencrypted) networks, WEP encrypted networks, and WPA/WPA2 encrypted networks (PSK only). This software uses libpcap and arpspoof.^[9][10] The apk was made available on Google Play but it has been taken down by Google.

CookieCadger is a graphical Java app that automates sidejacking and replay of HTTP requests, to help identify information leakage from applications that use unencrypted GET requests. It is a cross-platform open-source utility based on the Wireshark suite which can monitor wired Ethernet, insecure Wi-Fi, or load a packet capture file for offline analysis. Cookie Cadger has been used to highlight the weaknesses of youth team sharing sites such as Shutterfly (used by AYSO soccer league) and TeamSnap.^[11]

CookieMonster is a man-in-the-middle exploit where a third party can gain HTTPS cookie data when the "Encrypted Sessions Only" property is not properly set. This could allow access to sites with sensitive personal or financial information. In 2008, this could affect major websites, including Gmail, Google Docs, eBay, Netflix, CapitalOne, Expedia.^[12]

It is a Python based tool, developed by security researcher Mike Perry. Perry originally announced the vulnerability exploited by CookieMonster on BugTraq in 2007. A year later, he demonstrated CookieMonster as a proof of concept tool at Defcon 16.^{[13][14][15][16][17][18][19][20]}

Methods to prevent session hijacking include:

• Encryption of the data traffic passed between the parties by using SSL/TLS; in particular the session key (though ideally all traffic for the entire session^[21]). 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. In response, scientists from the Radboud University Nijmegen proposed in 2013 a way to prevent session hijacking by correlating the application session with the SSL/TLS credentials^[22]
• 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 they have logged in.
• Some services make secondary checks against the identity of the user. For instance, 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.^[23][24] However this will not protect against attacks such as Firesheep.

• ArpON
• Cross-site request forgery
• HTTP cookie
• TCP sequence prediction attack