Bug Bounty Stories #2: Tale of an XSS issue

XSS due to an unintended code pattern where my payload escaped the JSON and found its way into DOM!

Image Credits: SecurityGOAT (That’s me ;)

Once upon a time, I was pentesting a quite popular website. That website was quite old and I have been using it since my University days, so the chances of any easy bugs was not a possibility in my eyes.

And my motivation for pentesting it came from a report I read on how badly its APIs were coded, having quite a lot of AuthN & AuthZ issues!

So I was quite determined to test for any AuthN & AuthZ issues maybe in some endpoints that might have been missed by others. Maybe…

The Start

So I set out and tried some easy stuff to start with — changed my name and added XSS payload there. Nothing interesting showed up since my payload was encoded, plus there was some restriction on the characters allowed in the name.

So I left the XSS payload there and moved onto other pages and just as I moved to the other page, voila, I see the XSS popup right on my face!

Woah! That was quite easy! No effort whatsoever :D

Root Cause

But I wanted to know why did it happened, that is, the root cause behind it.

So I checked the page source and looked for the payload I had injected. I found that my payload (that is, my username) was sent over in the <script> tag, but it was inside a JSON payload. Plus my username was reflected 2 times in that JSON payload.

It was interesting to see alert popup but I didn’t yet saw how that happened? What was the root cause? Because root cause is where the juicy stuff is right!

And main motivation was to understand how it happened so I know another code pattern where I can execute my JS payloads!

Vulnerable Code Snippet

So I started to dig and copied that snippet of vulnerable code.

What it boiled down to was:

Due to the username not being encoded, when sent in the JSON payload the </script> tag terminated the initial script tag where this JSON payload was embedded in!

And sublime text made it quite easy to verify that :) (Inspector window should have shown that too, but I checked the page source that time…)

But anyways, we know the reason now: The username was reflected at 2 places and the first one helped to close the initial script tag and the second one then escaped out of that JSON context and created its own script tag and ran my payload!

Severity?

This issue was a stored Self-XSS :/

Ah! so lame!! so much lame!

But anyways I didn’t had much privileges on the application and gave them a possible attack scenario (which turned out to be impossible in their case).

You can read more on weaponizing self-XSS, which I covered in this post:

Powering the Lamest: Self-XSS FTW!

But in my case, things didn’t worked. So I just helped get this lame issue fixed :)

Anyhow it was interesting to see the code pattern that led to this issue and that was my takeaway from spending my 5 mins pentesting ;)

The Fix

The easiest fix would have been to encode user payload and avoid any XSS issues!

But I feel that there’s no reason to let a user add a <, >, ( or ) in their username either! So I feel that a safelist of characters could have been built as well to avoid having the XSS payload in the first place!

Other than that I feel that the company can also add a CSP that avoids any inline script execution without a nonce.

But this can bite back if not done well:

https://securitygoat.medium.com/bug-bounty-stories-1-tale-of-csp-bypass-in-an-electron-app-f669f6ecefc9

Anyways if you go with sane things and don’t add any hacks, you would be fine! Because as I had mentioned before XSS is Dead! Really!!

https://securitygoat.medium.com/xss-is-dead-we-just-dont-get-it-b1a8cfc43733

Closing Thoughts

I hope you enjoyed this post and learnt something interesting. Or maybe it was a code pattern you already knew about, but hopefully I gave to an important point to always dig deeper and understand why the payload actually worked! What was the root cause? Is there any pattern here? And so on and so forth… This will take you much ahead and give you an edge over your peers and maybe personal satisfaction :)

Let me know your feedback in the comments below and feel free to connect on twitter: @_SecurityGOAT

If you want to learn some topic, send me DM over Twitter and I will write about it :)

Lastly, if you have been enjoying my work and would love to support me, consider checking my Patreon page or you can even Buy Me a Coffee :)

See ya!
Until next time, keep learning and happy hacking.