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 balancer. 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. Please post your comments.
Thank You!