Re: CSP wildcard host matching

This is already "a problem" in PKIX certificates today.

The proposed change would also be different from the matching
rules for TLS in FRF2595:

http://www.ietf.org/rfc/rfc2595.txt

   - A "*" wildcard character MAY be used as the left-most name
     component in the certificate.  For example, *.example.com would
     match a.example.com, foo.example.com, etc. but would not match
     example.com.

People live with this rule, and it matches the implicit multi-level structure of the SOP elsewhere.

I question how important making this change actually is to developing policies.  In the certificate case, I think the where this issue almost always comes up is when a site hosts itself on both "www.example.com" and "example.com", in which case for CSP the 'self' token handles it adequately and should be preferred.  I think it's probably a much rarer case that a third-party site needs to include resources across that boundary in a wildcard manner.

-Brad


On Jun 29, 2014, at 2:53 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Sun, Jun 29, 2014 at 11:42 AM, Mike West <mkwst@google.com> wrote:
>> As are `xxx.example.com` and `yyy.example.com`. I'm hard-pressed to think of
>> a scenario in which resources from those two origins would be acceptable,
>> but resources from `example.com` wouldn't.
> 
> Maybe once we have a way to restrict cookies to be same-origin and you
> wouldn't want same-origin credentialed fetches for resources that
> ought to come from cdn{1-10}.example.com. Of course, having a way to
> manipulate request's credentials mode just like you can manipulate
> referrer soon might also address that.
> 
> It also seems counter-intuitive that the * crosses the dot.
> 
> 
> -- 
> http://annevankesteren.nl/
>

Received on Sunday, 29 June 2014 21:24:35 UTC