XSS Discovery and Exploitation With BurpSuite

I’ve recently completed TryHackMe’s cross-site-scripting room and PortSwigger’s XSS labs and here’s what I’ve learned! This piece assumes you have the OWASP Broken Web Application installed and already have Burp set up as your proxy!

XSS stands for cross-site scripting. It is counted among the OWASP top 10 vulnerabilities for web applications. XSS is an injection attack where malicious javascript is injected into a web application and is executed by other users. Attackers take advantage of this vulnerability to conduct malicious activities. For example:

There are two types of XSS attacks that I will be covering in this piece. The first is Reflected XSS, for which I will be providing demonstrations, the second is Stored XSS, which I’ll be giving a brief overview of!

XSS vulnerabilities are discovered by testing entry points. Entry points that may be vulnerable to XSS include:

Reflected/Non-persistent XSS attack is when an attacker gets a script to execute within another user’s browser. These attacks are made possible when user-supplied data in an HTTP request is included in the webpage source without any validation.

Say for example there is a web application that let’s users search for items in a store. You enter in the following term into the search box: table. The application then makes a request like so:

Upon reviewing the source code of the page, you notice the application has included the user supplied search term in the webpage’s source:

<div class = “example class”>

<p> You searched for: table </p>

</div>

Assuming that there is no input validation or processing being applied to the data, an attacker can replace the term with malicious JavaScript code. For example, instead of entering “table” into the search box, they enter:

After entering the following payload(Javascript code), if the application is indeed vulnerable to xss, just like the first search, the payload will be included in the source and the javascript will execute causing an alert box containing the string of text(‘XSS’) will pop up on the page!

This serves as the proof of concept for the attacker. The application is vulnerable to XSS; Javascript code was executed within the browser.

Now, you may be wondering “why is this considered dangerous?” Keep in mind that the value entered into the search box is also the value of the URL parameter.

So if an attacker were to copy the link including their payload and email it to many different people in a phishing attempt, whoever clicked that link will have the code executed in their browser.

Unlike with reflected xss, a stored xss does not execute within a single user’s browser. The attacker’s payload is instead stored on the web application itself(such as in a database) and is thus executed anytime a user visits the webpage. Because XSS attacks are self-contained within the application itself, the attacker doesn’t need to trick users into making a request containing their exploit(such as through a phishing attempt).

A stored XSS attack is made possible when a website does not sanitize user input before it is inserted into the database.

To discover a stored XSS vulnerability, an attacker would need to test possible points of entry where it seems data is taken from a user, stored, and then shown to other user’s. Examples Include:

I’m going to use the intentionally vulnerable OWASP Broken Web Application to demonstrate how to test for reflected xss using BurpSuite and some JavaScript code!

The attacker’s payload(malicious javascript code) depends on the context of the XSS vulnerability. That is, a different method of exploitation may be needed depending on where the controllable data appears and what type of input validation is being used.

There are measures put in place to ensure that user input(untrusted data) is only displayed within a user’s browser but never executed.

Common forms of XSS defenses include:

That’s what I’ve learned so far about XSS Vulnerabilities! I hope you were able to learn something as well! Thankyou so much for reading.

Upcoming Pieces Include:

Until then, Happy Hacking!