The Curious Case of Hidden Phone Number Change & POST-to-GET CSRF — A Hacker’s Tale
Introduction
Sometimes, the most interesting vulnerabilities aren’t the flashy ones — they’re the sneaky, almost accidental bugs that show just how broken the logic behind a system can be. This is one such story where a "simple" password change page led me down a rabbit hole, exposing insecure phone number updates, exposed JS files, and a site-wide CSRF risk.
The Setup: A Weird Account Settings Page
I was casually poking around a web application’s user settings section when something immediately stood out:
There was only an option to change the password — no UI to update email, name, or even the phone number. This felt odd for a platform that relied heavily on phone-based verification.
The Discovery: A Phone Number Change Endpoint Hidden in Plain Sight
I decided to do some digging, and sure enough, a JavaScript file revealed an unused (and undocumented) phone number change endpoint. However, the parameters required were unclear. I had no documentation, and the request wasn’t being triggered anywhere in the app’s visible functionality.
Connecting the Dots: Reusing Registration Parameters
This is where intuition kicked in. During the registration process, I had noticed the parameters the site used to collect phone numbers. I decided to try using the same parameters in a request to the phone number change endpoint. Surprisingly — it worked.
The Protection Layer: CORS and CSRF
The endpoint was behind CORS and had CSRF protection — so at first glance, exploiting it externally seemed difficult. But after some experimentation, I found a surprising twist:
The site’s backend was vulnerable to a POST to GET CSRF attack. By converting my request to a GET request with parameters in the URL, CSRF protection was completely bypassed.
Impact: Site-Wide CSRF Exposure
This wasn’t just about phone numbers anymore. This POST to GET CSRF weakness applied to every endpoint across the site. Any sensitive action — including changing critical account information — could potentially be triggered by a malicious site tricking the user into visiting a link.
The Disappointing Reward — or Lack of One
Unfortunately, the platform’s reward policy only covered High and Critical vulnerabilities. This issue, despite its real-world exploitability, was downgraded to Medium, meaning no bounty payout.
This is the reality of bug bounty sometimes: cool bugs with real impact go unrewarded just because they don't tick the "critical" box.
Key Takeaways
- Don’t assume what you see in the UI is all the functionality that exists.
- Exposed JS files are goldmines for hidden functionality.
- Reusing parameter conventions across different endpoints can unlock unintended functionality.
- CSRF protections that only work for POST requests are not protections at all.
- Not every valuable bug gets you paid — but every bug teaches you something new.
Final Thoughts
Even if this bug didn’t get me a bounty, it’s a fun reminder that security is often a patchwork of half-implemented protections, forgotten endpoints, and accidental bugs — and sometimes, all it takes is a curious eye to find them.
Note : Used chatgpt for better language.
Comments
Post a Comment