[whatwg/url] IPv4 host parser + site definition seems potentially dangerous. (#560)

Per the IPv4 parser, http://127.0.0.127.1 is a valid, non-IPv4 host.  Similarly, http://foo.0.127.1 is a valid, non-IPv4 host.  Per the Public Suffix List spec, the prevailing rule that should apply to them (since they have no matches in the list) is "*", so their eTLD is just "1", and so their site (defined in the fetch spec) is "http", "127."1".

This is strange for two reasons:
1)  "http://127.1" is, per the IPv4 parsing spec, equivalent to "http://0.0.127.1", which seems unsafe.  I believe it's a reserved IP, anyways, but still not great.  FireFox maps this to "http://127.0.0.1", at least when passed to the Javascript URL constructor, which seems even less safe.
2)  "http://127.0.0.0.1" looks a lot like "http://127.0.0.1", and we always tell users to look at the end of a hostname, so doesn't in general seem very safe to display to the user.

Now, admittedly, trying to resolve "127.0.0.0.1" at the DNS layer should generally fail, but the situation here seems a bit troubling.

I ran into this because Chromium is trying to store the Network Partition Key's site | origin as an origin object, but a fuzzer recently discovered an assert failure when creating an origin with a host of "0.1" (which is recognized as not being in the canonical form of "0.0.0.1").  Obviously, we could just make it hold an origin | (scheme + hostname), and we can adhere to the spec, the described behavior just doesn't seem that safe to me.

I'd rather just reject an host that ends in a number but isn't a valid IPv4 IP, so filing this to see if anyone else has any thoughts on this.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/url/issues/560