For URLs including a "link" parameter, Firefox navigates to the value of "link" instead of opening the domain
Categories
(Firefox for Android :: General, defect)
Tracking
()
People
(Reporter: rbucata, Assigned: royang)
References
(Regression, )
Details
(Keywords: regression, sec-moderate, Whiteboard: [adv-main140+][webcompat-source:web-bugs])
Attachments
(4 files)
Environment:
Operating system: Android 13
Firefox version: Firefox Mobile 139.0
Steps to reproduce:
- Navigate to: https://tweakers.net/pricewatch/2181424/samsung-galaxy-a56-5g-256gb-opslag-grijs.html
- Dismiss the cookie policy
- Tap on any price link or website link and observe
Expected Behavior:
A new page is opened
Actual Behavior:
Nothing happens
Notes:
- Reproduces regardless of the status of ETP
- Reproduces in firefox-nightly, and firefox-release
- Does not reproduce in chrome
Created from https://github.com/webcompat/web-bugs/issues/159810
| Reporter | ||
Updated•6 months ago
|
| Reporter | ||
Comment 1•6 months ago
|
||
Comment 2•6 months ago
|
||
Since nightly and release are affected, beta will likely be affected too.
For more information, please visit BugBot documentation.
Updated•6 months ago
|
Apperently any link with the get parameter 'link' in it doesn't work anymore. So "https://tweakers.net/?link=test" is broken, but "https://tweakers.net/?plink=test" works
Note that we at Tweakers have adjusted the GET parameter in these links to tlink= in order to make the links work again in Firefox on Android.
As far as I can tell both version 139 of Firefox for Android and the 140.0 beta version are affected. Users report that Firefox on iOS is not affected. Also desktop version of Firefox does not seem to have this issue.
Comment 5•6 months ago
|
||
If comment 3 is true, that would be concerning. ni? myself to try to build a testcase here.
Here is a simple testcase: https://tweakers.net/~kees/link-test.html
The first three links don't work in Firefox 139 on Android
Comment 7•6 months ago
|
||
This doesn't just prevent Firefox Android users from accessing links with a 'link' URI parameters, it instead opens to the link parameter, which potentially could be a malicious website.
It works for external links (Eg, a user clicks a link in an email from their mail client like K-9, and that opens in Firefox), as well as embedded links from inside of webpages.
All these links link to my website (https://gingernut.helevtica.systems) on Firefox Android (139.0.4), even though the URL domain is http://test.local.
'link' URI parameter
http://test.local/?link=https://gingernut.helvetica.systems
A preceding parameter and 'link' parameter
http://test.local/?test=true&link=https://gingernut.helvetica.systems
'link' parameter and a following parameter
http://test.local/?link=https://gingernut.helvetica.systems&foo=bar
Unsafe characters in 'link' parameter are URI encoded
http://test.local/?link=http%3A%2F%2Fgingernut%2ehelvetica%2esystems
All characters in 'link' parameter are URI encoded
All characters in 'link' parameter are URI encoded, with a preceding and following parameter
An example of a phishing scam, which URL is from the Australian Tax Office domain, but Firefox Android actually opens a Rick Ashley video on YouTube
Comment 8•6 months ago
|
||
This doesn't look like a webcompat problem.
Updated•6 months ago
|
Comment 9•6 months ago
|
||
Likely a regression from bug 1942509, given that the patch there added a test with the URL "https://example.com/?link=https://example.com"
| Assignee | ||
Comment 10•6 months ago
|
||
Yes, that is the correct cause of the regression. This was trying to recover the Google map case but not suppose to load the link parameter unless the original url couldn't be loaded. I'll revert and request uplift. Thanks
| Assignee | ||
Updated•6 months ago
|
| Assignee | ||
Comment 11•6 months ago
|
||
I will remove both afl and link parameter fallback support until I figure out a better way to support them.
| Assignee | ||
Comment 12•6 months ago
|
||
Unfortunately, lots of conflicts since the change landed for a while now. I'll manually revert.
| Assignee | ||
Comment 13•6 months ago
|
||
| Assignee | ||
Comment 14•6 months ago
|
||
Created a safe change that we can uplift with minimal risk.
Updated•6 months ago
|
| Assignee | ||
Comment 15•6 months ago
|
||
Original Revision: https://phabricator.services.mozilla.com/D253746
Updated•6 months ago
|
Comment 16•6 months ago
|
||
Comment 17•6 months ago
|
||
firefox-beta Uplift Approval Request
- User impact if declined: Incorrect URL can be loaded.
- Code covered by automated testing: yes
- Fix verified in Nightly: no
- Needs manual QE test: no
- Steps to reproduce for manual QE testing: Load example URLs in the Bugzilla issue and make sure that the correct URL is loaded.
- Risk associated with taking this patch: Low risk
- Explanation of risk level: fallback URL will not be used if the user decides not to redirect to external app.
- String changes made/needed: None
- Is Android affected?: yes
Updated•6 months ago
|
Updated•6 months ago
|
Comment 18•6 months ago
|
||
| uplift | ||
Updated•6 months ago
|
Comment 19•6 months ago
|
||
I was able to reproduce this issue on 139.0.4 Firefox for Android, and on Firefox for Android Beta 140.0b9 with Samsung Galaxy S24 (Android 15).
Not reproducible on 141.0a1 Nightly from 6/15.
Updated•6 months ago
|
Comment 20•6 months ago
|
||
| bugherder | ||
Comment 21•6 months ago
|
||
Verified on the latest Firefox for Android 140.0 build 1, and on Beta 140.0b10 with the following devices:
- Samsung Galaxy S24 (Android 15),
- Lenovo tablet (Android 10),
- Realme GT Master Edition (Android 13), and
- Google Pixel 6 (Android 16).
Updated•6 months ago
|
Comment 22•5 months ago
|
||
Updated•5 months ago
|
Description
•