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

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

From: Daniel Veditz <dveditz@mozilla.com>
Date: Fri, 21 Jan 2011 18:21:58 -0800
Message-ID: <4D3A3F46.6080403@mozilla.com>
To: Michal Zalewski <lcamtuf@coredump.cx>
CC: public-web-security@w3.org
On 1/21/11 2:44 PM, Michal Zalewski wrote:
> 1) Allowing policies to be defined in HTTP headers; and then parse
> first relevant <meta> if no HTTP header policy is found. There is a
> compelling argument to be made in favor of HTTP headers (a reduced
> likelihood of mishaps, less clutter with complex policies); and in
> favor of <meta> (easier deployment in some use cases). I don't think
> it's productive to build two competing approaches around this
> distinction alone.

I'd be perfectly happy to add a <meta> header to CSP. We originally
had it, in fact, but took it out to simplify the proposal. <meta> is
a less secure way to specify the policy so I'm not willing to remove
the HTTP header, but it does extend the use to more scenarios.

> 3) Allowing inline scripts guarded by policy-specified nonce tokens
> (<meta> says "inline-script-token=$random", inline scripts have
> <script token="$previously_specified_random">...</script>). This
> eliminates one of the most significant issues with deploying CSP or
> this proposal on sites that are extremely concerned about the overhead
> of extra HTTP requests; for example, much of *.google.com is subject
> to such concerns.

That can be added to CSP quite easily if it's secure and useful.
Most sites we've looked at are so awash with external <script>
requests (many of them to Google!) that it doesn't seem to be a
large concern on most sites. I worry such a feature would be misused
more often than used correctly and give a false sense of security.

> 4) Having a policy flag to choose between origin-based specifications
> (which are more convenient, but problematic for two reasons: the JS
> API problem outlined earlier, and the out-of-order / out-of-context
> loads described in the mail below) and explicit URL whitelisting (more
> verbose and harder to maintain, but significantly safer from that
> perspective).

We didn't want to propose such a verbose idea as part of the initial
CSP spec, but we thought about it and the syntax can be extended to
support full URIs. Anything that verbose is inappropriate for an
HTTP header or <meta> tag, but that's one reason CSP supports
external policy files. Not sure how to solve the order problem but
that doesn't sound like it's something that can be solved by a "policy".

-Dan Veditz
Received on Saturday, 22 January 2011 02:22:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 22 January 2011 02:22:40 GMT