Closed Bug 1378296 Opened 4 years ago Closed 10 months ago
URL Bar Spoof
User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:54.0) Gecko/20100101 Firefox/54.0 Build ID: 20170628075643 Steps to reproduce: Manually entering a URL into the address bar and then choosing to stay on the page when prompted (via onbeforeunload) causes the entered URL to stay in the address bar while the document is still under the attacker's control. Please follow the steps in http://strukt.tk/pocs/ffspoof.html for a live PoC. Actual results: The URL entered in the address bar stays the same. Expected results: The URL should be reverted to the current page's.
Normally a spoof is done by a third party without the user knowing, but in this case, the information has been provided (and is known) by the user themselves. This makes it more of a usability question than an actual spoof.
I have developed a better PoC, utilizing a copy hijacking technique, you can find it here http://strukt.tk/pocs/ffspoof.html
Dan, what are your thoughts on this?
The copy bit didn't work for me, but maybe I turned it off in prefs. Still I see what you're getting at. We have a tension: users type things that fail all the time. If we clear what they type then they can't edit any typos that might then make the URL work. On the other hand if we leave their text it can be used for spoofing if for some reason the navigation doesn't work AND WE DON'T TELL THE USER THAT. Some failures make this obvious because an error page replaces the original content. Some failures, like this case, do not. One "solution" would be to clear the page content, but of course in this case the user has told us very explicitly not to do that by not clicking the "Leave Page" button (even if they don't realize that's what ESC means in this context). In the case where the user explicitly chooses not to leave a page with an beforeunload handler we should know enough at that point to restore the Address Bar to the original URL. We can restore the URL if the user clicks in the Address Bar and hits ESC, we should do the same if a beforeunload is canceled. That said, this isn't a great spoof. Plenty of clues that the user just told us to stay on the same page, and if the destination URL is https: then we won't show a lock icon. As more and more important sites go https-only spoofing without a lock is not very useful.
I see your point here, the bug is not so great in that it is quite obvious. I'd like to know if this is going to be fixed, your response doesn't really clarify about that.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3
Whiteboard: [fe:investigate] → [fe:investigate][fxsearch]
Status: NEW → RESOLVED
Closed: 10 months ago
Resolution: --- → DUPLICATE
Duplicate of bug: CVE-2020-15665
10 months ago
You need to log in before you can comment on or make changes to this bug.