The revival of (cross site) script kiddies.

First off, a Happy 2019!

Being in charge of adjudicating Microsoft’s Cloud Bug Bounty; we see many “low hanging fruit” XSS bugs coming through. While we have tools that catch these bugs, sometimes they slip through the cracks. Also, since machines won’t find every.single.bug.ever; we pay out for interesting bugs, and bump up payouts for high quality reports. Sadly though, many of these bugs make us utter a “how come our tools didn’t catch this?”, rather than a “wow, that’s an interesting approach!”. Needless to say, the latter would get higher payouts.

XSS 101

I hope most of you know cross site scripting (XSS). If you can inject active content (we mean JavaScript, 9 out of 10) into a page that, preferably others will see, you have cross site scripting. There may be other nuances to this, but that’s generally my approach. The best way of showing these; is to perform an

alert(document.domain);

which will display the current context’s domain. Showing the current domain, rather than a “123”, “foo” or “pwnage!!1!” message, clearly shows which domain’s DOM, you have access to. In the world of embedded iframes, that shows to be useful.

Escaping

Most XSS payloads, and there are several out there, are designed to be injected in a page’s DOM. Since the application you’re targeting may be prefixing some controls, you may have to close a previous tag. The tainted data may be included as an HTML attribute, as part of of a JS script block or just as general HTML content. For these, a payload like:

• ” onmouseover=”alert(123)
• “; alert(123); var foo=”
• </textarea><script>alert(123);</script>

May have to come in effect. Needless to say, that list is endless.

</rant><request>

Being on the receiver side of bug bounty submissions, and spending several evenings in HTTP access_log or W3SVC1 log files performing pattern analysis, I see a significant higher breadth than depth. Meaning, that many will try a vanilla <script>alert(123)</script> payload, rather than following how the data ends up in the DOM. Missing out on bugs, and payouts.

So for that, I’d ask that if you find yourself mindlessly copy pasting XSS payloads in each field, don’t see the absence of a alert dialog box as a binary (“the site is not vulnerable”), maybe you just need to perform some taint analysis and try again.