Re: XSS risk from iframe@doc?

On Jan 17, 2010, at 9:56 PM, Ian Hickson wrote:

> On Sun, 17 Jan 2010, Maciej Stachowiak wrote:
>> 
>> Adam did specify "weak XSS filters". Even though filters based on 
>> blacklisting instead of whitelisting are poor design, I suspect a lot of 
>> sites still use them and therefore we might make existing sites more 
>> vulnerable.
> 
> Yes, but we do so every time we invent a new event handler (e.g. 
> onhashchange), content embedding mechanism (e.g. <video>), styling 
> mechanism (e.g. <style scoped>), element with special styling or parsing 
> rules (e.g. <ruby>), feature affecting the rendering (e.g. hidden=""), 
> attribute affecting the UI (e.g. <input required>), etc etc etc.
> 
> I mean, pretty much any new feature in HTML5 can be be a problem for an 
> XSS filter with a matching weakness. If we start being worried about this, 
> we are likely to end up frozen in fear, unable to invent anything.

Most new script injection techniques are either on* event listener attributes or URL-valued attributes. Even a "dumb" XSS filter could handle those in a general way. But doc="" is different from either of those. Can you think of other examples? You are correct that other forms of reflective element or attribute could create security risks, but most of them do not lead directly to script execution.

I'm not saying Adam's concern rules the feature out, but we should think about whether there is a way to tighten it up or find a different way to do things. Making it solely an IDL attribute and not a content/markup attribute is one way to avoid script injection risks, but may not serve the use case equally well. (In fact, it's not any harder to document.write or use innerHTML on the content document, so a script-only feature might not be worth doing). Making it require sandbox="" mitigates the risk a tiny bit as it requires injecting two unknown attributes. Perhaps there is something else creative we can do.

Regards,
Maciej

Received on Monday, 18 January 2010 08:36:50 UTC