1587659 - Adding /1 before https://... causes browser to redirect to a Chinese 404 page

Status: UNCONFIRMED

(Core :: DOM: Navigation, task, P3)

Description

[phly95]

Let's say you're on Gmail, and you go to https://mail.google.com/mail/u/0/#inbox, then you want to access your secondary account. so you swap out /0 for /1, but then you accidentally hit home or another trigger that skips to the beginning of the URL. so instead of https://mail.google.com/mail/u/1, you end up with /1https://mail.google.com/mail/u/0/#inbox . Firefox sees this as directions to go to http://www.1https.com//mail.google.com/mail/u/0/#inbox , which could be dangerous behavior, and I do not know if this page or any other https.com pages contain browser exploits (I hope not). This could also be abused with other common url modifiers as well, and may not be limited to this url specifically.

Comment 1

[phly95]

BTW, the redirected url is a porn website.

Comment 2

[phly95]

not specifically the redirect itself (it's a 404 page) but the website in general is a porn website.

Comment 3

[Paul Theriault [:pauljt] (no longer reading bugmail)]

When you enter an incomplete URL, Firefox has to do its best to guess at what you intended. I've seen similar behavior to this in the past. I'm not the authority on this, but I don't think there is anything really that surprising here (other than the domain squatting which is out of our control). URL bar behavior isn't standardized as far as I know, so you will see different behavior in other browsers.

For example, if you enter /abc, I believe Firefox first looks for a DNS name called abc, assuming you meant http://abc. But when that fails, it tries http://abc.com. Above you have effectively entered /1https, which is obviously a common enough typo that someone thought it worthwhile to typosquat on the domain.

So yes there is a risk that someone can register a domain that will end up being navigated too. But no different registering a common typo of a popular domain name. This is publicly documented behavior (at least in source code, but I believe elsewhere) so I dont see any reason to keep this bug private.

Thanks for the report anyways, it might a useful datapoint for improving URI fixup in the future.