W3C home > Mailing lists > Public > public-webappsec@w3.org > June 2014

Re: CSP wildcard host matching

From: Brad Hill <hillbrad@gmail.com>
Date: Mon, 30 Jun 2014 09:34:30 -0700
Message-ID: <CAEeYn8h3Y8VQ==xJesyBB5Y+u1w76EM0w2eoZyPP5fdd93ccqA@mail.gmail.com>
To: Giorgio Maone <g.maone@informaction.com>
Cc: Mike West <mkwst@google.com>, "Hill, Brad" <bhill@paypal.com>, Anne van Kesteren <annevk@annevk.nl>, Sid Stamm <sid@mozilla.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
One other issue: we don't seem to prohibit wildcard matching or set a
barrier on  public-suffixes.  This is a barrier for TLS wildcards, for
cookies, etc.

It's not totally clear to me that this bit of extra complexity adds its
weight in practical security, but something to consider, especially for
cloud hosting use cases.

e.g. if I trust *.example.com, should that also include
3rdParty.cloudhosting.example.com, if cloudhosting.example.com is a


On Mon, Jun 30, 2014 at 3:09 AM, Giorgio Maone <g.maone@informaction.com>

>  FWIW, when I had to face this problem in ABE ( http://noscript.net/abe/
> ) I decided to keep *.xyz.com with its restrictive, universally accepted
> meaning (matching all the subdomains, but not the base domain) and introduce
> .xyz.com
> (leading dot, with no star) as a syntactic sugar for "*.xyz.com xyz.com".
> -- G
> On 30/06/2014 08:07, Mike West wrote:
>  On Sun, Jun 29, 2014 at 11:24 PM, Hill, Brad <bhill@paypal.com> wrote:
>> This is already "a problem" in PKIX certificates today.
>> <snip>
> 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.
>  I don't think it's "important", but it's a case where Firefox and Chrome
> diverge.
>  I continue to think it's counter-intuitive for the wildcard to exclude
> the base host, but I certainly don't think it's worth arguing at length
> about, nor do I think it'll have much practical impact.
>  I'll go change Blink, and we'll leave things as they are.
>  -mike
>  --
> Mike West <mkwst@google.com>
> Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91
>  Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
> Registergericht und -nummer: Hamburg, HRB 86891
> Sitz der Gesellschaft: Hamburg
> Geschäftsführer: Graham Law, Christine Elizabeth Flores
> (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
Received on Monday, 30 June 2014 16:34:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:39 UTC