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

On Thu, Jan 27, 2011 at 8:54 AM, Brandon Sterne <bsterne@mozilla.com> wrote:
> We can debate the names and syntax later, but we need to settle on the
> functionality that will be included in version 1 of Content Security Policy.

Is there some reason we need to synchronize on a "version 1" feature
set?  I'd prefer an extensible model more like HTML where we can each
implement different parts of CSP on different schedules.  For example,
something more in the spirit of
<http://blog.whatwg.org/html-is-the-new-html5>.

> 1. Script controls
>   a. disable inline scripts by default
>   b. script-src: list of domains where script can be loaded from
>   c. script-nonce: a nonce which, if present in a <script> tag will
>      permit inline script to run

I think that everyone agrees that script controls are definitely worth doing.

> 2. Content restrictions
>   a. allow: catch-all for content-types not specified in policy
>   b. img-src: domains permitted to load images
>   c. media-src: domains permitted to load <video>, <audio>
>   d. object-src: domains permitted to load plugin content
>   e. frame-src: domains permitted to be loaded in <iframe>s
>   f. font-src: domains permitted to load fonts
>   g. xhr-src: domains permitted to send XHR to
>   h. style-src: domains permitted to load stylesheets

I'm not that excited about these features.  Maybe I don't understand
the use cases sufficiently, but the benefits from these features seem
outweighed by their complexity.  For example, what is the use case for
being able to restrict font-src?

Here is a use case that seem related to the above that might be worth
thinking about:

1) My site is entirely served over HTTPS, but my developers keep
including mixed content by mistake.  I wish I could set a policy for
my site that prevented me accidentally loading insecure content.

Maybe there are other good use cases for this feature that I don't understand?

(Note that there is some coupling between script-src and object-src
w.r.t. controlling the source of script on a page.)

> 3. Violation Reporting
>   a. report-uri: URI to which a report will be sent upon policy
>      violation
>   b. SecurityViolation event: DOM event fired upon policy violations

I see violation reporting as valuable because it lets developers
understand whether their site actually matches their policy.  I also
think having a "report only" mode is valuable so developers can
experiment with CSP without breaking anything.

> 4. Clickjacking protection
>   a. frame-ancestors: list of domains permitted to embed the resource
>      in an iframe

IMHO, clickjacking is a quagmire.  I'd love to see a solution, but I'm
not really convinced that this is it.  I'd like to avoid being drawn
into yet another discussion on this topic, if at all possible.

> 5. Options (mechanisms to change default CSP behaviors)
>   a. inline-script: permit inline script to execute
>   b. eval-script: permit eval() and related functions to be used

If we manage to disentangle (1) from the rest of these features, then
we probably don't need (a).  Enabling inline-script defeats the script
controls, so the way folks should "enable" inline script is by not
using the script controls.

w.r.t. (b), I think the ability to block eval and friends is useful,
but not essential.

> 6. Policy delivery
>   a. HTTP header
>   b. <meta> (or <link>) tag, to be superseded by header if present
>   c. policy-uri: a URI from which the policy will be fetched; can be
>      specified in either header or tag

Obviously we need a policy delivery mechanism.  I suspect there are
strong use cases for both (a) and (b).  The previous CSP proposal has
a complex mechanism for merging policies.  IMHO, we should go with the
much simpler "first one wins" strategy.  Headers trump <meta> tags.
Textually earlier headers trump textually later headers.

> I think the most productive way forward for this group will be to debate
> the individual merits of the above sections.  If members feel that a
> section should be modified or removed, please make a comment to that
> effect, including supporting rationale for doing so.  The same would
> apply to group members who want to propose an addition to the above.
>
> Does this sound like a reasonable approach to take?  I look forward to
> our continued discussion.

Yeah, I think this a good way to structure the discussion.  The one
refinement I'd make (as I mentioned above) is that we don't need to
synchronize our implementation schedules.  If you're super excited
about (2), that's great, but I'd like to be able to implement, e.g.,
(1), (3), and (6) now and decide whether to implement (2) later.

Adam

Received on Thursday, 27 January 2011 20:40:16 UTC