Identifying the Cookie Monster In the Web
Computer session is a temporary interaction you have with a website. For example, the time between you first log into your bank account, and then log off after your operation, is a session. Session keys are used to identify a particular user by the server. The server will generate session id and will send to the client via a cookie. This cookie should be in the every aftermath request headers by the user to that server. These cookies play a vital role in the authentication process between a client and a server. So due to that web attackers deploy attacks to grab this cookie and do malicious acts which can affect the client or the server. These attacks are defined as cookie hijacking or session hijacking.
During a session hijack, an attacker places himself in between our computer and the website’s server (Facebook for instance), while we are engaged in an active session. At this point, the attacker actively monitors everything that happens on our account, and can even kick us out and take control of it. The biggest threat of a session hijacking is that the attacker can enter the server and access it’s information without having to enter to a registered account. In addition, he can also make modifications on the server that to help him hack it in the future or to simplify a data-stealing operation. An attacker can deploy session hijacking attacks on two levels. They are as follows
- Network Level
- Application Level
But in the following article I’ll be mainly focusing on Application Layer session hijacking. This article will contain how an attacker will do a session hijacking using cookies and how to prevent such attacks.
Application Level
The application layer is a layer in the Open Systems Interconnection (OSI) seven-layer model and in the TCP/IP protocol suite. It consists of protocols that focus on process-to-process communication across an IP network and provides a firm communication interface and end-user services. The HTTP protocol is also in this layer. So as we use that protocol to exchange cookies, hijackers use this knowledge to deploy an attack.
In the application level, the session hijacker not only tries to hijack existing sessions but also tries to create new sessions using stolen data. Session hijacking at the application level mainly involves obtaining a valid session ID by some means in order to gain control of an existing session or to create a new unauthorized session.
Following described methods are some of the ways that an attacker may deploy to start a session hijack.
1) Obtain Session ID’s
Application level session hijacking is all about obtaining the session ID since web applications key off of this value to determine identity. Session IDs generally can be found in three locations.
- Embedded in the URL, which is received by the application through HTTP GET requests when the client clicks on links embedded in a page.
- Within the fields of a form and submitted to the application. Typically the session ID information would be embedded within the form as a hidden field and submitted with the HTTP POST command.
- Through the use of cookies. Cookies are used to send the session id to the client by the server. When client want to interact with the same server with the same session client must provide the cookie to authenticate.
All three of these locations are within the reach of the session hijacker. Embedded session info in the URL is accessible by looking through the browser history. A hijacker can sometimes re-enter in the URL from the browser history and get access to a web application if it was poorly coded. Session info in the form submitted through the POST command is harder to access, but since it is still sent over the network, it can still be accessed if the data is intercepted. Cookies are accessible on the client’s local machine and also send and receive data as the client surfs to each page. The session hijacker has a number of ways to guess the session ID or steal it from one of these locations.
2) Sniffing (Session Side Jacking)
The hijacker can create the “man in the middle” situation and use a packet sniffer. If the HTTP traffic is sent unencrypted(not as HTTPS), the session hijacker has traffic redirected through his host where he can examine the intercepted data and obtain the session ID. Unencrypted traffic could carry the session ID and even usernames and passwords in plain text, making it very easy for the session hijacker to obtain the information required to steal or create his own unauthorized session.
Using a sniffing device or software such as Wireshark, the attacker scans incoming and outgoing traffic, looking for the session cookie. Sites without an SSL certificate are also exposed to this kind of attack, since they don’t encrypt data sent between computer and server.
3) Brute Force
If the session ID appears to be predictable, the hijacker can also guess the session ID via a brute force technique, which involves trying a number of session IDs based upon the pattern. This can be easily set up as an automated attack, going through multiple possibilities until a session ID works.
4) Man In The Browser
This type of attack infects your browser with a Trojan horse that monitors what you do on the web, while secretly collecting data and even changing input values in banking forms and other similar websites. A cookie usually has the details about the session details such as session id and it may also contains details about users interactions with a particular web site. All of these cookies are resent and received via the browser. So the malware in the browser can alter the normal behavior and can execute in harmful manner to the user.
Prevention of Session Hijacking At The Application Level
There are a number of things that can be done to prevent session hijacking. In the same manner that the act of session hijacking was discussed, I will discuss the countermeasures for session hijacking in terms of the techniques that apply to the network and application levels.
- 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 user has logged in.
- Session Time Out :- Users often share client machines, so it’s important that the session time out after a certain period of inactivity. If the session never times out, this also gives the hijacker an unlimited amount of time to run his brute force attack.
- Use encrypted session IDs :- Developers can further protect user’s session IDs by encrypting them. They can write code that encrypts each session token or encrypt the entire channel using SSL. They can also use different session IDs for secure vs. insecure parts of the site. So, the session IDs that travel on the SSL protected channels would be different from the ones that travel on the unprotected channels.
- Logging Out After Every Session :- This is a simple measure against Cookie hijacking. But it’s one the most important measures that a user must take. Because logging out of your account will terminate the session. This means you will also force the attacker to log out.
Summary
Session hijacking remains a serious threat to networks and web applications on the web. This article provided a general overview of how this attack is done and what are the preventive methods that can be taken to achieve a secure communication. It is important to protect our session data at both the network and application levels. Although implementing all of the countermeasures discussed here does not completely guarantee full security against session hijacking, it does raise the security bar and forces the session hijacker to come up with alternate and perhaps more complex methods of attack. It is a good idea to keep testing and monitoring our networks and applications to ensure that they will not be susceptible to the hijacker’s tricks
