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

On 27/01/11 16:54, Brandon Sterne wrote:
>     c. script-nonce: a nonce which, if present in a<script>  tag will
>        permit inline script to run

Obviously, I support this idea :-) Although I'm not convinced it needs 
to be in version 1.0.

We will need to specify exactly what "present" means. See:
http://www.gerv.net/security/script-keys/
for a few ideas. In particular, you may want to find a way to have the 
key in the tag itself for external scripts, rather than the script. This 
way, people can e.g. include shared copies of web frameworks from 
Google, and also not have to dynamically generate their script files.

Also, I'm not sure "nonce" is the right word.
http://en.wikipedia.org/wiki/Cryptographic_nonce
suggests that it's "number used once". As the above document discusses, 
I can see various sites making various trade-offs about how often they 
change the key, based on caching concerns.

So I would suggest "script-key" as a better name.

> 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

(Nit: we should make sure the event name and semantics fit best 
practice. For example, it seems event names are lowercase. 
http://www.whatwg.org/specs/web-apps/current-work/#mediaevents)

> 5. Options (mechanisms to change default CSP behaviors)
>     a. inline-script: permit inline script to execute

I like the idea of calling this something like "disable-xss-protection", 
if that's actually true. If knobs on your security policy allow you to 
shoot yourself in the foot, they should be clearly labelled.

> 6. Policy delivery
>     a. HTTP header
>     b.<meta>  (or<link>) tag, to be superseded by header if present

Are we going for an arbitrary-number-always-tightening model, or a 
first-policy-wins model?

Gerv

Received on Thursday, 27 January 2011 17:12:00 UTC