w3c / webappsec-csp

WebAppSec Content Security Policy
https://w3c.github.io/webappsec-csp/
Other
209 stars 78 forks source link

Consider dot-prefix domains for wildcard matching #304

Open 007 opened 6 years ago

007 commented 6 years ago

(Please close https://github.com/w3c/webappsec/issues/513 if this is the more appropriate forum for the request)

As it stands, it seems that I need to explicitly add example.com and cdn.example.com as separate entries in CSP headers. Any subsequent subdomains could use *.example.com for matching, but the *. prefix doesn't match a domain with no prefix.

I'm not sure the exact fix, but I'd like to see the preceding . as implicit for bare domains, sort of like the trailing dot is part of the SOA / zone records in DNS. That would let the *.example.com match both the bare domain and any subdomains, without requiring two separate rules to implement.

*example.com would work too, but only if the implicit-dot is part of the parser. If not, evilexample.com would be a terrible security hole.

dveditz commented 6 years ago

Or I suppose copy cookies and accept a leading dot as a "domain" match: ".example.com"

We'd have to investigate what current browsers do when they encounter that. Hopefully they ignore it, but worst case they might throw an error and ignore the entire CSP. That would be an argument in favor of expanding the scope of "*.example.com", although that risks opening up a bypass for sites that explicitly do not want to allow content from the bare domain. Does that happen?

People might already want some kind of a negation syntax ("*.example.com but not partner.example.com or vendor.example.com") and this would make it more important. A leading hyphen seems obvious since a domain isn't supposed to start with one (but I bet they exist nonetheless).