Free XSS reflection auditing tool
This morning Jaimie Sirovich released a tool for doing cross site scripting relfection security auditing. The way he describes it’s function is that it looks for parameters and injects a small snippet of HTML. If that HTML is seen once the server returns data you know it’s vulnerable to cross site scripting. Of course that’s not always the truth, and there are many other forms of XSS that are missed by this approach but it’s free, and you can’t beat free. He is talking about it in context of Blackhat SEO, where you can raise your own page rank by injecting XSS into pages that have a high page rank, although this is relevant to both search engine optimization as well as web application security.
But it begs a good question, actually. What is the single best string to use to test for XSS? The other day, I was talking to an auditor who was trying to inject an XSS vector but couldn’t use an equals sign “=” or a slash “/”. It sounds easy enough, but it ended up being really difficult, in that it had proper encoding. You’d be surprised how difficult it was to find a valid HTML attack that didn’t allow either of those. Finally I found that if you don’t close a <style tag, and it is immediately followed by another HTML tag, IE, Netscape 8.0+ in IE rendering engine mode and Opera will render an embedded JavaScript directive inside of a URL parameter. Whew! I thought I was loosing my touch.
So I would say, based on that experience, an equals sign and a slash seem like good things to want to test for if you want to have a higher liklihood of a successful attack (especially if you want 100% coverage with all browsers since the forementioned attack wouldn’t work in Firefox because of the JavaScript directive). The simple cross site scripting string <XSS/> doesn’t test for either. So maybe <XSS=XSS/> is a likely choice? Now that also doesn’t test if you can jump out of quotes. But maybe that doesn’t matter because it assumes you’ll have to try to jump out of the quotes yourself. But if it were me, I’d try alf’s trick of putting in a single and double quote: ‘”<XSS=XSS/>
Now that won’t test for DOM based attacks but maybe that’s not a problem. The XSS locator (the first vector on the XSS CheatSheet) attempts to locate these for you by attempting to break out of encapsulation by escaping escapes in JavaScript. It’s got a high probability of jumping out of any quotes or encapsulation, but the problem is that it is a pretty long string, so perhaps ‘”<XSS=XSS/> is a better alternative. Who knows?
So back to the original point of Jaime’s post. Does this help with SEO? Arguably it will help a little, but it seems to me that reflected XSS and automatic 301 redirects are the worst way to improve page rank. It seems to me that getting pages that are highly ranked to store the XSS vector and show it once the browser reaches the site (which has already been to that URL) it would have a much higher probability of increasing page rank.
As a side note, the two important things for SEO is either to redirect the valid traffic that hits the site (in which case the search engines don’t need to see it and it can be as obfuscated as it needs to be) or it needs to improve page rank, in which case it needs to be valid HTML syntax, or close to it, for the crawlers to see the link. If it’s the latter, it’s more about HTML injection to inject links, than it is about JavaScript injection, which is more about the former (redirecting or hijacking the valid traffic away from the vulnerable page). In this time of SEO flux, webmasters will do anything to get ahead. Anyway, thanks, Jamie for the tool!
June 30th, 2006 at 10:46 am
The other day, I was talking to an auditor who was trying to inject an XSS vector but couldn’t use an equals sign “=” or a slash “/”.
Maybe you can help me with an XSS vector
<a href=”…”…$1>
I can only inject data at the $1. I’ve already figured out that, in IE, I can do something like…
<a> to add an onload event handler, even though I can’t add spaces.
In Firefox, onload/…=… will add an onload event handler, but I can’t manipulate the URL that early on.
I can’t insert spaces (as I said), (’s, )’s, or single quotes, among other characters. Double quotes get turned into " and ampersands get turned into &, so I can’t do something like &#x…;.
So, basically, it’d appear that I can’t really insert javascript, via IE expressions with the style attribute. -moz-binding doesn’t help since, as far as I know, only IE is vulnerable to exploitation.
Any ideas as to what I can do?
…or is there a more appropriate place I should be asking?
June 30th, 2006 at 11:07 am
What about the grave accent char? IE: `
Onload doesn’t work for links anyway (it does with BODY tags though), so you are better off with style attributes, or onmouseovers or something similar.
June 30th, 2006 at 12:52 pm
Err…. I actually meant onclick, heh, but anyway… `’s aren’t allowed, either. Here’s the exact regular expression I’m sorta trying to have my vector match (it’s a bbcode parsing routine):
$patterns[] = “#\[url\]([\w]+?://([\w\#$%&~/.\-;:=,?@\]+]+|\[(?!url=))*?)\[/url\]#is”;
Normally, the above would, I think, be sufficient to protect against XSS, since double quotes aren’t allowed (and since the href attribute is surrounded by double quotes), but there is a certain trick one can employee, in this case (relating to how the bbcode is parsed), to get outside the double quotes.
Unfortunately, I’m not willing to disclose much more information than that, publically.
June 30th, 2006 at 12:57 pm
I forgot to mention - I’d be willing to provide more info. via email, if you were interested (incl. a link where you could try out varrious vectors)..
June 30th, 2006 at 1:43 pm
Yah, yawnmouth, just email me (click on about us on the homepage, my email’s on there). It’s hard to tell without being able to test it.