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

On Fri, Jan 21, 2011 at 3:16 PM, Michal Zalewski <lcamtuf@coredump.cx> wrote:
>> Your approach seems, generally, to provide all the various options
>> when you think more than one thing might make sense.  At a high level,
>> I don't think that's a good approach.
>
> My general concern is that there is a risk of the discussion devolving
> into nit-picking over peripheral aspects that have comparable merits,
> potentially leading to fragmentation (CORS vs Microsoft's
> XDomainRequest; toStaticHtml versus innerSafeHtml). If these are the
> key differentiators between competing proposals, and the reasons why
> WebKit or MSIE may end up with an approach incompatible with Firefox,
> then I think a less principled stand may be ultimately more
> beneficial, even if it results in a less elegant specification.

The reason we're here having this discussion is because we'd like to
come to an agreement about what to do.  We could, of course, all go to
our respective corners and implement something different, but that
would be costly for the web.

> That said, #1, #2, and #3 aside, I think the concern in #4 - the
> practical safety of scoping these policies to origin level - deserves
> some consideration sooner than later (also in the context of CSP).

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.

If you'd like to use script in your page, you'll need to include your
scripts before this element.  That script can, of course, listen for
events and schedule timeouts.  We just can't take any more strings and
parse them as script.

Adam

Received on Saturday, 22 January 2011 00:25:38 UTC