Table of Contents What is Session Hijacking?Step into Session HijackingWill encrypting the session value help prevent hijacking?Let's change the Session CookiesHow to fix the problem? 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.
"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.
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".
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.
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.
That's it; in this way we can avoid session hijacking to an extent. I will post a walkthrough video in the future. Please post your comments.
Thank You!
session_validate_code.zip (1.26 kb)
Maheshkumar S Tiwari edited Revision 5. Comment: minor edit
Maheshkumar S Tiwari edited Revision 4. Comment: Formatting
Maheshkumar S Tiwari edited Revision 2. Comment: Added TOC
Balaji M Kundalam edited Revision 1. Comment: Typography - minor edit
Please post code as a code, not as a picture
I uploaded the code samples as attachment....