W3C home > Mailing lists > Public > public-web-security@w3.org > January 2011

Re: More on XSS mitigation (was Re: XSS mitigation in browsers)

From: Michal Zalewski <lcamtuf@coredump.cx>
Date: Fri, 21 Jan 2011 17:19:21 -0800
Message-ID: <AANLkTi=kJcEEpgOYOviHDfZoZNHF8wQfyx_CWb6nfrwK@mail.gmail.com>
To: Adam Barth <w3c@adambarth.com>
Cc: public-web-security@w3.org
> The reason we're here having this discussion is because we'd like to
> come to an agreement about what to do.

I wonder if the vendors can settle it, though? Arguments both ways
make sense, and are somewhat comparable in terms of their
significance, which can make this difficult. I don't want to get ahead
of the debate, though, so maybe let's leave it at that :-)

> Thinking along those lines, what do you think of the following mechanism:
> <meta name="no-more-script">
> After this element is added to the DOM, the user agent refuses to
> compile any more script.  Period.  Full stop.

That's probably not bad, and pretty flexible in function of its
simplicity. It's a bit trickier to fit plugins into that model.

It takes away the ability to use HTTP header policies for sandboxing
same-origin user HTML, which is a possible if unintended use of CSP.
We probably don't care, though.

The one substantial roadblock to embracing this or any other approach
that limits inline scripting later on in document body is dealing with
event handlers for UI interaction. Manually attaching several hundred
of them to document elements from JS code looks like a very major

With no-more-script approach specifically, you actually need to
register an onload handler or a 1 ms timeout, or else you won't be
able to look the relevant elements at the time your JS first executes.
I wonder how to lessen this pain. I suspect offering some options here
would be essential to any successful proposal. No idea how to do it
cleanly, though.

Received on Saturday, 22 January 2011 01:20:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:09:25 UTC