Welcome to WWWWWH, a series where I’ll be covering the Who, What, When, Where, Why, and How of different web-based vulnerabilities as I do deeper dives into each vulnerability in my own career. This is a great exercise for making sense of all the different vulnerabilities from end-to-end. In this series, the goal is to not only understand how to perform and look for vulnerabilities, but to also understand how to weaponize them for building out a Bug Bounty methodology and thinking like an attacker.
Reflected Cross-Site Scripting
The first topic I decided to take a deep dive into is Cross-Site Scripting (XSS), and more specifically, Reflected XSS. In a nutshell, XSS is manipulating a vulnerable site and forcing a victim to execute Javascript. Reflected XSS differs from other types of XSS because the injected code will be reflected directly into the user’s browser view. This commonly happens when a developer forgets to implement proper input validation to ensure that user-generated data entered through the page is sanitized before it gets displayed.
WWWWWH Analysis
Who?
When searching for an XSS vulnerability in a web application, contrary to popular belief, you’ll only be looking to target the company who created the application in very rare cases. Generally, you’ll be looking to target users of said application because they will be the ones accessing sensitive data that you, as an attacker, would be interested in.
What?
Since everything in Reflected XSS is executed on the client side, the vulnerability is focused on targeting the client side code. It’s here that the attacker will be forcing the victim to execute Javascript they are not intending to execute.
When?
This vulnerability offers opportunities to access sensitive user data, so it’s important to use this while the victim is presently accessing and using the application. Since a main use case for this vulnerability is session riding, it’s important that the user's data is fresh.
Where?
This vulnerability will occur where an input vector has unsafe or insufficient measures for input validation, and reflects unsanitized data back into the application itself. Some common places are in HTTP requests (headers, cookies, etc.), URL parameters, or anywhere else you can control input. You’ll then need to find a way to deliver this exploit to the victim over the internet.
Why?
After finding an input vector, figuring out the exploit, and honing in on a victim - it’s time to decide why you want to execute this vulnerability against the user. As mentioned above, a common use case is to impersonate a user’s session, often called session riding. Another common use case is to use it to capture the victim’s keystrokes via keylogging. Reflected XSS can also be used in phishing attacks, where you can trick the user into providing credentials or other sensitive data. When targeting a user of the application directly, you can use it to read data that only the user is able to access, or carry out an action that only they can perform with their permissions. On the other side of the spectrum, you can also use it to target the company themself by performing virtual defacement. Reflected XSS has many use cases, but these are the common opportunities for exploitation.
How?
Finally, after answering all of the questions above, you’ll deliver a payload to the user by utilizing the unsanitized input vector via your chosen attack vector (the Why?). Here’s an example of HTML code, and a basic Reflected XSS payload that could be used to test whether an XSS vulnerability is possible. Generally, people test for Reflected XSS by triggering an alert() in the browser, or a console.log(‘test’).
In this test scenario, imagine an application requires you to enter your username. It then takes the username you entered, and includes it directly into a welcome message. You can view an example below.
<html>
<body>
<p>Enter your username:</p>
<input type="text" id="username">
<button onclick="printUserName()">Enter</button>
<p id="output"></p>
<script>
function printUserName() {
const usernameObj = document.getElementById("username").value;
const outputObj = document.getElementById("output");
outputObj.innerHTML = "Welcome to the website " + usernameObj + "!"
}
</script>
</body>
</html>As you can see, the script function does nothing but take the username input and reflect it right back into the DOM (Document Object Model). So, you’d be able to PoC (Proof of Concept) and test for an exploit by placing the following payload into the input field to close out the quotation marks, and trigger an alert on the image error.
"<img src=1 onerror="alert('test')">This payload proves the existence of a Reflected XSS vulnerability in the page. If you had discovered this in the real-world, it would now be time to revisit the Who, What, When, Where, and Why to determine how to weaponize and deliver an exploit to the victim.
WWWWWH: Reflected XSS
I hope that you've enjoyed my first installment into the WWWWWH series, and I'll be revisiting it again to cover other Cross_site Scripting variations like Stored XSS and DOM-Based XSS, as well as more vulnerabilities in the future!
This is great information thank you.
Best,
Davis Booker