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

On Jan 24, 2011, at 15:50, Adam Barth <w3c@adambarth.com> wrote:

> It's not the difficulty of implementation that concerns me.  We
> certainly have the engineering bandwidth in WebKit to implement CSP.
> What worries me is the complexity of using CSP.  Part of trying to
> build something simple is that its easier for developers to understand
> and use correctly.
> 
> 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".

Yes, the inline option was a topic of significant discussion.  As Dan mentioned, this was primarily intended to provide a scaffold to help port prepare websites incrementally.  Removing it certainly is an option.   Or perhaps the nonce proposal could provide an alternative solution (though that requires modifying the page yet again, which doesn't entirely solve the incremental rollout problem).

But that particular feature isn't the core issue; the gist of your argument seems to be that writing policies in CSP is too difficult.  Can you provide examples where writing a writing a secure CSP policy is more difficult than in your proposal?  For example, the policy below protects against XSS and many more threats than your proposal does, yet is also the most minimal policy you can specify:
X-Content-Security-Policy: allow 'self'
> 
> I agree that we should be threat-focused rather than attack-focused.
> We seem to agree that the threat we'd like to mitigate is the threat
> from an attacker who can inject content (e.g., HTML) into the honest
> site, right?

Yes, we are concerned primarily with maintaing the integrity of a website by mitigating content injection attacks.  As the spec says, XSS is our primary (but not exclusive) focus.

> 
> Indeed:
> 
> ---8<---
> Whenever the user agent would load a plug-in on behalf of a document,
> if the document has an "allowed scripts policy", if the origin of the
> URL from which the user agent retrieved the plug-in is not contained
> in the allowed scripts policy, instead do not load the plugin and
> queue a task to fire a simple event that bubbles named
> SecurityViolation at the element that attempted to run the script.
> --->8---
> 
> More problematic than Flash is Java, actually, because setting
> mayscript="false" doesn't actually prevent the Applet from script the
> page.  O_o
> 
> Adam

Ah thanks, I had missed that.  We had originally had rolled plugin restrictions into the script category, but that had the undesirable effect of having to confer scripting trust to websites just to play a video.  :/  Ideally I'd like to control plugins by classid so you could specify a policy to only permit say Quicktime content from a given site, but we decided that was too complex to bite off at this time.

Didn't know that about Java... O_o indeed.
  Lucas.

> 
>> On Jan 21, 2011, at 2:20 PM, Adam Barth wrote:
>>> Security is a multi-faceted topic that we're unlikely to solve all at
>>> once.  One approach that might work well is to have in mind a broader
>>> vision of where this security mechanism can go, but to make progress
>>> one step at a time.  This general approach has worked well for HTML,
>>> for example.  The first version of HTML didn't have every conceivable
>>> feature under the sun.  It started small and over time grew to be able
>>> to handle more and more use cases.