Web application penetration testers, have you ever run into a situation where you can inject into the attribute of a tag and break out of the attribute, but not the tag?
For those who can only <script>alert('XSS')</script> this is a lost cause... BUT NOT FOR THE SASSY!
No, the sassy PenTester will just create a new attribute, specifically an event handler. An event handler attribute will launch some bit of JavaScript code when a certain event occurs. Some are more useful than others. If we're injecting into the "src" attribute of an "img" tag, we can point the image to a URL that doesn't actually exist, causing an error. Conveniently, in many browsers there exists an "onerror" attribute which runs its contents as a set of Javascript commands when loading the image produces an error. Here's an example of a string we could inject:
http://www.fail.nod/not_there.jpg" onerror="alert('XSS')
Win!
What if we have control over the contents of the "value" attribute of a text box? This is pretty common in search boxes that populate the search box of a search results page with the previous query entered, in case you need to make small changes, like correcting a typo. Normally we could use the following to pop an alert box:
"><script>alert('XSS')</script>
But for the sake of the point of this blog post in general, let's say that for some reason (perhaps an incomplete patch of this XSS flaw) the application filters angle brackets (< and >). Assuming we can't use alternate encodings or something of that ilk, this forces us to work with attributes instead. My favorite is "onmouseover", which triggers when a user moves their mouse over the element we have control over. The only problem is, what if we have a REALLY small text box off in a corner of the page that no one can see? This doesn't do us much good.
Here's where it gets fun, and where CSS comes into the picture.
With CSS, we can define the size and position of an element. Better yet, we can use the "style" attribute to define these properties inline. The following attack string will cause our text box to be the size of the entire page, and will pop an alert box when the user moves their cursor while it's over any part of the text box (which is conveniently gigantic).
" style="position:absolute;top:0px;left:0px;right:0px;bottom:0px" onmouseover="alert('XSS')
And now, just for giggles, imagine that our quotes are being escaped with backslashes. This actually doesn't prevent us from breaking out of attributes, but it does make writing our payload a bit harder. Fortunately, if you can avoid using spaces in the values of attributes you don't need to delimit them with quotes. In terms of JavaScript, there are a few tricks to avoiding the use of quotes. My favorite is to define a regex, then take its "source" attribute, which is essentially just the raw pattern itself, represented as a string. For the string "intertubes", you could write the following:
/intertubes/.source
This can be used interchangeably with strings, so our attack string can look like this, with an extra junk parameter at the end, just to prevent the trailing quote from interfering...
" style=position:absolute;top:0px;left:0px;bottom:0px;right:0px onmouseover=alert(/SpiderLabs/.source) fakeattrib="
So what have we learned today? XSS flaws can be hard to patch correctly, and with the right tricks and a little sass, even difficult exploitation scenarios can be leveraged into reliable attacks. Always, always retest any supposedly fixed vulnerabilities to ensure that a proper fix is in place.
