- From: Daniel Veditz <dveditz@mozilla.com>
- Date: Fri, 21 Jan 2011 14:47:14 -0800
- To: Michal Zalewski <lcamtuf@coredump.cx>
- CC: Devdatta Akhawe <dev.akhawe@gmail.com>, gaz Heyes <gazheyes@gmail.com>, Giorgio Maone <g.maone@informaction.com>, Brandon Sterne <bsterne@mozilla.com>, public-web-security@w3.org, Lucas Adamski <ladamski@mozilla.com>
On 1/21/11 2:13 PM, Michal Zalewski wrote: > How do you imagine turning a policy like CSP or > Adam's proposal into an "additively restrictive" one? The principle > behind both approaches is that you start with default deny, and > whitelist permitted origins. > > The way to do it safely is to only allow the whitelist to be specified > once, and ignore subsequent attempts; I am not sure how this fits your > model? CSP is already "additively restrictive". This might be useful if a site had a relatively lax global policy that was added to every response (including multiple partners used in various sections of the site) and particular pages wanted a tighter policy (say, only the host itself). Maybe it won't be as useful as we think but seemed safer than worrying about which of the multiple headers was the intended one and which was potentially injected. > But I really think that in both cases, it's a false dichotomy. There > is no reason why CSP could not accept both policy formats (HTTP header > and <meta>), and if HTTP headers take precedence over <meta>, there is > no security trade-off and a usability gain. There is also no reason > why CSP could not support reporting to local JS or to a server-side > callback depending on a policy parameter. We certainly could do both. We simplified because multiple options added complexity that seemed to discourage people. Before adding them back it would be useful to get feedback from actual use of the feature in Firefox 4 -- we might find we're worrying about all the wrong things. -Dan Veditz
Received on Friday, 21 January 2011 22:47:54 UTC