Redirect http://https:// to malicious website
Categories
(Fenix :: General, defect)
Tracking
(firefox86 wontfix, firefox87 fixed, firefox88 fixed)
People
(Reporter: ginobiervliet, Unassigned)
References
Details
(Keywords: reporter-external, sec-low, Whiteboard: [reporter-external] [client-bounty-form] [verif?][adv-main87-])
This is not a obvious bug. Maybe just a simple if statement that needs to be fixed?
When navigating to a url using the http prefix following an extra https prefix (e.g. http://https://mozzila.org) you will be redirected to https://https.com. https.com will redirect you to a malicious site. In the Netherlands I get an advertisement with false bitcoin statements. This is a phishing site. Sometimes it will redirect to http://iyfnzgb.com which is blocked by the ISP for being malicious.
Steps to reproduce:
- try to navigate to http://https://mozilla.org
I found this error while browsing a personal medical page (mijngezondheid.net). They have a link that looks normal but (probably because of an error in their CMS) it anchored to http://https://www.serviceapotheek.nl/lindeholt.
I have tried to reproduce it in other internet browsers but I could only reproduce it in FireFox.
I can reproduce this on multiple devices
- 2x macbook pro 2018 with big sur (FireFox version: 84.0.1 (64 bit version)
- Huawei p30 pro with Android 10 (84.1.4)
- and multiple windows devices (unknown specs)
Comment 1•4 years ago
|
||
This is odd. When I try Firefox, Chrome, and Safari on my Mac I get essentially the same behavior: the "//https:/" in the middle is parsed as a domain with an emptystring port, which is odd but appears to be allowed by the spec (==default port). I then get the equivalent of "server not found" for the domain "https" on all three browsers.
Since there is no terminating dot (e.g. https.
) in theory my local resolver could apply a default assumed domain, like ".com". I have seen ISPs try to be "helpful" and correct an domain lookup that fails ("no TLD? probably meant .com"). But then I would expect you to see that consistently with other browsers on the same network/ISP as well.
I have seen cases when entering URLs directly into the addressbar where something like this happens. Due to a typo that makes the string an invalid URL it gets interpreted as a "search", and back in the day Google would sometimes take people to the "best" match directly rather than show search results if it was certain enough. Or maybe it was a setting to do that, can't remember. Anyway, typo-ing "http;//something.com" (note semi-colon" could send you to https.com, which back then also tended to redirect to "interesting" places. That can't be this case, though, because that didn't apply to links, and Google isn't doing the "I feel lucky" behavior any more (they want the search ad money?).
If it were just the one device I'd ask about your web extensions -- it could be you have a search hijacker in there. But that wouldn't explain the same behavior on your Android device. Still worth checking, though.
Steps to reproduce:
- try to navigate to http://https://mozilla.org
I get the expected "We can’t connect to the server at https." error page. Not sure what the next steps should be from here since I don't see a problem in Firefox. Can you open the Network tab in Dev Tools before following the link and see what domains it's attempting? For me I see a request for "https" that just stops. Maybe you've got a more local https that is sending you a redirect? Then try the same thing in Chrome with their dev tools and see what's different about it.
(note: I can definitely confirm that https.com
is an redirector. All the attempts I've tried end up blocked by uBlock Origin (adblocker) so I don't know if the site is just a cash grab redirecting to low quality ads (some of which are malicious) or if it's actively malicious itself. I don't know why https.com itself isn't blocked.)
Comment 2•4 years ago
|
||
Pretty sure this is a duplicate of bug 1643789. The "correction" only happens for middle clicked links for some reason.
Comment 3•4 years ago
|
||
Oh, though perhaps it's worth keeping this open for android? I don't know what they do here, and the other bug is desktop-only.
Comment 4•4 years ago
|
||
We use a regex currently :-/. Probably depends on bug 1685152 being fixed so that Fenix can normalize URIs consistently with Gecko expectations.
Similar to bug 1670725
Reporter | ||
Comment 5•4 years ago
|
||
I've tried looking at the network data in FireFox and Chrome. it looks like FireFox changes http://https://testing.nl to http://https.com//testing.nl Chrome doesn't.
Chrome removes the second ":" while Firefox replaces it with ".com". Strange huh?
Comment 6•4 years ago
|
||
(In reply to ginobiervliet from comment #5)
I've tried looking at the network data in FireFox and Chrome. it looks like FireFox changes http://https://testing.nl to http://https.com//testing.nl Chrome doesn't.
Chrome removes the second ":" while Firefox replaces it with ".com". Strange huh?
So the first step is that everyone removes the colon - as indicated in comment #1 this is standard URL parsing behaviour (you can try going to https://mozilla.org:/
- it will just load the actual mozilla.org website without any issue). So both Chrome and Firefox end up with http://https//testing.nl
. Chrome stops there because there is no https
server (unless one exists on your network, or your ISP redirects, as indicated in comment #1.
At least on desktop Firefox, when the DNS lookup for https
indicates there is no such server, the switch from https
to https.com
is a function of "alternate" fixup (controlled in about:config via browser.fixup.alternate.enabled
). It's a very old behaviour that was used so you could just type "google" and hit enter and go to google.com (before searching with a search engine directly from the address bar was a thing, or when users disabled that for privacy reasons). This behaviour shouldn't be applied for link clicks (and at least on desktop, I only see it happening for middle clicks, not for "normal" left-clicking a link).
Comment 7•4 years ago
|
||
The patch I'm about to put up in bug 1643789 fixes the desktop issue, but I suspect it may fix the android one, too - I'm just not in a position to check.
Comment 8•4 years ago
|
||
(In reply to :Gijs (he/him) from comment #7)
The patch I'm about to put up in bug 1643789 fixes the desktop issue, but I suspect it may fix the android one, too - I'm just not in a position to check.
:kbrosnan, when fenix picks up the m-c changes from bug 1643789 (landed just over 2 days ago), can you check if this is fixed on fenix nightly?
Comment 9•4 years ago
|
||
It now fast fails to the network error page using an up to date Nightly. In 85 I see the network timeout page for http://https//testing.nl and http://https//mozilla.org
Reporter | ||
Comment 10•4 years ago
|
||
It looks like it is fixed now. Tested it on macbook and Android device.
Both are in a loading state when trying to navigate to http://https://test.com and timeout eventually.
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•2 years ago
|
Updated•5 months ago
|
Description
•