Table of contents
This is a writeup for a challenge from PortSwigger's Web Security Academy. In this one, we will learn how a simple Cross Site Scripting vulnerability works, how it can be exploited and what an attacker can gain out of it.
Objective
This lab contains a simple reflected cross-site scripting vulnerability in the search functionality.
To solve the lab, perform a cross-site scripting attack that calls the alert function.
Solving the challenge
We've got a web page with the search bar:
We can try to submit our XSS payload to the search field to test it:
The payload is simple:
<script>alert(document.cookie)</script>
We are creating another <script> HTML tag inside the document and executing arbitrary JavaScript code.
In most examples of the basic XSS, you will see the payload alert(1), but hear me out - it is bad advice. A classic #bugbountytip moment - by using anything aside from alert(1), you're automatically increasing the level of understanding from the recipient side. It's not that easy to actually understand what is you popped 1 on the screen mean, and what are the security implications of it.
Long story short, use the alert(document.cookie, or alert(document.domain) instead, and you will be fine!
The basic concept of testing for the XSS will remain the same - we will find the input field to provide the payload. It is a well-known vulnerability, and it's taking its place in OWASP top-10 for eternity, so there are mitigations that should be applied. They aren't always there, but in more difficult challenges we will have a look at how to bypass the most common ones.
With our payload, we got the current session cookie displayed on the screen.
To replicate this attack, we can use the URL:
