Re: CSP and default policies

Hi. I was just wondering, what if there is an "enable-default-restrictions"
directive for your blacklist model? Sites that are willing to take the risk
of always applying new restrictions may specify this directive once and for
all. "Default restrictions" might change due to browser
implementation. Other sites that don't want to take this risk may specify
only the directives (specific restrictions) he likes. Is this a bad idea?

David Huang

On Fri, Apr 1, 2011 at 2:24 PM, Brandon Sterne <bsterne@mozilla.com> wrote:

> Hello public-web-security,
>
> There is still an open question as to the set of restrictions that
> should be enabled by default in CSP.  Jeff H. pointed it out and linked
> to some relevant posts here:
> http://lists.w3.org/Archives/Public/public-web-security/2011Feb/0145.html
>
> Collin made a good point in saying "it should be possible to send a
> frame-ancestors directive without implicitly also changing how
> javascript URLs work."
>
> The "empty policy" that was being discussed in that context is not
> actually the tricky case.  Enough of us are content to make the empty
> policy a no-op as to sidestep this particular issue.  Take the case,
> though, of a policy with no known directives.  What restrictions should
> be enabled there?  So, the question is not "what should we do with an
> empty policy?", but "when do the default restrictions kick in?" Without
> them there is no XSS protection, after all.
>
> Answers to this question include:
> 1. when any directive is specified
> 2. when script-src or object-src is specified
>
> 1 and 2 can be thought of fundamentally as a "whitelist" and a
> "blacklist", respectively, from the perspective of XSS mitigation.
> There are various advantages and drawbacks to each approach which I've
> tried to catalog below.  This group needs to decide now which
> fundamental approach is used in Content Security Policy.
>
> 1. Whitelist model
>   Defined: Default restrictions are enabled when any directive is
>     specified. Nothing is allowed unless explicitly allowed in the
>     policy
>
>   Pro:
>   - never be surprised by a feature being added to browsers that your
>     policy doesn't restrict
>   - enables an "optimal policy" development strategy by starting
>     with an empty policy and adding incrementally until site "works"
>   - more secure "average policy" since XSS protections will be
>     enabled more frequently
>
>   Con:
>   - be surprised by a change to the semantics of an existing
>     directive
>   - be surprised by a change to default restrictions
>   - coupling between base restrictions and potentially unrelated
>     directives
>
> 2. Blacklist model
>   Defined: Base restrictions only apply when a script-y directive is
>     specified. Other restrictions are only applied when additional
>     directives are specified.
>
>   Pro:
>   - never surprised by change to default restrictions (there are
>     none)
>
>   Con:
>   - be surprised by a change to the semantics of an existing
>     directive
>   - be surprised by a new feature added to browsers that your policy
>     doesn't restrict
>
  - less secure "average policy" since copy/pasting another site's
>     CSP is more likely to permit your site to "work"
>
> Both cases involve potential "surprises" to web sites when changes are
> made to CSP.  It is for this reason that it may be advisable to
> introduce a "compatibility level" directive into the grammar that
> communicates to the user agent the set of directives the server is aware
> of and beyond which the user agent will not enforce.  This may,
> unfortunately, evoke bad memories of a "versioning" debate we had early
> on via mozilla.dev.security but it's a topic that seems unavoidable in
> some ways.
>
> If you do not agree that the topic of version compatibility is
> unavoidable, consider the two following cases which should ideally both
> be supported:
> A. a web site presently enumerates the full set of capabilities that
>   it needs in order to function and wishes to express a policy that
>   restricts all capabilites beyond this set
> B. a web site presently knows that it wants to express a policy
>   prohibiting a risky set of capabilities, but does not want to
>   introduce breakage at any point in the future if changes are made
>   to CSP
>
> I argue that both cases cannot be supported under either 1 or 2 above
> without some compatibility level expressed in the policy.  I certainly
> welcome any debate on that point and look forward to your responses.
>
> Cheers,
> Brandon
>
>