1295067 - File upload dialogue can be seemed to be opened on arbitrary websites.

Status: RESOLVED DUPLICATE of bug 1678389

(Core :: DOM: Core & HTML, defect, P3)

Description

[Abdulrahman Alqabandi]

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

Steps to reproduce:

<style>
#q{opacity:0.0;}
</style>
<input type="file" id="q"/>
<button id="qbutt">click me</button>
<script>
var pop;
var qint;
qbutt.onclick=function(){
	pop=open('https://www.dropbox.com/');
	qint=setInterval(function(){
		try{console.log(pop.location.href)}catch(e){setTimeout('q.click()',2500);window.clearInterval(qint)}
	},333);
}
</script>


Actual results:

The upload dialogue seems to be opened whilst focused on a random external website, this may fool some users into uploading files they thought would go to their dropbox/google-drive profile.


Expected results:

Perhaps the file upload dialogue should have similar behavior as the alert box. If it's triggered out of focus, then it should not appear.

Comment 1

[Daniel Veditz [:dveditz]]

Attachment: testcase from comment 0

Please attach your testcases rather that put them inline in comments. It's easier to test that way, and for all but the most trivial testcases it makes the bug text much easier to read and follow by keeping the clutter elsewhere.

Comment 2

[Daniel Veditz [:dveditz]]

The testcase only works if you disable the popup blocker or whitelist that site. This is not the default configuration.

We probably can't implement the suggested solution because the File pickers are native dialogs. Pretty sure we can't rewrite them as in-content overlays as we did with the prompt service dialogs. We could make them drag their spawning tab/window to the top but that has problems and can lead to a different kind of spoof (surprise misclicks). Can we suppress/cancel these dialogs if they're spawned from a window that is not the top-most?

While we're at it, maybe don't allow them from iframe'd content that isn't same-origin with the top-most either -- there's no way for the user to know where the file is going to go because there's no destination shown on the dialog itself.

Comment 3

[Abdulrahman Alqabandi]

Attachment: q.html

It's possible to have the file dialogue appear (without allowing popups) if we remove the delay from the onclick event. Doing it this way makes it appear less convincing though.

Comment 4

[Matthew N. [:MattN]]

We pass a dialog title when we init a file picker and that string is currently "File Upload". We could help savvy users by including the origin or domain in the dialog title. I don't know if the title is used on all platforms but I do see it on OS X.

Comment 5

[Matthew N. [:MattN]]

All of the possible solutions discussed are changes in Gecko, not Firefox, so I'm moving this to Core::DOM

Comment 6

[Daniel Veditz [:dveditz]]

Putting the origin in the title might work.

There's a case where it might be misleading: page on www.foo.com has the form with the upload control, so that's what we put in the dialog title. The form itself, however, submits to bar.com, which might lead the user to say we were lying. "www.foo.com" is still the correct choice: that's what the user sees, the foo.com page could change the form action to anywhere after the upload dialog, or even capture it into a blob: without submitting it to any site at all. www.foo.com is in control of that data once the user picks a file on the picker dialog.

adding tanvi and jkt in case they want to chime in.

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

I  was told OSX does _not_ show the title with file picker. Does that depend on the version of OSX?

Comment 8

[Matthew N. [:MattN]]

Hmm… I just tested in a new profile with Nightly (e10s on and off) and I see the title since we open a new window for the picker on OS X 10.10.5. In Safari the new window is opened as a sheet so the title isn't shown but at least on my computer we don't do that.

Comment 9

[Jonathan Kingston [:jkt] he/him]

Suppressing the dialogs would certainly be preferable to the title change in my opinion (assuming that is available to us), this appears to be what Chrome is doing in this case.

Comment 10

[Andrea Marchesini [:baku]]

Attachment: click.patch

Here a check about if the document is visible or not.

Comment 11

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 8793388 [details] [diff] [review]
click.patch

This is most probably not right. IsVisible() is about pageshow/hide state. And don't you want to check the state of the top level page, since hidden iframes in currently focused tab should still work, at least when same origin.

Does this even fix the testcase?

Comment 12

[Andrea Marchesini [:baku]]

Actually, if a new window is opened, both windows are visible. My approach doesn't work at all in this scenario.
I guess a proper fix for this is: we should show dialog pickers only if there is an user interaction.
smaug, do we have something similar already implemented? Does it makes sense?

Comment 13

[Olli Pettay [:smaug][[e-mail]]]

Shouldn't we just block filepicker if the inputElement.ownerDocument.defaultView.top isn't active in the currently focused top level window?

Comment 14

[Daniel Veditz [:dveditz]]

Un-hiding at the reporter's request.

Comment 15

[Sylvestre Ledru [:Sylvestre]]

Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information

Comment 16

[Tom Schuster (MoCo)]

Chrome nowadays requires a TransientUserActivation, we should also implement that. https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/html/forms/file_input_type.cc;drc=a9a94c402b991b35b1f86cf5ef24b47af92dbef5;l=165

Comment 17

[Tom S [:evilpie]]

Oh we already implemented this in bug 1678389. I must have set some wrong pref in my main profile, because the user activation isn't required there.