ASP.NET Web Applications: How to Avoid Session Hijacking
Let me try to explain how to avoid session hijacking in ASP.Net web applications. First of all this is not a complete solution to stop session hijacking but this will help to stop the theft of session information to an extent. I welcome more suggestions and input on this topic so that we can discuss it here and share the knowledge and ideas to make it more useful. This solution might just help you to get an idea and to how to test your web application against session hijacking and avoid exploitation.
This article describes hijacking (theft) of a user Cookie from a browser. I am sure that after reading this article, everyone will test their applications at least once.
What is Session Hijacking?
"In computer science, session hijacking is the exploitation of a valid computer session, sometimes also called a session key, to gain unauthorized access to information or services in a computer system. In particular, it is used to refer to the theft of a magic cookie used to authenticate a user to a remote server. It has particular relevance to web developers, as the HTTP cookies used to maintain a Session on many web sites can be easily stolen by an attacker using an intermediary computer or with access to the saved cookies on the victim's computer". Wikipedia. OWASP.
Step into Session Hijacking
We all know that an ASP.NET session state is a technology that lets us to store server-side, user-specific data. A session state of a user is identified by a Session ID, which is called by: ASP.NET_SessionId (SessionStateSection.CookieName, DefaultValue = "ASP.NET_SessionId") When the user requests a web page for the first time, the server will create a unique read-only string token (24 character string) as Session id and append it the request/response header. This will be used by the server each time to identify the user sending the request. This Session ID will expire when the user closes the browser. If the Session ID is embedded in the URL then this technique is also known as a cookie-less session.
Consider when a user named "User 1" sends a request to server, the first time a new ASP.NET Session Cookie will be generated by the server and sent back to "User 1" through the Response Header. The same Cookie will then be updated in the Request Header and sent back to the server for each and every request. Based on this Session Cookie, the server can identify each and every request sent by "User 1".
If the user is accessing the same web page or application from two different browsers or separate instances of the same browser then the session cookies generated will be different for each one. If you are using a single browser with multiple tabs then all the tabs share the same Session Cookie. Now a hacker or attacker gets in and steals the Cookie of "Browser 1" and updates the "Browser 2" Cookie. All the Session information of "Browser 1" will be copied to "Browser 2". This can easily be done by freely available tools or browser plugins like Modify Headers, Burp or Fiddler etc.
Will encrypting the session value help prevent hijacking?
I will say No, it will have less effect or have no effect at all. The reason why I said "No" is that, we are only encrypting the value not the browser session cookie. When a browser session cookie is stolen then whatever session information is linked to that cookie is not safe at all, even though it is in an encrypted form.
Let's start with an example. Here I have the following prerequisite. A Visual Studio version, IE with Developer Tools, Firefox with few add-ons like Live HTTP Headers, Modify Headers or Fiddler etcetera. Also I am using two different browsers like IE and Mozilla Firefox to show how the data is changed after hijacking a Session Cookie. Ensure you have IE developers or Fiddler or any other IE supportive tool installed that help us to look into the HTTP headers information. Enable the IE Developer tools, click on the "Network" button and followed by "Start Capturing" button.
Now consider I have a web page that accepts a fruit name. I entered the fruit name as "Apple" and hit the submit button. The IE Developer tool will begin capturing the HTTP activities. Now if you observe, there are various tabs available like, Request Headers, Response Headers, Cookies, etc. Inside the Response Headers and Cookies we can see the generated ASP.NET_SessionId but that is not available in Request Headers. This means that this is the first request sent to the server by the user. Now again click on the "Submit" button and wait for the tool to complete the process. Yes, now the session information is shown in the Request Headers.
Now open a Firebox browser. Download and enable these freely available add-ons or extensions. Live HTTP Headers and Modify Headers. Using Live HTTP Headers we can view HTTP Response Headers related information of a URL. Install it and configure it to open in a separate tab. Modify Headers allows the user to add, modify or filter out HTTP request headers. Run the sample web page in a browser and enter a fruit name such as "Mango". Check the Live HTTP Headers tab where we will see that the HTTP headers information with a different session got generated. So for different browsers the Session Cookie will be different.
Let's change the Session Cookies
Now we will steal and override the Firebox Session Cookie with IE Session Cookie. Open the Response tab of IE Developer tool; copy the Session Cookie information into a notepad. Now go to Firefox and open the Modify Headers add-on. Enable the drop down and select "Modify", put in the next text box "Cookie" and in the value field copy and paste the ASP.NET_SessionId information. Click on "Enable", a green icon occurs for the modified entry. Then click on "Start", this will enable the process of overwriting the Cookie information the next time we rerun the web page.
Rerun the web page and we will see the value got changed from "Mango" to "Apple". Now check the Live HTTP Headers information, we will see the Cookie got changed to a new Session Cookie. So in this way if someone has access to the Session Cookie it can be easily misused. We can generate the same steps using Fiddler, Burp etcetera.
How to fix the problem?
Yes, by implementing SSL.
Also, in addition to that we can use the following method to make it more secure.
We can't stop the theft of session cookies through any these tools. But we can handle this situation at the code level in the application. How about an event that handles each and every request handled by an ASP.Net application, that always fires whenever a request is made. If a page uses scripts or an image or HTML or any files, this event is likely to send more requests to the server, consequently this event fires more than any other events in Global.asax. The event is called Application_AcquireRequestState. Application_AcquireRequestState and is called once for each HTTP Get or Post request. This event occurs when ASP.NET acquires the current state (for example, session state) that is associated with the current request.
On this event we can validate the hacker or attacker system IP address for each Session request. In order to do that we need to hold the user IP addresses (during login) in the Session and compare it against the actual hacker system IP address. If the session IP address and system IP address are different then we can direct the user to logout or show an unauthorized access page because each system needs a unique IP address to work properly on a network or World Wide Web.
Here I am creating an encrypted session value that consists of Browser and User information that we can validate against the hacker information. At Global.asax we can validate this information on the Application_AcquireRequestState event. The code is given below.
If the user is behind a firewall then using HTTP_X_FORWARDED_FOR we can get the actual system IP address. The X-Forwarded-For (XFF) HTTP header field is a de facto standard for identifying the originating IP address of a client connecting to a web server through an HTTP proxy or load balance. This field holds the value in a comma separated list of IP addresses and the left-most is the original client address. Against this we are comparing the IP address in the session.
We also need to secure the Session Cookie.
After the SSL configuration is done the following updates the entries into the web.config and Global.asax files to make the cookie more secure and have a secure HTTP connection.
