CSP and default policies

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

Received on Friday, 1 April 2011 21:25:04 UTC