1719442 - When configuring a homepage URL without the colon between "https" and the "//", alternative URI fixup redirects to malicious sites

Status: RESOLVED FIXED

(Firefox :: Address Bar, defect)

Description

[igor.bobar]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36 Edg/91.0.864.64

Steps to reproduce:

Open Firefox, which is configured to have a home page, in this case misconfigured, so it has a colon missing between the https and the double forward slash //.

Firefox then redirects you to a site called "gloos - ves . com" (without the spaces) plus some random string and that site then redirects you to some random website, that is sometimes in my regional language (German in this case) or also some random ads.

This has been reproduced on my local machine, as well as some other colleagues machine which has a Firefox Dev build. I haven't tested it on my 89.0.2 (64-Bit).
The first machine this has been observed on is running Firefox 31.6.0 on Linux (IGEL ThinClient)

Actual results:

When entering a website as Staring Page and the website has the colon missing between "https" and the "//", Firefox opens a site called "gloos - ves . com" which redirects you to some random and (but not exclusively) potentially malicious sites.

IMPORTANT:
This only happens when the link is setup as the starting page when you open firefox.

Expected results:

It should have just opened the website and probably filled in the colon. Or it should throw an error message that doesn't accept that mistake.

Comment 1

[:Gijs (he/him)]

Because an attacker who can convince you to make this typo can probably convince you to put the full URL into the homepage field, there isn't really any point keeping this bug hidden, so I'm removing the security-exploit flag.

Marco, is it worth looking at this separately from bug 1679556? Should we just hardcode the http and https hosts in the alternative fixup code so at least we don't "correct" those? That seems like an easier fix than the 2 options discussed in the last comments in bug 1679556 and will probably address the 99% case at this point...

Comment 2

[Marco Bonardo [:mak]]

Yes, hardcoding the fact we don't fixup http/https doesn't prevent us from doing the suggestions in bug 1679556 in the future (we could still completely disable suffix fixup, as well as improve the not found page). Thus, it would probably be an acceptable initial compromise.

Comment 3

[Marco Bonardo [:mak]]

I must note that we generate alternate only for http, we never fixup https, and considering the current status of the Web moving towards https, this feature makes less and less sense. I wonder if we should enforce the homepage to not be http, for example (but I know this would break a ton of edge cases...).

Comment 4

[:Gijs (he/him)]

Attachment: Bug 1719442 - stop doing alternate fixup for 'http' or 'https' strings as host names, r?mak

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c241b495cbb5
stop doing alternate fixup for 'http' or 'https' strings as host names, r=mak

Comment 6

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/c241b495cbb5