Hello guys, I hope you all are doing well. I’m Jivan, and I’m back with a new write-up about a CSRF (Cross-Site Request Forgery) vulnerability.
This vulnerability allowed me to change a user’s profile and notification settings by crafting a custom HTML payload that executed the attack. In this write-up, I will explain how I discovered the vulnerability and built a custom payload to exploit it successfully.
Now let’s begin with how I discovered this vulnerability on [Redacted Dot Com]. Due to security and privacy reasons, I am not disclosing the target company’s information. In this write-up, I will refer to the target as [Redacted Dot Com], where this CSRF vulnerability was discovered.
After starting the initial review of [Redacted Dot Com], I created an account and began looking for any endpoints to test after logging in. I noticed an option to change or update profile information, so I chose this endpoint and started analyzing it.
I updated the information, such as the name field, for this [Redacted Dot Com] endpoint and captured the request using Burp Suite. (See the attached image for reference.)
If you carefully review the Burp Suite captured screenshot above, you’ll notice that the POST /api/changeInfo/basic HTTP/2 API request contains fields such as name, mailing, and other input fields. However, there is no CSRF token implemented in this request.
Advanced Real Bug Bounty Case Studies – Volume 1
Learn bug bounty hunting through real vulnerability case studies. Discover how XSS, HTML Injection, IDOR, and Broken Access Control vulnerabilities are identified, validated, and responsibly reported using practical, real-world examples instead of intentionally vulnerable labs.
Now, you might be wondering why I mentioned CSRF bypass in the title. Don’t worry I’ll explain this part clearly during the exploitation section.
After this, I created a CSRF PoC for the POST /api/changeInfo/basic HTTP/2 API request using Burp Suite’s built-in CSRF PoC generator.
Now I saved the above PoC code and delivered it to the victim, but I observed that the server was not accepting the PoC and instead returned a generic error.
After that, I carefully reviewed the PoC code generated by Burp Suite and identified some issues in the code. Let me explain this in detail.
While reviewing the PoC, I noticed that Burp Suite had set enctype="text/plain" in the generated form. However, the web application only accepts the request if the enctype is set to application/json;charset=utf-8. So, I updated the enctype value accordingly.
Next, I observed this line in the PoC: <input type="hidden" name="{"name":"AttackerUser_CSRFPoC","mailing":true,"serviceMailing":true,"paymentMailing":true}" value="" />
To make the PoC work correctly, I modified the input structure. Instead of a single input with a JSON object as the name, I created separate input fields for each parameter, like this:
<input type="hidden" name="name" value="CSRFPoCByAttacker">
<input type="hidden" name="mailing" value="true">
<input type="hidden" name="serviceMailing" value="true">
<input type="hidden" name="paymentMailing" value="true">
After this modification, the fully functional CSRF PoC will look like this:
<html>
<!-- CSRF PoC - generated by Burp Suite Professional -->
<body>
<form action="https://[Redacted_Dot_Com/api/changeInfo/basic" method="POST" enctype="application/json;charset=utf-8">
<input type="hidden" name="name" value="CSRFPoCByAttacker">
<input type="hidden" name="mailing" value="true">
<input type="hidden" name="serviceMailing" value="true">
<input type="hidden" name="paymentMailing" value="true">
<input type="submit" value="Submit request" />
</form>
<script>
history.pushState('', '', '/');
document.forms[0].submit();
</script>
</body>
</html>After modifying all the input fields and the enctype, I sent the exploit to the victim again. This time, the server accepted the request and returned a response with true, which confirms that the custom CSRF payload was successfully executed.
The server accepted and processed the request, which is why I mentioned CSRF bypass in the title — the bypass was achieved by modifying the input fields and the enctype value.
After documenting all the details, I submitted a detailed report to the triage team, including a clear explanation of the attack scenario, impact, and severity. A few days later, I received a response from the triage team confirming the reported CSRF vulnerability.
They classified it as a Low Severity issue and rewarded me with a $50 USD bounty for my finding and the use of a custom exploitation technique.
🕵️♂️💻 Appreciate you sticking around till the end — your curiosity fuels the hunt!
I hope this write-up gave you valuable insights into how a Cross-Site Request Forgery (CSRF) vulnerability can still be exploited — even when standard protections seem to be in place.
In this case, I successfully exploited the CSRF by modifying the input structure and content type to bypass default security checks. It’s a good reminder that security controls are only effective when correctly implemented.
👉 Interestingly, I’ve exploited this type of CSRF vulnerability many times — even in applications where a CSRF token was already present! Due to weak or misconfigured validation, I was still able to craft working payloads and was rewarded bounties for several of these findings.
I’m sharing these real-world bug bounty experiences to help others learn from practical examples and improve their own testing and detection strategies.
If this helped you learn something new or sparked a new idea, stay tuned — I’ll be posting more in-depth write-ups on web and Android security soon.
As always, feel free to share your thoughts, feedback, or questions — I love hearing from fellow hackers and learners.
Until next time, stay safe, stay curious, and hack responsibly. 🛡️💻
Can I see ur POC with clear report?
Sorry, I can’t share it due to security reasons, and this is a private program. However, in this write-up, I have clearly mentioned all the details regarding how I discovered and crafted the payload.
Please provide writesup for the bugs that u have found in apple bbp also
Hello Arjun I can’t share Apple bug details publicly without their permission. If they grant it, the write-ups will be available on AppSecWriteups.com