Hi Nick, On 03/13/2010 06:13 AM, Nick Kralevich wrote: > 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 *:*".
Maybe we should revisit the use of *. The problem you're identifying, Nick, seems to be an overloaded meaning of *. Perhaps it is more clear if it is only allowed to represent one type of data: scheme, host or port. Then "allow *" would mean allow all hosts on inherited scheme. If we do this, we could introduce a new keyword 'all' that represents the current ultimately permissive wildcard (essentially equal to *:*:*). I'm just thinking out loud here... >> 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*. While it makes a policy feel complete, I'm not sure that's necessary. First of all, covering the entire range might be overkill. Something too granular is not convenient or easily digested (video-src audio-src img-src embed-src applet-src link-src style-src ... for each tag). On the other hand, something not granular enough might not be useful. We have to decide what will be used and focus on designing something that will have the greatest effect. If we get lost in corner cases, CSP will never see the light of day, and when it does, it'll be way too complex to use. So I don't think CSP has to be able to express "no policy", since the lack of a CSP is just that. I'd be interested in seeing a sample use case for permitting any protocol; is there a specific example of a web property you have in mind that would require this? > 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). CSP is not supposed to be an almighty end-all to security issues, but rather an extra layer of help that can lock down a site. Those who can't craft a policy in CSP that is perfect for their site might have to use other countermeasures (as a supplement or alternative). Additionally, if CSP's assistance is not desired (fully permissive policy) it can be *omitted* from the HTTP response -- I don't see a need for someone to specify a CSP that says they don't want to use CSP. Thanks again, Nick. -Sid _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
