Challenge 2: Reflected cross-site scripting attack
You will learn about a reflected XSS and how it differs from the stored XSS. Also, I will walk you through exploiting reflected XSS.
Welcome back to learning Cross-Site Scripting(XSS) vulnerability with the Kurukshetra app built by d4rk36.
In this article, we shall learn about the reflected XSS and how it differs from the stored XSS.
Before we start, ensure the lab is running if you have not set up your lab yet. Feel free to refer back to the below link.
Raghunath G
XSS Vulnerable App - By Design
Types of Cross-Site-Scripting (XSS)
How Reflected XSS Work?
The server processes the malicious input code supplied from the client side, and the same malicious code is injected and then returned to the client in an HTTP response without proper validations.
The browser renders the response content, assuming it was supplied by the application server, which can be trusted, and the injected malicious code also gets executed.
The significant difference that can be observed when compared to stored cross-site scripting is, in reflected XSS, the malicious code is just appended back in the HTTP response and executed immediately. It is not stored anywhere in the database.
For the same reason, the impact of reflected XSS is reduced compared to the stored cross-site scripting vulnerability.
Practicals - Reflected XSS
Post setting up the lab, visit http://localhost:8066. The application should be loaded as shown below and Navigate to "XSS Challenge 2."
Before you start assessing, take some time to understand how the application functionality works.
Let's go ahead and give it a try with the similar payload used in the stored XSS.
Once appending the payload, click the "Submit" button, as shown in the screenshot below.
Immediately observe the alert pop-up message, which will be displayed below.
Click "OK" and observe the page loads normally.
To verify and confirm the vulnerability, right-click and select "view page source" and search for the above-injected payload.
The proof-of-concept script code aligns correctly with the HTML response received, and all the characters are displayed back as given in the input field.
Yay!! Now, we can confirm we have successfully exploited the reflected XSS.
Now, a point to remember here is that as this is not stored in the database, it gets executed only when the malicious code is injected. At all other times, the application usually behaves as expected.
In Stored XSS, the malicious payload gets executed whenever any user visits the injected application functionality.
Summary
This article covered how to identify reflected XSS and how it works, including reusing the same XSS payload without much tweaking.
Keep learning!! :D