On 3/13/10 6:13 AM, Nick Kralevich wrote: > On Fri, Mar 12, 2010 at 5:24 PM, Brandon Sterne > <bste...@mozilla.com> wrote: >> 2) How does one specify a wildcard for any protocol? >> >> I don't think we should allow that. Do you have a reason to >> believe we should? > > IMHO, any policy language needs to cover the entire range of > policies, from completely *permissive* to completely > *preventative*.
Content-Security-Policy is an attempt to develop a declarative security stance. Blacklisting fails, you will never know all potential sources of evil attacks. You hopefully _do_ know the source of everything you intend to show up on your site (you might not given advertising networks, but then again ads are sometimes a source of evil attacks). If you can declare those sources and the client can block everything else then we think we've made your site less susceptible to attack. In that view wildcards are a botch from the beginning, but like allowing inline-scripts (another self-defeating feature) we think it's necessary as a transition device. When it comes to protocols, though, we intend to be strict. There should be no way ever to whitelist '*' protocols. Who knows what someone will invent in the future and how abusable it might be? If you use it you can list it, otherwise "the web" is http/https only in our book. > It seems like the only way to write a completely permissive > policy is to explicitly list out all possible schemes, which is > awkward (IMHO). CSP isn't designed for a permissive policy. If you add a CSP header you are explicitly opting into a non-permissive regime. Writing a CSP policy is only awkward if you don't know what you're hosting on your pages, and if you don't know you can't really secure it anyway so why bother with CSP? The most awkward thing about CSP will be eliminating inline-scripts, not writing the policy. -Dan Veditz _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
