Closed Bug 411236 Opened 13 years ago Closed 13 years ago
File upload input focus stealing: by dynamically positioning file input element, any user mouse click will set focus in file input
2.88 KB, text/html
169.42 KB, application/java-archive
4.00 KB, text/html
169.55 KB, application/java-archive
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:188.8.131.52) Gecko/20071127 Firefox/184.108.40.206 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:220.127.116.11) Gecko/20071127 Firefox/18.104.22.168 By tracking mousemove events, a file input element can be dynamically positioned so that it always is beneath the pointer. Any user mouse click will set the focus in the file input text entry field. Once the focus is set on the file element, any entered keystrokes can be selectively captured and potentially used to upload arbitrary files from the user. Reproducible: Always Steps to Reproduce: 1. 2. 3. Tested with user agents: - Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:22.214.171.124) Gecko/20071127 Firefox/126.96.36.199 - Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:188.8.131.52) Gecko/20071127 Firefox/184.108.40.206 - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:220.127.116.11) Gecko/20071127 Firefox/18.104.22.168 - Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:22.214.171.124pre) Gecko/20080107 BonEcho/126.96.36.199pre
Assignee: nobody → dveditz
Product: Firefox → Core
QA Contact: firefox → toolkit
Attachment #295896 - Attachment mime type: application/zip → application/java-archive
Assignee: dveditz → jonas
Status: UNCONFIRMED → NEW
Ever confirmed: true
This doesn't work in Firefox 3 as key input is disabled for file controls.
Version: unspecified → 1.8 Branch
I don't see any way we can fix this without applying the same fix to the 1.8 branch as we have in 1.9. I.e. completely disable the ability to type a filename. Is this attack prevented in any other browser? If so, how? I think safari for a long time has disabled the ability to type filenames.
The testcase doesn't seem to work properly with Opera, but at least some keystrokes are 'stolen' and one can use opacity (not -moz-opacity) to hide <input type="file">. Does IE have similar problem too? I guess opacity doesn't work there, but some kind of filter. Would it be possible to force -moz-opacity:1 (and perhaps some other css values) when input[type="file"]:focus?
I don't think we can stop anyone from hiding a file-input, there are just too many ways to do it. Two off the top of my head: Cover up parts using positioned opaque divs Clip away parts by placing inside a smaller div with overflow:hidden I'm sure there are many more.
Yes, I was thinking those too, but still wondering if there was some way to force z-indexing/clipping etc. (Is this a dup of some other bug where all this has been discussed before.)
This example shows another possible approach of dynamically positioning the file input element. The file input element is hidden until the mouse is over a link and is made extremely small so that it cannot be seen under the cursor. Any mouse click will set the focus in the file input element. The file picker button is obscured by a properly placed div.
(In reply to comment #7) > > (Is this a dup of some other bug where all this has been discussed before.) > I don't believe this is a dupe. Bug 57770 and bug 258875 discuss related issues of styling file inputs to trick users into believing they are typing into a normal text box. The premise being that the user thinks that they are typing the file path into a text box but it is really an upload control. Although plausible, this is probably unlikely among a general audience. This bug shows that it is possible for any user mouse click to set the focus by dynamically positioning the file input element. The use opacity, sizing, overlays, clipping, etc. simply hides the fact the user is clicking in the file element. The overall goal is to steal the focus. Because once the focus has been stolen, any future text that the user enters can be selectively captured in the file input element. If appropriate text can be captured, it can be used to steal arbitrary files. Bug 56236, bug 290478, bug 304480, and bug 370092 (among many others) have discussions or demonstrations of this.
The fix in bug 413135 addresses this issue as well.
Updated the example attack to use the disabled property to selectively cancel keystrokes. This bypasses the fix for bug 413135 in attachment 298006 [details] [diff] [review].
attachment 299567 [details] [diff] [review] in bug 413135 catches this one too. Branch only, so "fixed" unless I'm missing something.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.