1378296 - URL Bar Spoof

Status: RESOLVED DUPLICATE of bug 1651636

(Firefox :: Address Bar, defect, P3)

Description

[Mustafa Hasan (strukt)]

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.

Comment 1

[Matt Wobensmith [:mwobensmith][:matt:]]

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.

Comment 2

[Mustafa Hasan (strukt)]

I have developed a better PoC, utilizing a copy hijacking technique, you can find it here http://strukt.tk/pocs/ffspoof.html

Comment 3

[Mustafa Hasan (strukt)]

Any news here ?

Comment 4

[Mustafa Hasan (strukt)]

More than 14 days have passed and there's still no response here, any updates ?

Comment 5

[Panos Astithas (he/him) [:past] (please ni?)]

Dan, what are your thoughts on this?

Comment 6

[Daniel Veditz [:dveditz]]

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.

Comment 7

[Mustafa Hasan (strukt)]

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.