Internet Explorer Accepts Style Attributes on Closing HTML Tags
There’s a really interesting thread on sla.ckers.org talking about bypassing some fairly rigid anti-XSS vectors that allow nothing that looks like HTML. Specifically it doesn’t allow <[A-Za-z] which does limit the vectors pretty substantially. In the process of working through the attack vector Hong mentioned that an attack could surface inside of an end HTML tag. Here’s the example code:
</a style="xx:expression(alert('xss'))">
It gets around the filter because there is no letter immediately following the open angle bracket, it is a forward slash. I’m not exactly sure why any end attribute should be allowed to have style information associated with it, since that doesn’t really make sense contextually. This doesn’t appear to work in Firefox or Opera, but it does work in Internet Explorer, which makes up a vast majority of the browsing community. I wanted to wait until the exploit actually worked before posting it, as it was a very interesting way to bypass filters that probably wouldn’t have worked in any other way (with the possible exception of injecting nulls). Nice find, Hong!
March 19th, 2007 at 10:32 am
Is this going to be added to the cheat sheet?
March 19th, 2007 at 11:58 am
No, nulls didn’t work in this case either - they might work inside the tag but not between
March 19th, 2007 at 11:59 am
RSnake, your blog has a somewhat extreme reaction to angled brackets… I will try escaping them.
No, nulls didn’t work in this case either - they might work inside the tag but not between < and the tag name. So this was really the only loophole. Interestingly, this only works if you have a real tag name (but not any tag) following the slash, that’s why my automated test didn’t find it. If you look at the DOM - there really is an element with the tag name “/A”. Crazy…
March 19th, 2007 at 12:19 pm
Actually, I run the test again and Opera will also accept while Firefox accepts and . But they simply assume that it is a closing tag for a missing opening tag and insert this opening tag - attributes are ignored. Quirks of HTML parsing. IE on the other hand accepts the slash for 36 of 67 tags in my list (pretty much all structuring tags) and accepts attributes as well.
March 19th, 2007 at 12:20 pm
I forgot… I meant: Opera will also accept </br> while Firefox accepts </br> and </p>
March 19th, 2007 at 6:46 pm
I think that the discovery of this attack vector has major, as in global impact on WAS. I’ve been studying the .NET framework for over a year now attempting to find any security related issues, other than the ones Dinis and the other OWASP members have found regarding Full and Partial Trust of .NET assemblies.
By default ASP.NET 1.x and 2.0 implement a XSS validation class that detects potential attack vectors for each request. This validation routine catches most of the attack vectors I’ve seen and tried. This particular attack vector was able to bypass the built-in validation ASP.NET implements.
Microsoft states not to rely solely on this validation routine, but most developer do. As far as I know, this is one of the few, if not the only, attack vector that has been published/disclosed that is capable of bypassing the built-in XSS validation class.
Many thanks to everyone who assisted in the discovery of this attack vector. Now everyone needs to start patching their ASP.NET web applications!!
March 20th, 2007 at 1:43 am
I have to clarify that I see it somewhere before, but I don’t remember where I see it.
April 7th, 2007 at 5:25 am
Mephisto,
The vector on how to bypass ASP .NET 2.0 request filtering was published on BID 20753 [http://www.securityfocus.com/bid/20753].
Technical details here:
http://www.securityfocus.com/archive/1/464796
Please note that although the details of the attack have been made public recently on bugtraq (see previous URL), they were forwarded and confirmed to CPNI (formally known as NISCC) on October 2006:
http://www.cpni.gov.uk/docs/re-20061020-00710.pdf
NISCC forwarded the research to Microsoft. In short, Microsoft’s response was that you should not rely on ASP .NET request filtering and provide your own filtering on top of that.
Hope you find the links useful for your research.
Regards,
AP.