Session Management Vulnerability in Web Application Part 1

Session Management Vulnerability in Web Application Part 1

Introduction

Communication over the internet is done using HTTP protocol. HTTP is stateless protocol and that means there is no backing at the protocol level to analyze the state of a specific request. Another way of saying this is that web servers do not have a mechanism, which tells them where tech request is coming from, whether it is from a new client or a client who is already communicating with it. So, from the point of view of the server, each request it gets is a new request for the server. To overcome this problem a new programming way was implemented with the HTTP protocol, which is called the Session Management. It is the process of keeping track of a user’s activity, across sessions of interaction with the browser.

Now let’s try to understand how session management works with web applications.

How Are Sessions Tracked

Session identifiers (SIDs) are primarily used by developers to track sessions. Once successfully authenticating the user, the server creates and maintains a session ID. There onwards, for every request that is generated, this value is inspected to track the user. This means that session IDs are like authentication token, used so that the user is not required to re-enter the credential information along with every request.

Based on how SIDs are sent and received, there are three ways by which sessions can be tracked:

1. Cookies: The SID is developed and maintained in the server and it is sent to the user in the form of cookies. The user’s hard disk is used to store the cookies and they go along with every request. Before performing the request, the same is verified by the server. This is the most commonly used method.

2. URL Rewriting: In this method the SID value goes in the URL of every request. This is a difficult form of session tracking, as till the conversation completes, it is required to keep track of the parameter in the form of a chain link.

3. Hidden Fields: These are elements that are not directly evident to the user. These fields can be read through the page source. Hidden fields are used during session management, as SID values are stored in this element and it can be sent to the server with every request. This method is not commonly used these days.

Vulnerabilities in Session Management

Following are the different ways in which active sessions can be hijacked:

Session Sidejacking

If SSL is not used by the application and it transport data in plain text, then it is possible for anyone in the same network to grab the cookie values by using tools like Wireshark. Following are some cases worth mentioning:

1. SSL only for login page: If there is no SSL, even the credentials would be gone. But, some developers use SSL only for the login page, assuming that the references are transported safely. But once user authentication is done, the cookies that go with each request, identify him. All requests done after logging, contains cookies, and the sessions can be easily hijacked if they are not safeguarded with SSL.
2. Single URL is enough to hijack a user: There are various cases, in which the application uses HTTP, in order to fetch JS files or images, which belong to the same domain. So, if there is a single link that goes to the server without HTTPS, the cookies go along with it and they can be seized by an attacker who is searching the network.

Session Fixation

Session fixation is an attack in which the session is fixed by an attacker, in advance, and he stays down till the user logs in and then hijacks it. This is applicable to the SIDs in the URL scenario. Following are the ways in which this attack is possible:

An attacker logs into the website – www.vulnerablesite.com. Cookie value is set by the server and is returned to him, say Set-Cookie: SID=adfajkdfjer23411sdfadf

  • The victim is now sent the link, http://www.vulnerablesite.com/test.php?SID= adfajkdfjer23411sdfadf
  • The victim logs on and the SID value is assigned to him by the server. Because of bad coding, the server does not check whether it is generated by itself and tags the users with it.
  • The attacker, who knows the SID value he used, can use the same and get access to the victim’s account.

Generating Cookies Prior to Authentication

Cookies have to be changed or generated after successful authentication. If the same cookies is used before and after authentication, then the possibility of session hijacking increases, according to the following example.

An attacker logs into the website www.vulnerablesite.com. Cookie value is set by the server and is returned to him, say Set-Cookie: SID=randomqrrqwer234234234

  • This value is noted by the attacker and he leaves the system. The page is left open.
  • The victim logs into the same website. Cookie value is not changed after authentication.
  • The victim’s account can be accessed by the attacker, who has the cookie value.

Predictable Session IDs

By reviewing the pattern of session IDs, the session ID of a logged in user can be predicted and his account can be hijacked. Following is an example:

Set-Cookie: sessionid=dG9tOm1hbmFnZXI=

Although this may seem random at first, it is not. Base 64 decoding of the value provides the following data.

Base64 Decode [dG9tOm1hbmFnZXI=] = tom:manager

Thus, a valid cookie can be constructed, if the attacker studies the pattern.

Usage of Cross Site Scripting Vulnerability

XSS attack can be used to steal cookie value or SID. In other words, XSS allows executing scripts like JavaScript, on the end user’s browser. Therefore, the attacker just has to write a script, which can access the cookie value and it can be sent to a server that he owns. Same thing is done by the script mentioned below. The attacker’s site is hit with this cookie value. With the use of document cookie, it is possible to access the cookie on the client’s side.



Let us know what you think