1324784 - Address bar spoof by drag and dropping invalid URL

Status: RESOLVED WORKSFORME

(Firefox :: Address Bar, defect, P3)

Description

[Abdulrahman Alqabandi]

Attachment: spoof2.html

User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36

Steps to reproduce:

Open PoC attached and drag and drop anchor tag to the address bar (use latest stable)


Actual results:

We can set our own 'text/x-moz-text-internal' when dragging an object which could lead to URL spoof.

'text/x-moz-text-internal' is the content type used for the drag object thats created when one drags a tab.

So far from my tests this does not work on latest nightly, im traveling right now so cant take time to mozreggress.


Expected results:

No spoof

Comment 1

[:Gijs (he/him)]

I think the brokenness on Nightly is probably bug 1324410.

Can you elaborate what you think the vulnerability is here? Is it just that you can drag text that looks like a URL to the location bar without triggering a load?

Comment 2

[Abdulrahman Alqabandi]

(In reply to :Gijs Kruitbosch from comment #1)
> I think the brokenness on Nightly is probably bug 1324410.
> 
> Can you elaborate what you think the vulnerability is here? Is it just that
> you can drag text that looks like a URL to the location bar without
> triggering a load?

The main bug would be the ability to set 'text/x-moz-text-internal' I think. If you set a href to the text it wont let you drag it. 

We can also detect when a user would be drag and dropping our text, so we could change the document to resemble the website 'spoofed'

Comment 3

[:Gijs (he/him)]

(In reply to Abdulrahman Alqabandi[test] from comment #2)
> (In reply to :Gijs Kruitbosch from comment #1)
> > I think the brokenness on Nightly is probably bug 1324410.
> > 
> > Can you elaborate what you think the vulnerability is here? Is it just that
> > you can drag text that looks like a URL to the location bar without
> > triggering a load?
> 
> The main bug would be the ability to set 'text/x-moz-text-internal' I think.
> If you set a href to the text it wont let you drag it. 
> 
> We can also detect when a user would be drag and dropping our text, so we
> could change the document to resemble the website 'spoofed'

Still confused. Does the same thing not work if you assign to text/plain or text/unicode or text/uri-list ?

Comment 4

[Abdulrahman Alqabandi]

Seems like you can, hrmm I did not expect that also to work. I was expecting text/plain to have firefox search google. Do you think having the address bar not load like that is normal though?

Comment 5

[:Gijs (he/him)]

(In reply to Abdulrahman Alqabandi[test] from comment #4)
> Seems like you can, hrmm I did not expect that also to work. I was expecting
> text/plain to have firefox search google. Do you think having the address
> bar not load like that is normal though?

It refuses to load because what you dropped isn't a valid URL, or because what you dropped isn't supposed to be linkable from the place you dragged it from. So yeah, I kind of do.

It's hard to see how to break this kind of usecase without breaking dragging all/any kind of text to the URL bar. Searching google doesn't really make sense if you drop "www.mozilla.org" or something like that (which is not a valid URL without the "http://", but will 'work' if you just hit enter/return if you're a user being intentional about that).

Comment 6

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

It's pretty clear from the various reports, that we have a generic problem with the distinction between what is currently being edited, and what is actually loaded.
We can keep workarounding this, but whatever filter we put when allowing drop/paste will have misses.
We need some UI solution here to make the user notice that when it is interacting with the page he is on a different address.
We could surely restore the currently loaded url on blur, but that would likely annoy technical users and we should somehow warn the user that things changed (his focus likely changed to content). We could limit the behavior to pasted/dropped contents maybe.
Or we could have a visible unsafe indicator?

All this to say we need a more generic UI solution to this problem, cause the alternatives are either too permissive (filters won't be perfect) or too restrictive (we may completely disallow pasting/dropping things that look like urls, and this would annoy technical users).

This said, this is not a complete spoof, the security indicators all still all there.

Comment 7

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

An alternative solution, may be to act more similarly to Chrome, if we think it's an url, we just load it, otherwise force a search.
Then we remove that uncertainty that lies in the middle (it's there but not loaded).
It will annoy someone, no doubt.

Comment 8

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

We actually implemented comment 7 in bug 1321619, I think we can solve this?