1063010 - URLs with a potentially misleading IP address should be normalized

Status: RESOLVED FIXED

(Firefox :: Address Bar, defect, P3)

Description

[Daniel Jackson]

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0
Build ID: 20140825202822

Steps to reproduce:

Enter any of an infinite number of URLs to specify an IP address -- for example, for "localhost", all of the following will access 127.0.0.1 (as will an infinite number of other addresses):

http://127.0.0.1
http://127.0.1
http://127.1
http://2130706433
http://0177.00.00.01
http://0177.00.01
http://0177.01
http://00000000000000000000000000177.0000000.0000000.0001
http://000000177.0000001
http://017700000001
http://0x7f.0x00.0x00.0x01
http://0x7f.0x01
http://0x7f000001
http://0x007f.0x0000.0x0000.0x0001
http://000177.0.00000.0x0001
http://0xdeadbeefcafeBADF00D7f000001 (Firefox ignores all but the last 32-bits)



Actual results:

Firefox keeps the exact URL as typed (lower-cased) while accessing 127.0.0.1 for all of the above addresses.



Expected results:

Other browsers (Chrome, IE), normalize the URL to 8.8.8.8 dotted notation when loading the page (and correctly do not recognize the last one).

Although Firefox does have the benefit of preserving the URL the user types, there are potential consequences:

* The user could be misled as the address could be a homograph for a domain name (with the misleading part highlighted in the address bar as the host).  For example, http://OXDEADBEEF.com (DNS resolves to 50.63.202.36) vs http://0XDEADBEEF/com (the specific IP address 222.173.190.239).  To make matters worse is the Firefox bug which truncates an arbitrary-long address to the last 32 bits (e.g. http://0xdeadbeefcafeBADF00D7f000001/ is also treated as 127.0.0.1).  This potential problem may become critical with the ever-increasing number of TLDs (one may be issued that could easily be confused with decimal/octal/hex numbers)

* The fact that leading zeros (and the bug ignoring anything over 32-bits) and arbitrary mixes of notation create an infinite number of addresses means that any site blacklisting or quotas imposed by the browser or an extension can easily be avoided.

* HTTPS certificates with an IP address alternative name entry will not work with all addresses (and typically only ever issued with 8.8.8.8 addresses as alternatives).

This may also affect IPV6 formatted addresses.

Comment 1

[:Gijs (he/him)]

What request headers does the server actually see in Chrome/IE when they normalize in this manner?

Comment 2

[Daniel Jackson]

Chrome and IE both seem to normalize numeric IPs before transmitting any headers -- Host/Referer/Origin all show normalized 4-part 8.8.8.8 addresses for IPv4.  I didn't check through a proxy (assume the same) or IPv6.

Comment 3

[:Gijs (he/him)]

(In reply to Daniel Jackson from comment #2)
> Chrome and IE both seem to normalize numeric IPs before transmitting any
> headers -- Host/Referer/Origin all show normalized 4-part 8.8.8.8 addresses
> for IPv4.  I didn't check through a proxy (assume the same) or IPv6.

Interesting. A casual check with e.g. http://jsbin.com/jewun/1/edit does suggest that the logic is not specific to the URL bar, though (at least in Chrome on OS X).

bz / annevk, thoughts? Is anything specced about this behaviour and/or URLs?

(I suspect this means we need to move this logic into nsDefaultURIFixup, which makes me very sad)

Comment 4

[Anne (:annevk)]

Per RFC 3986 (which I agree with) only the first of those is an actual IP address. The others should not resolve, unless perhaps there's an entry in the DNS for them.

However, it seems the library for DNS checkups parses all of them and there is no way to turn that behavior off. That seems very bad and explains why there is some of this divergent behavior. If there's a way where we can only recognize four sets of digits as IPv4 I would be in favor of that.

Comment 5

[Boris Zbarsky [:bzbarsky]]

I'm pretty sure this is a duplicate, fwiw.

Comment 6

[:Gijs (he/him)]

(In reply to Boris Zbarsky [:bz] from comment #5)
> I'm pretty sure this is a duplicate, fwiw.

I swear I searched before, but look at that:

Comment 7

[Jesse Ruderman]

Bug 67730 (blocking) is controversial, long-term, and may require coordination with other browser vendors. But it's not obviously wontfix, so we shouldn't morph it (into normalizing).

Comment 8

[Junior [inactive]]

I'm thinking about IPv6.
I don't find similar test cases in web-platform test.

Is there any canonicalization issue for IPv6?

Comment 9

[Anne (:annevk)]

Junior, I think we canonicalize IPv6 correctly already. Any particular case you're thinking of?

Comment 10

[Junior [inactive]]

(In reply to Anne (:annevk) from comment #9)
> Junior, I think we canonicalize IPv6 correctly already. Any particular case
> you're thinking of?

No, I'd like to make sure if there's nothing I'm missing.
Therefore what left to this issue is bug 1289711.

Comment 11

[Anne (:annevk)]

I think so, web-platform-tests should have some IPv6 tests too though. If it doesn't you might want to add a couple, but I'm pretty sure the only problem we have/had is with IPv4 (well, and other kinds of URLs, but that's beyond the scope of this bug).

Comment 12

[:Gijs (he/him)]

Valentin, I think we fixed this in bug 1288049, is that right?

Comment 13

[:Gijs (he/him)]

(In reply to :Gijs from comment #12)
> Valentin, I think we fixed this in bug 1288049, is that right?

Egh, just read the comments and realized bug 1289711 is still open.

Comment 14

[Valentin Gosu [:valentin]]

Yes, bug 1288049 fixed all the use cases in comment 0 except the last one, for which we have bug 1289711.

Comment 15

[Drew Willcoxon :adw]

(In reply to Valentin Gosu [:valentin] (he/him) from comment #14)

Yes, bug 1288049 fixed all the use cases in comment 0 except the last one,
for which we have bug 1289711.

Closing this then, please correct if I'm wrong.