After the development of a web application for a client, I had requested our security experts group to carry out the VAPT (Vulnerability Assessment and Penetration Testing). Well, it’s the process that should be carried out before launching any system to make sure there’s no vulnerability exposed for the attackers to exploit the system or an application. And the result was a big list of vulnerabilities identified in the hosting server, services, and the application itself. In this article, I’ll be explaining how I fixed the issues identified in VAPT. I’ll try to break each vulnerability and its solution into a series of posts and link them at necessary places. In this article, we will talk about Session hijacking vulnerability detection and prevention.
Note: The web application’s authentication was relying upon WordPress login and user management.
Vulnerability 1: Session Hijacking detection and prevention
Session hijacking is also known as cookie hijacking; is the process of exploiting valid computer sessions. Such sessions might contain hard-to-guess data. The harder the data is, the harder it is for the attacker to break into the legitimate user’s session. Assume that the attacker can guess the cookie used in an active session of a user, then he can fully impersonate that user.
How to read session cookies?
Follow the below steps to understand how to read session cookies and its value.
Step 1: Install Cookie Editor plugin
Step 2: Access the application over HTTP protocol. E.g., http://application-url.com/login
Step 3: Log in to the application and click on the Cookie Editor extension in the browser toolbar.
Step 4: The extension would have captured cookies stored and their value. Just copy the cookie value to use in another browser.
Step 5: In another browser, access the login page of the application – http://application-url.com/login
Step 6: Click on Cookie Editor extension and paste the value copied in step 4 and hit enter. You will be logged in to the session that was created in a different browser without authentication and this is what is called Session hijacking.
How to prevent session hijacking vulnerability
Enable Secure and HttpOnly flags in the web server and use the long and random number or strings as the session key. This helps in reducing the risk that an attacker could simply guess a valid session key through trial and error or brute force methods. Use HTTPS to encrypt the session ID during transmission.
What is HttpOnly Flag?
By default, cookies can be transferred not only by HTTP and can be accessed by any JavaScript files loaded by the page. This enables cross-site scripting vulnerability (XSS) attack and it can be prevented by making cookies to send only via HTTP and disallow access via JavaScript.
What is a Secure Flag?
By default, cookies are sent on both HTTP and HTTPS requests. If an attacker can switch to HTTP traffic, then he can easily access the same cookie as it is not encrypted. By setting Secure flag, the webserver ensures that the cookie is encrypted when it’s created. And yes, you will need to purchase or use a LetsEncrypt SSL certificate to enable HTTPS.
In apache, enable Secure and HttpOnly flags as shown below:
Step 1: You will need mod_headers.so to be installed and enabled in Apache webserver.
Step 2: Copy the below line and paste it into httpd.conf file.
Header edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure;SameSite=None
Step 3: Restart the Apache webserver.
How do I confirm that HttpOnly and Secure flags are set?
It’s simple.
Step 1: Install the Cookie Editor plugin (if you haven’t) and enable it.
Step 2: Now go and access the website’s login page.
Step 3: Click on the Cookie Editor icon from the browser toolbar and make sure the "Secure" and "Http Only" flags are set.
That’s it! We have now prevented the session hijacking attack and in the next post, we will look at Vulnerability 2: Insufficient Transport Layer Protection.
