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

Re: Scope and complexity (was Re: More on XSS mitigation)

From: Daniel Veditz <dveditz@mozilla.com>
Date: Tue, 25 Jan 2011 10:57:41 -0800
Message-ID: <4D3F1D25.4010202@mozilla.com>
To: Adam Barth <w3c@adambarth.com>
CC: Lucas Adamski <lucas@mozilla.com>, public-web-security@w3.org
On 1/24/11 3:50 PM, Adam Barth wrote:
> To pick on one example, adding "inline" as script-src is disaster for
> security, yet its temping enough that a number of folks who've I've
> seen try to use CSP decide to add it.  IMHO, CSP would be better at
> mitigating XSS without the "inline" option for "script-src".

technical nit: inline is not a script-src and hasn't been in any
working code we've shipped. It goes in a completely different part
of the policy, moved from early versions of the proposal to
highlight the distinction that is not "just another source".

Clearly a policy with "options inline-script" disables XSS
protection. It will be documented as such and I expect site scanning
tools to issue warnings if they are updated to know about
Content-Security-Policy. Without that feature, however, developers
converting existing sites have to choose between using CSP or not,
black and white; with that option there is an intermediate step
where they can gain the benefits of CSPs other features, enabling
inline-scripts--disabling XSS protection--for specific pages that
are not yet converted and removing it as they are.

The option does undercut a major feature of CSP. If we want to get
all hair-shirt on site developers we can cut it. We could also
rename it for more clarity of its impact on the policy. "options
allow-xss" perhaps? Or better, if wordier, "options
disable-xss-protection"? Certainly those are less clear on what it
does from an authoring POV, but maybe that will further discourage
overuse.

-Dan Veditz
Received on Tuesday, 25 January 2011 18:58:23 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 25 January 2011 18:58:23 GMT