Re: ISSUE-4: Policy combination

It appears I failed to clearly specify the intended behavior in the document, but the feature Brad describes (simultaneous report-only and blocking modes) was certainly intended in the original design of CSP.  This feature enables a great method for sites to iterate toward an "optimal" policy: serve a permissive policy in blocking mode and a more restrictive policy in report-only mode, and then once confidence is obtained in the correctness of the more restrictive policy, it can be uplifted into the blocking mode.  Indeed, I made several public statements to this effect at OWASP events this year (Irvine and DC).

When I agreed with Adam's proposal for "first policy wins", my assumption was that the above was still true.  I assumed that the first report-only policy would win and, independently, the first blocking policy would win, but that these policies would be carried out separately by the UA. Does this seem to be a reasonable approach?

Cheers,
Brandon


----- Original Message -----
From: "Brad Hill" <bhill@paypal-inc.com>
To: "Adam Barth" <w3c@adambarth.com>
Cc: "Brandon Sterne" <bsterne@mozilla.com>, public-webappsec@w3.org, "Giorgio Maone" <g.maone@informaction.com>
Sent: Friday, December 9, 2011 12:58:08 PM
Subject: RE: ISSUE-4: Policy combination

Aha, I think I misread the diff.  The new language only says that you MUST NOT have both, and is not really clear what behavior is if you do.

Allow me to take off my hat as chair here for a moment, to represent a contrary opinion as a site operator on two topics here.  (voices thus far on this topic have been mostly browser implementers)

RE: Presence of both Content-Security-Policy and Content-Security-Policy-Report-Only

>From an developer/operational perspective, it seems like it's a nice feature to be able to have both an enforced and a monitored policy simultaneously, to allow incremental refinement.  You can set for enforcement the policies you know are compatible, and monitor experimental additions that further reduce privileges.

Deployment of CSP for legacy sites will be hard enough without making it an essentially one-shot process, or forcing site to turn off their known-good policies while they experiment with stricter versions.

RE: Policy combinations vs. first-wins

Consider the case where a site owner has a set of CSP policies that it wants to guarantee are enforced for all resources, but also has individual resource owners who want to opt-in to tighter restrictions.   Coordinating this type of thing, e.g. between a corporate infosec group and individual app development teams, is difficult in the real world, especially for large sites.

 We can solve this in one of two places:

  1.  The user agent can combine the policies, incrementally dropping privileges as tokens are encountered.
  2.  The site operator can combine the policies, e.g. by observing policies at a network-edge device and re-writing a unified policy. 

With regard to the specific concern of Adam's regarding policies (e.g. Meta-Referrer) that don't have a clear ordering or union algorithm, I think the above implies that we still need a define a standard algorithm for policy combination, even if we punt that complexity to site operators instead of browser vendors.  

The question then comes down to who should be responsible for implementing the combination algorithm.  Doing it in the browser implies fewer implementations by people who arguably know better what they are doing, and introduces less total complexity into the ecosystem.  Doing it server-application-side introduces an entirely new component, and one that is reasonably complex if it has to look for meta http-equiv, whereas the browser is mostly doing this work already.

-Brad

Received on Saturday, 10 December 2011 01:54:54 UTC