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

>   c. script-nonce: a nonce which, if present in a <script> tag will
>      permit inline script to run
>

Have we discussed the danger of false sense of security this could
impart. In particular, I am concerned about people just marking all
scripts going out of their server with the correct nonce.

And if we are using nonces, why not just use nonces to demarcate the
start and end of untrusted content; the browser can enforce 'no script
in untrusted area'. So youtube, instead of having to worry about
nonces for every script will just need to demarcate untrusted content
with nonces.[1]

There are certain losses to the second approach (the developer has to
identify untrusted content, whereas in the original he has to identify
trusted content). But it seems in both cases, chances of mistakes of
'lets sign everything' will be equally common.

-devdatta


[1] http://www.cs.berkeley.edu/~prateeks/papers/dsi-ndss09.pdf
> 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
>
> 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
>
> 4. Clickjacking protection
>   a. frame-ancestors: list of domains permitted to embed the resource
>      in an iframe
>
> 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
>
> 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
>
> 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.
>
> Best regards,
> Brandon
>
>
> [1] I am using the name "Content Security Policy" as it's referred to
>    in the deliverables section of the proposed Web App Security WG
>    Charter [2], defined as "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."
>
> [2] http://www.w3.org/2010/07/appsecwg-charter
>
>

Received on Thursday, 27 January 2011 22:16:34 UTC