Re: [CSP] URI/IRI normalization and comparison

On Tue, Jan 20, 2015 at 3:32 PM, Mike West <mkwst@google.com> wrote:
> I'll change this to explicitly list `blob`, `data`, and `filesystem`. It
> seems like there should be some concept that encompases these kinds of URLs
> that we don't want to match against '*', but I don't see one lying around.
>
> https://github.com/w3c/webappsec/commit/8cbfd691843b110f97b522e06c2990b532d477dd

URL schemes from which local data can be fetched does seem like a
primitive of sorts. In fact, we need this kind of primitive to define
SVG/CSS properly:

  https://www.w3.org/Bugs/Public/show_bug.cgi?id=26114


> The "protected resource" is the document/worker which the policy applies to.
> We can either accept that as a global, or grab it from the incumbent
> settings object. I prefer the former for the moment, but will prefer
> something else once we rewrite the whole thing in terms of Fetch.

I would prefer that a comparison function grabs no globals I think. Or
at least that it is explicit somehow if it must be done.


> 1. Wildcard handling is a broken concept for IPv4; it simply doesn't make
> sense as written. Maybe moving the '*' to the right side would make sense,
> but honestly I'd rather remove that than somehow extend the concept to IPv6.

The problem with IPv4 is that in practice http://2/ is IPv4 too. The
URL Standard does not cover this yet but most likely will. Once parsed
that would become normalized to http://0.0.0.2/ so maybe
comparison-wise the IPv4 stuff works...


> 2. We accidentally support IPv4 by virtue of supporting numerics in
> hostnames. It's not at all clear to me that we _should_ have extended the
> grammar to support IPv6. I think we instead should encourage folks not to
> tie security checks to IP-address-based hosts. Perhaps we should revert the
> decision in https://github.com/w3c/webappsec/issues/49?

That seems okay to me. The URL Standard will at some point be able to
tell apart domain names from IPv4 from IPv6 so you'll have enough
primitives to do whatever.


>> * Step 4.10 talks about the URL being the result of a redirect but it
>> is unclear how that information can be obtained from a simple
>> comparison operation. It also has the same problems with path as
>> mentioned earlier. It's not a string, but a list.
>
> This will be clearer with a Fetch-based rewrite. It's not clear how we can
> obtain this information at the moment given the way things are structured,
> so this bit is seriously hand-wavey.

Indeed. There should at least be a note of sorts there I think.


-- 
https://annevankesteren.nl/

Received on Wednesday, 21 January 2015 08:46:58 UTC