On Fri, Mar 12, 2010 at 5:24 PM, Brandon Sterne <[email protected]> wrote:
> On 03/12/2010 04:38 PM, Nick Kralevich wrote: > > While reading through the Formal Policy Syntax of the CSP, it occurred to > me > > that the meaning of "allow *" might be confusing. The wildcard seems to > > correspond to a hostname only, and not to a scheme or port. > > Another great question. I've made a change to the policy syntax that I > hope will clarify things. > > <source> ::= "'self'" > | "*" > | <scheme><host><port> > > What this means is that * by itself implies <inherited-scheme>//*:* but > * can still be used as a wildcard for hostname, port, or both. I'm not sure if this clarifies things.... 1) There are now two ways to specify an "inherited-scheme / any port" policy, "*" and "*:*". Having two ways to express the same concept may lead to more confusion, not less. 2) This is inconsistent with other host wildcard handling. For example, "*. google.com" means "inherited-scheme / google host / *default* port" whereas "*" means "inherited scheme / any host / *any* port". Instead of making a change to the formal specification, it may make sense to change all occurrences of "allow *" in the document to "allow *:*". > 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*. The CSP has completely preventative down. It can be written as: X-Content-Security-Policy: allow 'none'; However, how does one write a completely permissive policy? The obvious choice of: X-Content-Security-Policy: allow *:*; isn't correct, as it fails to take into account "options". But even expanding it to: X-Content-Security-Policy: allow *:*; options eval-script inline-script isn't sufficient, as it still blocks non-inherited schemes. It seems like the only way to write a completely permissive policy is to explicitly list out all possible schemes, which is awkward (IMHO). -- Nick _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
