Finding Reflected XSS Through Persistence

Assalam u Alaikum!

My name is Ali Hassan, from Pakistan.

Today I want to share a bug bounty experience with you — a Reflected XSS I found on a public program (referred to here as redacted.com).

https://redacted.com/book/payment

https://redacted.com/book/payment

I'll explain it in simple words, the way I'd explain it to a junior, so that anyone new to this can understand it easily.

O you who believe! Seek help through patience and prayer. Indeed, Allah is with those who are patient. Surah Al-Baqarah 2:153

This ayat is the base of this whole story, because the bug I found came through patience — not by rushing.

Let's Start the Story

Let me tell you what happened.

I was testing the payment/checkout page of redacted.com. There was a parameter related to campaigns — something like a promo code or campaign name parameter.

I started with a basic, straightforward payload:

<script>alert(1)</script>

<script>alert(1)</script>

I tried this several times, with different variations, but nothing happened. No popup fired. It seemed like this parameter wasn't vulnerable.

This is where I practiced patience. I didn't give up, and I didn't just move on to the next target right away. I paused and thought — there must be a reason this payload isn't working.

Understanding the Real Reason

So I opened the page's source code and checked exactly where my input was landing inside the page.

Turns out, whatever text I entered was already being placed inside an existing script tag. Something like this:

<script>
   var campaignName = "MY_INPUT_HERE";
</script>

<script>
   var campaignName = "MY_INPUT_HERE";
</script>

This meant my input was already sitting inside a script block. So when I entered the alert payload wrapped in script tags, the browser treated it as plain text — because it was already inside an existing script, and a new script tag wasn't actually being opened.

Alhamdulillah, that's when it clicked for me — I finally understood what the actual problem was.

The Correct Payload

Now I realized — if my input was landing inside an existing script tag, I first needed to close that existing tag, and only then open a new one for my own code.

So I tried this payload:

</script><script>alert(1)</script>

</script><script>alert(1)</script>

Here's what it was doing:

— closed the existing script tag

And Alhamdulillah, this time the popup fired! It confirmed that this parameter was vulnerable to reflected XSS.

Final Url was:

https://redacted.com/book/payment/?campaignName=</script><script>alert(1)</script>&......

https://redacted.com/book/payment/?campaignName=</script><script>alert(1)</script>&......

POC

Impact

This vulnerability would trigger just by opening a crafted link — no extra click or form submission was needed. If an attacker sent this link to a logged-in user, they could potentially access that user's cookies (session data), since those cookies weren't protected with the HttpOnly flag.

Report Outcome

I submitted this as a report — but it was closed as a duplicate, meaning another researcher had already reported the same bug before me. No bounty this time, but it confirmed that my approach and finding were correct.

That's the whole story. I hope this helps a new bug hunter out there.

Allah Hafiz!