Session not timing out when browsing away from application

Continuing with Web Application Vulnerabilities today I will describe why is it important to abandon the session once a logged in user browses away from the site without logging out and thus the associated SessionID is not terminated in a timely manner. If the user is working on a shared computer and does not log out of the application or close the browser, but simply browses to another web site, then the following user will be able simply browse back to the previous session. This can be exploited by a malacious user who can reuse the session and can cause serious damage to the user data. many a times users forget to log out. An attacker may be able to gain access to the same browser session soon after the user has
left the computer, and hence gain access to the application. A simple solution can be designed to prevent this. One thing which is important to note is asp .net applications by default use a 20 minute session timeout on sliding expiration. However still the SessionIDs should be terminated the moment the browser is used for external sites.  In order to log the user off once the user starts navigating away from the application can make use of master pages with two html frames. The application should reside in the main frame, which the user will browse. There can be an invisible frame with a javascript that gets called when the user browses away from the App. Essentially the script makes an Ajax logout request as soon as the user navigates away from the application. This in turn will abandon the user’s session and log the user off.   

Session Hijacking Vulnerability

Continuing my posts on Web Application Vulnerabilities, today I like to add details on Session Hijacking: What it is, Potential Risk and how to remediate it.

What is Session Hijacking and Potential Risk – Session hijacking is the act of taking control of a user session after successfully obtaining or generating an authentication session ID. Session hijacking involves an attacker using captured, brute forced or reverse-engineered session IDs to seize control of a legitimate user’s Web application session while that session is still in progress. ( refer imperva.com for more details). The ability for an attacker to capture and use SessionID’s is highly dangerous. If an attacker is able to gain a valid SessionID of a valid user, it is possible for the attacker to gain unrestricted access the application as that user. Confidentiality and integrity of the system is then compromised.

The two most important countermeasures to prevent session hijacking that I know of are as follows:

  1. Session ID should be strongly encrypted to stop it being deciphered or changed by an attacker. By default the session id that is generated by the ASP .Net application is encrypted using RSA. It is a good idea to send the session id cookie on an HTTPS pipeline to the user machine.
  2. Use a unique variable (such as the client IP Address) to prevent the session from being useable on other machines. The application can implement a solution that uses the client’s machine’s external IP address. The idea is to encrypt this IP address and put it in the Authentication cookie which is sent by the client on every single request it makes to the application web server. An authentication cookie is created only when the client logs into the application with valid credentials. At this stage the client’s machine’s external IP address can be retrieved from the HTTP – Headers and encrypted and saved in the authentication ticket. This is then saved in the authentication cookie and sent to the client. By implementing it in this manner, on every further request the application will first decrypt the IP Address that is saved in the authentication cookie and match it with the IP address that is retrieved from the HTTP- Headers. If you are really enthusiactic you can override the default SessionStateModule that is provided by ASP .Net to create your own session ids.

For encrypting and decrypting IP Address you can use DESCryptoServiceProvider from System.Security.Cryptography namespace.

 More vulnerabilities and their solution to follow. Keep looking.

Web Application Vulnerabilities

Recently I was involved in developing a financial web application. Other than verify that the application meets all the functional requirements, the application was put to stringent hacking tests. Several penetration tests were carried out by professionals to help identify any potential risks. The intent was to see to what extent an external attacker could penetrate the systems. This test focused on identifying technical vulnerabilities that a competent external hacker could exploit to gain privileged access to the application and server. Inspite that we were using HTTPS for the entire site, I was surprised to hear that these guys were able to hijack the sessions and perform Cross site request forgery.

In the next few posts I will like to post the key and high vulnerabilities that the attackers look for and the ways to mitigate them.

Some of the minor vulnerablities that could potentially lead to system compromise are:

  1. Weak SSL Cipher Support – SSL Cipher keys of length less than 128bit are considered as weak. The information encrypted can possibly be decrypted easily and can lead to further exploits. When a man in middle attack occurs this flaw can provide access of private information. The solution lies in IIS config settings. Make sure cipher less than 128 bits are not allowed. Please read more on the following Microsoft knowledge base: How to control the ciphers for SSL and TLS.
  2. Form AutoComplete Enabled – While this functionality is desired by users, you may not want it for all the form fields. The problem lies in fact that many recent browsers like IE, firefox have features that will save form field content entered by users and then automatically complete form entry the next time the fields are encountered. This feature is enabled by default and could leak sensitive information since it is stored on the hard drive of the local computer. The risk of this issue is greatly increased if users are accessing the application from a shared environment. If AutoComplete is enabled on a login field then an attacker may be able to gain access to usernames and
    passwords from local system caches. The solution is simple. To turn off auto-complete for your entire form, all you need to do is add an attribute to your form tag, like this:

<form id=”Form1″ method=”post” runat=”server” autocomplete=”off”>
Easy enough. Now you won’t get the auto complete on any of the controls on the form, works for any browser that supports auto-complete. If however you want to have auto complete on for some textboxes and off for the others, ASP.Net does provide in mechanism to control it at granular level. to turn off autocomplete for a textbox use this:
<asp:TextBox Runat=”server” ID=”Textbox1″ autocomplete=”off”></asp:TextBox>
or at runtime:
Textbox1.Attributes.Add(“autocomplete”, “off”);

Simple and you are done. Over the next few blogs I will put in more on web vulnerablities and steps that you can take to prevent them. Watch out!

Sliding Expiration

Ever wondered how sliding expiration setting that we use in forms authentication in asp .net work

Below is an example from one of the articles I came across at MSDN. It shows how does sliding expiration work in the context of forms authentication.

If the logon page is accessed at 5:00 00:00:00 PM, it should expire at 5:10 00:00:00 PM if the timeout attribute is 10 and the slidingExpiration attribute is set to TRUE. Now, if any Web page is browsed again at 5:05 00:00:00 PM, the cookies and ticket time-out period will be reset to 5:15 00:00:00 PM.

Note If the Web page is accessed before half of the expiration time passes, the ticket expiration time will not be reset. Fore example, if any Web page is accessed again at 5:04 00:00:00 PM, the cookies and ticket timeout period will not be reset.