CSRF + POST Body Param Reflection = POST-Based XSS (A BrainFuck)

Hello again,

This blog explains how i chained a CSRF and XSS on a POST request. So, lets get straight into it. One day i was hunting on a private program and i could see most of hacker’s were reporting CSRF. Almost 5 reports out of 10 were them. Lot’s of CSRF right?. Let’s name the scope https://brainfuck.com

I wouldn’t waste time looking for more CSRF as the chance of getting a duplicate is high. So, i started looking for OAuth Misconfiguration. Then, i saw that my reflector plugin identified a reflection in a POST parameter. The POST request was being made on /address and the reflected parameter was thelia_front_address_create[success_url] . So, i tried looking for XSS manually. Wasted almost 2 hours, started my KNOXSS API took a break and came back. Finally KNOXSS found a bypass payload (Can’t share you the payload but you can check yourself at https://knoxss.me )

So, this payload finally pops an XSS. But, this is a self XSS (Out Of Scope). Now, do you remember i told a lot of CSRF were being reported? So, i checked and yes the POST request was vulnerable to CSRF attack. You could basically create address and set that address as the primary using a simple CSRF request. So, i started working on the exploit to chain this two bugs. First. i created a HTML form (POST based Request with the XSS payload on the vulnerable field) and hosted in my server.

Now, when the victim visit my page https://attacker.com/csrf.html he/she will be redirected to https://brainfuck.com/address (The scope i was testing) and the XSS will be executed. Now, i did some tweaks on the payload and combined it with blind xss. But, for some reason i was not getting the PHPSESSID. Man, i could have achieved an account takeover. Upon further investing the whole thing. I noticed the samesite=lax; httponly in the cookie header. I was so close to a high severity Bug. So, what restricted me from account takeover?

• SameSite=Lax: This attribute restricts the cookie from being sent with cross-site requests unless they are top-level navigation (e.g., clicking a link). However, it doesn’t block cookies from being sent for requests originating from the same site.

• HttpOnly: This attribute makes the cookie inaccessible to JavaScript through document.cookie, which means you cannot directly access it in client-side JavaScript code. This prevents you from stealing cookies via typical JavaScript methods like document.cookie.

Also, the site had no such features where all the users could interact with each other, such as comments or else i would have used that bypass payload for stored XSS to account takeover. Anyways, even the XSS was limited. I wrote a report and submitted to the team. I had already spent a lot of time in this bug. Also, i was not sure if this will be accepted as i told you earlier, lots of CSRF. Now, begins the real BRAINFUCK. This is what i got reply from the triager.

I was like, What the FUCK?

Then, i investigated the whole thing again from the beginning. Then, i came to know i missed the most important and weirdest thing in my HTML form. The application logic was something like this:

The initial login decision (whether "Remember Me" is selected).

• Error handling paths: If an error occurs, the application will either:

  • Redirect to the same page if "Remember Me" is selected.

  • Log out the user and redirect to the login page if "Remember Me" is not selected.

It took me exactly an hour to identify this logic. I updated the team with further info.

Finally, the team reopened the report.

This, time they were able to reproduce the the POC and it was accepted and rewarded accordingly.

This is all for today. May the Pop Up be with You. :)

I would love to hear your thoughts on this. Maybe we can connect on X (Twitter)