# 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`

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1731095048390/4c0f1732-3b3f-4355-a02e-066082a8eeed.png align="center")

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](https://knoxss.me) )

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1731096136591/5424e779-417f-4024-9dbe-2af22d7367d7.png align="center")

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1731095969102/6d6f7493-b98b-4aeb-8892-d837c54e40a6.png align="center")

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.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1731096431113/fa344b92-5771-4f60-807e-e7b7ee17406d.png align="center")

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.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1731097501939/407e20ae-c54e-4951-8630-3a503cd5f325.png align="center")

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1731098243216/525fe25b-bbdd-41e2-b05d-bac27a8eb986.png align="center")

I was like, What the **FUCK**?

![Years Later GIFs | Tenor](https://media.tenor.com/1jNr3cMphpoAAAAM/long.gif align="center")

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.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1731098141871/4c72cbb3-a6c6-4a71-bc1e-1ec578883b4a.png align="center")

Finally, the team reopened the report.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1731098383738/530e8c8e-480e-4144-937e-2532b590bb67.png align="center")

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

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1731098458470/0791b9ed-136c-4c64-9652-9ef539a28ff6.png align="center")

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)](https://x.com/yamarajislitaf)