Paid Advertising
web application security lab

Internet Explorer Accepts Style Attributes on Closing HTML Tags

There’s a really interesting thread on 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!

8 Responses to “Internet Explorer Accepts Style Attributes on Closing HTML Tags”

  1. yawnmoth Says:

    Is this going to be added to the cheat sheet? :)

  2. Wladimir Palant Says:

    No, nulls didn’t work in this case either - they might work inside the tag but not between

  3. Wladimir Palant Says:

    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…

  4. Wladimir Palant Says:

    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.

  5. Wladimir Palant Says:

    I forgot… I meant: Opera will also accept </br> while Firefox accepts </br> and </p>

  6. Mephisto Says:

    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!!

  7. Hong Says:

    I have to clarify that I see it somewhere before, but I don’t remember where I see it.

  8. Adrian Pastor Says:


    The vector on how to bypass ASP .NET 2.0 request filtering was published on BID 20753 [].

    Technical details here:

    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:

    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.