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:
- 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.
- 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.