Re: [Content Security Policy] Proposal to move the debate forward

On 1/28/2011 12:03 PM, Adam Barth wrote:
> Well, the current design of CSP is difficult to implement
> incrementally.  Even the simplest policies affect font loading.  It's
> very convoluted to define a subset of the language that lets you
> control script execution without also controlling font loading.
>

I'm still trying to triangulate your specific, core concern about
complexity as the overriding criterion.  Since we apparently established
that the cost of browser implementation is not that high, and the
complexity of the policy language is similar in the supposedly more
common, minimal case of XSS mitigation (i.e. its at least proportional
to the detail and benefit as desired by the web developer), what
specific cost are we incurring in the proposal CSP model vs. your proposal?

Is it the cost of standardization?  If so I'd point out (as others have
already mentioned) one of the primary goals of this group and CSP in
general is to develop a "A policy language intended to enable web
designers or server administrators to adjust the HTML5 security policy,
and specify how content interacts on their web sites."   We don't move
towards that goal by ignoring how these various security mechanisms
should interact with each other and focusing exclusively on the most
minimal implementation for a narrow attack vector.  To standardize
something sooner while undermining one of the key goals doesn't feel
like a win to me.

Is it just extensibility?  It seems like you are perhaps fundamentally
objecting to the default "allow:" policy, insofar that it is implicitly
coupled to all of the other defined directives.  Yet, we cannot evaluate
the utility of the "allow:" directive in a vacuum of only XSS
mitiations.  We have to consider how important that directive is once
you have a more rich and granular policy language.   It may not seem all
that useful, yet without it a simple XSS mitigation policy cannot be
written simply.  Ignoring that and focusing just on XSS mitigation
doesn't actually solve the problem; it just kicks the can down the road
to the point that its much harder to solve those actual problems once
the fundamental syntax has already been fixed.

If the concern is around the future extensibility then by all means lets
focus the discussion on that.  But removing all other non-XSS
mitigations simply dodges the fundamental problem and only makes it
harder to solve it later.

>> On the other hand, if all the browsers
>> implement different initial subsets of CSP, that's not particularly helpful
>> for site authors. If a discussion of what the initial feature set is gives
>> each browser maker some idea of what the others are likely to implement, and
>> also exposes decision makers to the arguments in support of each feature,
>> that will be a win.
> The model works well for CSS.  Different vendors implement different
> features at different times, including experimental features.  The
> popular ones get folding into the main spec.  That seems like the
> model we want here, both now and for the future.
>

Those features are additive and their implementation is mostly
orthogonal.  It seems like security models are different... security
mechanisms are largely subtractive, and the interactions between them
determine whether or not a given threat can be effectively mitigated.  
We are defining a policy language that will be applied to existing
content, not simply additions to an existing soup of tags.  Having a
bunch of independent security mechanisms without a common syntax,
delivery mechanisms or clearly defined intersections between them
undermines the intended benefit to web developers and admins.  What
would be useful is a consistent language that lets web developers and/or
admins have a reference like OWASP provide clear examples that state "if
you want to protect your password reset page, here is a list of threats
to be concerned about, and a corresponding sample CSP policy".  

I like the use case page you started;  I think that is a good mechanisms
to organize our discussion around.  I hope some of the likely users of
these security mechanisms will chime in with their specific use cases. 
Regards,
  Lucas.

Received on Monday, 31 January 2011 00:20:37 UTC