Re: [CSP] URI/IRI normalization and comparison

On Wed, Jan 21, 2015 at 9:46 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> 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


Commented on the bug, thanks for that reminder. If URL adds such a hook,
I'd happily use it.


> > 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.
>

Point taken. I've changed the algorithm to accept the protected resource as
an argument:
https://github.com/w3c/webappsec/commit/c30ec07d07e763cc5c65e738643caca8b0dbe3d5


> > 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...
>

I think it "works" in the sense of not exploding in a puff of logic. I
don't think it "works" in terms of sanity.


> > 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.


What seems ok? Reverting the addition of IPv6 grammar, or changing our
matching algorithms to match IPv6?


> >> * 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.
>

Added in the same commit as above.

--
Mike West <mkwst@google.com>, @mikewest

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.)