Alternate fixup confusion for `http://https://` input
Categories
(Firefox :: Address Bar, defect)
Tracking
()
People
(Reporter: srpen6, Unassigned)
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:84.0) Gecko/20100101 Firefox/84.0
Steps to reproduce:
Redirect attack vector survey-smiles.com
If you run this command, you get expected error:
PS C:\> curl.exe -I http://https://example.com
curl: (6) Could not resolve host: https
However if you put the same URL in Firefox, you get redirected here:
http://www.https.com//example.com
which redirects to a spam site:
PS C:\> curl.exe -I https.com
location: http://survey-smiles.com
|
||
Comment 1•4 years ago
|
||
Firefox's address bar specifically, and the browser as a whole, has different goals than cURL. cURL takes completely valid URLs and fetches them, returning an error if it cannot. Firefox takes pretty much arbitrary user string input and tries to do its best to produce what the user wants - searches with the default search engine, or loading a URL.
This isn't a security issue that is exploitable by attackers (if it were, they could just redirect directly to the target site) and so there's no point keeping this hidden.
We should probably consider turning off alternate fixup by default at this point - Marco, is there a bug for this? Any reason not to that I'm forgetting?
|
||
Comment 2•4 years ago
|
||
This is still bug 1679556, this "mishandling" became viral for some reason, so we got more reports in the last months than in the last 10 years. It's non critical imo.
We should turn off alternate fixup, but as I said in https://bugzilla.mozilla.org/show_bug.cgi?id=1679556#c9 it would be interesting to measure the impact of it, how many users would flip it back?
Can we provide an alternative, like having the NOT FOUND page suggest "Did you mean to go to fixed_up_url?"?
Description
•