Reflected XSS (Referer)
Hello friends, today I will show you the steps of detecting a vulnerability that I encountered in Web Application Security Tests in my project named Saka Reflected XSS (Referer) and exploiting this vulnerability.
What’s XSS
You can find detailed information about the XSS vulnerability in the article below.
Running the Application
Docker
docker pull erdemstar/saka:reflected-xss-referer
docker run -d -p 80:80 erdemstar/saka:reflected-xss-refererVisual Studio 2019 IDE
git clone https://github.com/ErdemStar/Saka
cd reflected-xss-referer
- mouse click on reflected-xss-input.sln
- devenv reflected-xss-input.sln (CMD)Reconnaissance
When we first open the application, a page like the one below welcomes us. By pressing the Attack button on the page, we are directed to the part we will test.
When we come to the Attack page, name and message fields are available. When these fields are filled and the request is sent, it is understood that there is no change in the page.
Since there is no change on the UI side, let’s check the GET and POST Request and take a closer look.
It has been understood that GET Request is used to fetch the Attack page directly without receiving any data from the user.
Although it is thought that POST Request is used to send the name and message information it took from the user, when the body part is checked, it is seen that it does not have such a purpose, it only sends a field named referer to the backend.
The POST Request sent to the application is created when the button of the form on the UI side is clicked. To take a closer look, the response with GET Request should be examined.
When the <form> tag of the response obtained with the GET Request is examined, it is seen that the name and message parts are empty and the existence of an input named referer and the value assigned to it have been detected.
It has been understood that the reason why the input element is not visible from the UI is due to the setting of type=hidden.
Look at the GET Request, it can be checked whether the “http://localhost/" value assigned to the referer in the response comes from the request as follows.
Looking a little closer at the Referer field in the GET Request, the presence of input reflection is detected by looking at the response.
It has been observed that the same result is not obtained with the POST Request, which is similar to the request made in the GET Request.
Mental Notes
- The application does not use the name and message information received from the user through the form.
- When a request is sent to the /Home/Attack endpoint with GET, the data in the Header Referrer field of the relevant request is also reflected in the referer input in the response.
Exploitation
After obtaining sufficient information on the application, we add some characters to be interpreted by the browser to the Referer’s value we will send in order to exploit the XSS vulnerability.
When we check the content of the incoming reply, it is understood that the application reflects the Referer’s value received from us without any security checks.
After we have obtained so much information about the application behavior, when we send a request like the one below to the Referer field, we perform the Reflected XSS scenario on the application.
Thank you for reading my article, I hope it was useful for you. Below I leave the links of my other concepts that may be useful to you.
Click here to see my other articles about web vulnerabilities. Link
