This bug is 'invalid' because it demonstrates several different security holes and selection bugs. I'm wasting my karma by posting it because I want to avoid the possibility of causing bug 56236 to be marked as NS-confidential when imo it shouldn't be. Not that I want this bug to become NS-confidential either, of course :)

just a question: Wouldn't it be possible to trick user into sending a predefined file *regardless* of what you think you submit? Couldn't *any* post entry hide a lot? But perhaps there is already features controlling this couldn't happen?

Isn't the problem here that when one selects, content with display:none is also selected? This seems like a very odd behavior to me.. if I can't see it, I should not be able to select it....

IMO there are so many ways for a page to obscure the selection that an attempt to eliminate them would only obscure the security problem and introduce new bugs. File a bug on display:none if you'd like, though.

rkaa: Mozilla has all kinds of strange limits on what JavaScript and CSS can do to file controls. For example, JavaScript can't change the filename or focus the textbox (bug 6133?), and CSS can't set the color of the text inside the textbox afaik. If a text control /becomes/ a file control through JavaScript or through a page reload, the text is erased (iirc it is possible to switch among text, password, and hidden without data loss). One of the points I'm trying to make with the demo attachment is that this just isn't the right approach to the problem. It doesn't make sense to me that every time I type text into a textbox on an untrusted webpage, I have to make sure that no left-substring of what I type is a path to a file on my computer.

So how do we solve this? Get rid of the text input part of the file altogether or at least make it read-only? (That would be my answer.)

Er, I'd much rather see it unstylable. I use it (i.e., type in it) all the time. When you make a GUI that's as easy as typing, ask me again. Styling of form controls is an extension to CSS anyway.

David: Styling it is not the issue here. Check the demo, it does not style the file input. If you want to type a path in, the dialog that the "Browse" button shows should give you a text input (it does, right?). That way you would have to know that you were typing a path in. At the moment you can't always know that, as shown by the demo.

Then why don't you give the file input's text box an icon to show whether the file exists or not, that would make it clear it's a file input?

ccing some people, the style stuff is a little beyond me. Jesse, we never mark bugs NS-Confidential which were filed by non-Netscape people, or even have comments by non-Netscape people in them. If I have done this, I apologize, it was in error. The NS_Confidential flag is going away after NS6, or so I am told by mozilla.org. If we didn't file it, we have no right to restrict others' access to it. I'm going to seek some other Netscape opinions on how dangerous this is, and work on a fix. Jesse, how do you think we should stop this?

David Baron: that doesn't work, because it's possible for another element on the page to be in front of part or all of the file control, or for the page to be scrolled in such a way that parts of the control aren't visible. Mitchell: For the file-control part of the problem, Hixie's solution of making the textbox read-only is a possible alternative to mine, and may be easier for branch/rtm, because it doesn't involve new dialogs. I think that users would prefer a dialog when submitting over a dialog when entering information, though. Can you think of a solution that would avoid the use of dialogs? Otherwise I haven't changed my mind about the solutions (for the file control and for selecting) since creating the attachment last night :)

I have sent a slightly modified copy of the attachment to Microsoft.

Just so that I'm sure I understand the issue: You are able to get a person to "cut" text into their clipboard that they didn't realize they were cutting, and then able to convince them to paste into a file-upload dialog, and not realize what they were pasting (since you fire the submit before they see the paste activity). Historically, there have been a number attacks focused on the file-upload dialog. Most critically it should be noticed that initial values (supplied server side) are not permitted. I recall some attacks where subtle bugs caused server-supplied values to injected into such file dialog fields... and we worked Very Hard (TM) to make that impossible (difficult??). We've also faced some interesting attacks surrounding sending of email (my mind is blurring a bit about this), but I believe we eventually made it very hard to automagically send email from a client machine (I believe we interjected a dialog when the client tried to compose and send without user intervention). That approach is probably a partial precedent about adding a dialog in at least some circumstances when a "significant" action is about to take place automagically (potentially outside of direct user control). My general feeling is that we should probably make it harder to simply paste into a file dialog (we already block JS from writing into it). Perhaps we should cause a paste operation to pop up a file-picker dialog, and have the paste land in the file-picker, rather than the file-box (this would mean that a user would have to click OK in a very suggestive form. I think we've already special cased file-dialogs and their text loading for security reasons, and this would probably be a good example in keeping up with that pattern. ...well...at least that is my thoughts based on a few minutes on this topic... maybe other folks will have different suggestions. If we had a real smooth fix RSN we might be able to consider it for the Netscape 6 branch... but we'd need to nail at least some direction, and have the patch in hand to consider risk.

Popping up the file picker on paste seems like strange ui to me, and that 'fix' wouldn't address bug 56236 or users who don't know that they should avoid allowing a filename to be in a textbox at any time. Using the dialog like that might even be dangerous, for example if the dialog is opened with an initial value of what is pasted instead of opened with a blank filename and then "pasted" escaped text. Also, what if the user was already planning to press enter immediately after pasting? mpt, any comments on the various dialog proposals? I've noticed that most discussion here has been about the file control. Should I file a separate bug for discussing the copy issue so it doesn't get lost?

Isn't one of the real problems here that the 'value' property of the file input DOM object gives the filename? Why should the filename in the file input be relevant outside the client?

`Please note that a display of "none" does not create an invisible box; it creates no box at all.' <http://www.w3.org/TR/REC-CSS2/visuren.html#display-prop> If that can be interpreted for clipboard purposes the way I think it can, my first choice would be never to include any `display: none' content when copying, period. The user is certainly never going to expect content which doesn't even appear to exist (let alone to be visible) to be copied. And at a stroke this would prevent any future security/privacy/IP attacks which we haven't thought of yet which could be caused by including `display: none' content in the clipboard. If that is unacceptable to Ian and David (who know more about `display: none' than I do), then my second choice would be to eliminate the text field from file input fields, and replace it with a read-only box indicating the currently selected file. (But then I'm biased, being a user of a system -- Mac OS -- where entering paths directly into the input field has never been possible anyway.) That would solve this bug, bug 56236, most other bugs involving file input fields, and the case where Granny doesn't know that c:\autoexec.bat shouldn't be used as a password or a login name. Ideally, I'd like both of these suggestions implemented, because each of them solves other potential problems besides the one described in this bug.

Now I come to think of it, my first suggestion doesn't work if you use <span style="font-size: 1px; color: whatever-the-background-is;"></span>, instead of <span style="display: none"></span>. Rats. I still think it's a good idea, but it wouldn't fix this bug by itself.

I've filed bug 57808 on the display:none selection issue, since it does not solve the problem at hand and may be a conformance issue in its own right.

Could we agree to make it read only for RTM and get a fix soon? Is it sufficient to just disable pasting in these fields? I'd hate to run out of time because we're looking for a theoretical best fix instead of just something that works.

Do we really want to do that? Won't people complain? Think of Bugzilla's add- attachment screen - people will complain if they can't type in a file path.

PDT marking [rtm-]. Not that serious, no fix in hand.

The easiest way to fix this is to make the text field part of the upload control read-only. This will disappoint those who like typing in file paths, but for them we could make a preference to turn that feature back on. That way, if you really know what you're doing, you can turn it back on and proceed with caution. Does anyone know of another less restrictive fix, preferably one that does not involve any additional warining dialogs?

Couldn't you make the text inaccessible from the DOM instead?

I would be one of the people complaining about a read-only text control. Please implement a confirmation dialog for uploading files instead, as Jesse suggests. You aren't uploading files too often, are you?

It's our policy to avoid dialogs wherever possible. Many users click OK without reading, so they don't really provide security. Andreas, would a hidden pref which makes the field writeable again be acceptable to you?

Let me ask again: Isn't the basic problem here that the filename is accessible through the DOM? Why should that be relevant to the web page author?

Andreas: the read only control would only be the control on the page, you could still type into the edit control that the file picker has. dbaron: No, the problem has nothing to do with the DOM. Check the demo.

I did check the demo.

The only time the demo uses the DOM to access the value is to check that the value has been entered. It could also be done by hooking into onChange events, onBlur events, overlaying some box over the top of the input box as a "security measure" so that user's couldn't see what they were typing, etc. The bug is that it is possible for user's to be tricked into thinking the file control is a normal text field. Another (less subtle) exploit would be for a webpage to hide the Browser button somehow and ask users to enter the answer to some questions on a "quiz page" -- a la "what is the name of the password file on unix systems?" "what is the path to the registry on a windows computer?" etc.

Mitchell: A hidden pref is not the best solution, for two reasons: 1. Even if it existed, I would probably be too lazy to turn it on for every new profile. I'd rather use the "Browse..." button then. 2. I'm not the only one who prefers the keyboard over the mouse. You would have to tell everyone else with this preference about the hidden pref. Hixie: It's true that I could use the file picker, but I'd like to avoid it if possible. It's an additional step to launch it, and (maybe that's a bug in the file picker) its edit control is too small IMO. But now that I'm playing with it, I agree that I could get used to it. So this would be one possible solution. However, it's not obvious for people used to 4.x why a file upload text control is not editable anymore, and it's likely that bugs will appear about it. If making the text control disabled is chosen as a fix, could the that text control be made look somehow different to make it clear that you have to perform some external action to change the value? See e.g. the selection of the destination dir in the installer. Two more notes: - In my case, the attack would not work because I got the "Security Warning" dialog that is triggered by form submission, and the real password value was visible then. - When I upload a file, I'd appreciate a confirmation (e.g. that I haven't made a typo in the file name) _before_ it is sent. I now recognize that such a confirmation is implicitly performed if the use of the file picker is enforced, because the file picker doesn't accept any non-existing filenames.

I don't think a pref to re-enable the textbox would be a good idea. There are many ways for a webpage to trick users into putting text in the field, and it's difficult to be sure that a page isn't trying to trick you, even if you're familiar with the various ways pages could trick you into putting text in the textbox and/or hide the file control from your view. Also, having a pref might obscure larger security holes that only affect people with the pref on. I prefer a dialog on form submission to the forcing the user to use the file picker dialog because a single dialog at the end seems less intrusive and more useful. I think the problem of dialog fatigue can be avoided by listing names and sizes of files being uploaded in the dialog itself.

I'm not a UI designer... but I'd still vote for an upload confirmation dialog. If you want, you could always put in the "don't ask me again" checkbox. If you wanted to get fancy, you could have "don't ask about this TYPE of file again" (which would handle jpeg uploads for example) or "don't ask about uploads to this SITE/PATH again" (which would handle bugzilla attachments, and webmail users.) ...and of course UI designers might want the "fancy" choices in an "advanced" dialog, or possibly the dialog type (basic vs fancy) could be controlled by a pref (not very discoverable, but not too "in your face" either).

So there's support for a warning dialog. If we go that route, we should probably have "don't ask again" apply per site. Maybe two checkboxes: "don't ask again for this site/page" and "Don't ask again, ever." That way, users could stop the dialog for sites they trust, such as Bugzilla's add-attachment page, but the dialog would still appear in the case of a malicious file-upload control, which may be hidden or disguised. The solutions suggested so far: 1) Warning dialog 2) Make text field read-only, possibly with an enabling pref So, we either limit functionality and make life a little tougher for those who prefer to type the path, or we add yet another warning dialog, which also detracts from the user experience, IMHO. Which is the lesser evil?

A new confirmation dialog is not my first choice, and I don't want to make the textbox read-only either, as people would complain. How about if we just make the contents of that textbox inaccessible from the DOM? I realize this wouldn't stop a dumb user from pasting and then clicking Submit without looking at what was pasted, but it would prevent a script from knowing when to do a submit() automatically, as in Jesse's example. This will give the user time to notice that what was pasted in the box is not what they expect, and hopefully not click Submit. Is this a reasonable fix? Any major problems with this? I think doing this would lower the stakes on this exploit from a somewhat-out-of-the-user's-control exploit to a social-engineering exploit; more equivalent to a webpage telling a user to copy and paste "del C:\" into a dos prompt. Is this a reasonable solution?

Updated QA Contact

There are several other attacks that don't rely on being able to read the filename through the DOM, although they probably wouldn't work as often. For example, I could catch events bubbled to the body element, and guess from those when the user did a paste. Or I could keep track of the mouse location and submit the form exactly 2 seconds after the cursor leaves the field. There are also several other possible ways to trick the user by hiding or disguising the control (in addition to disguising the browse button). If bug 6133 is fixed, scripts will be able to focus the textbox for the control, so the page will only have to trick you into typing or pasting (it wouldn't have to trick you into clicking on anything). I don't think the command prompt is a good analogy to a file upload control. Most users who use the command prompt are more careful when typing into a command prompt than they are typing into a random webpage. There are too many things to special-case (such as bug 56236) to prevent pages from hiding file upload controls or doing things with them, and disallowing some things may interfere with accessibility, bookmarklets, non-malicious scripts, etc. Also, some users just aren't familiar with file upload controls or the file system of the computer they're using. I think it's necessary to either disable the textbox or put up a confirm when the form is submitted. I prefer the confirm because it would continue to allow Windows and X users to choose between the file picker and the filename textbox. (The confirm should appear only if you set the current value of some file upload control textbox using the textbox and not the filepicker. When the confirm appears, though, it should always list all files being uploaded. It would be nice if it could also list file sizes and tell the user when they're uploading non-existent files.)

Adding esther to cc list

Mass changing milestone to Moz1.0 - stuff targeted for late spring/early summer.

Less important bugs retargeted to 0.9.9

Turns out this was discussed in the old bug database too. Here are some relevant comments, reposted from bugsplat 343466: 1) Any time you submit a form that uploads a file, have a warning display on the page that says, "Warning: you are about to upload the file c:\windows\win.ini to the remote server" or something like that. 2) Don't allow the file upload control to be resized, which enabled me to make it so small that it wasn't noticeable. One Peacefire member thought this was the real bug, since form controls aren't supposed to be resizeable. 3) Don't allow people to type in the path to a file in a file upload control. Only let people select a file by hitting the "Browse" button and browsing their hard drive. ----------------------------- The reasons that we think this method is best are that it is going to be hard to figure out all the ways to hide the file upload input box (hidden layers, who knows what else). And another possible fix is to prohibit catching key events on file upload fields, but this would prohibit a number of legitmate uses, such as disallowing certain characters from file names.

imo there is no legitImate reason to disallow characters from filenames. A filename is a reference to something locally, the fact that some browsers (mozilla?) include the full path and don't allow the user to provide a pretty name are (IMO) bugs. I'm not sure how much relying on the browse button will upset users, I can imagine it upsetting me for various reasons, but I'm not your average user. can we at least try to get some progress on this bug for 1.0?

--> qa bsharma@netscape.com

Timeless, what point are you trying to make? Are you suggesting a particular fix above others? Don't waste our time with "this should be fixed" messages - how do you think we should we fix it?

there's a bug somewhere about multiselect file upload fields or whatever they are. I'm going to make a few assertions, please correct each of them in turn as necessary. 1. right click (or equivalent) is not something web documents should be able to interfere with. 2. If we made file upload fields behave like os directory areas (* ok someone gets to explain that gtk isn't an os and that Qt and xlib and blah ... i'll leave that to some ui designer) 2a. this means that the view (and context) menu would allow the user to select details or list or icon view 2b. this means that the user can drag and drop items into this field 2c. allow users to specify the filename to report to servers -- perhaps a properties mechanism 3. we configure file upload fields [and submit buttons] so that they can *never* be stacked beneath anything. 4. we make submit buttons have a drop down which lists the items being uploaded. 5. Submit buttons which will result in file uploads gain an icon indicating the number of files 6. we severely restrict dom events for submit and upload controls. 7. any attempt to submit a form via dom/js instead of from a user's click/manual trigger of a submit button results in a confirmation dialog. 8. that dialog would list the files being uploaded. -- ok, i think that's the jist of my proposal. why do i think this would help? A. while a web 'application' can impersonate icons, it should *not* be able to impersonate the user's icons unless the user tells the applications what they are. B. integrating with say the view menu and right click is another thing that web applications should *not* be able to impersonate. C. while web applications can impersonate drag and drop within an html document, i'm almost certain they can't impersonate drop handling from a file manager. -- in normal cases, dropping a file onto a browser window would load the file... D. allowing the user to provide a filename to send to the server solves some other problems we have about the browser giving too much information about the host system. i suppose i should prioritize this, or at least explain how i'd like it to fit for 1.0 ... If we do XBL form controls for 1.0, then i think we can do points 4-8 in that time frame. The other points can be done later or along with other feature work.

> 1. right click (or equivalent) is not something web documents should be able > to interfere with. Unfortunately, that is not the case. :( > 3. we configure file upload fields [and submit buttons] so that they can > *never* be stacked beneath anything. This would earn us the undying hate of developers who are trying to create tabbed interfaces in HTML. > 7. any attempt to submit a form via dom/js instead of from a user's > click/manual trigger of a submit button results in a confirmation dialog. How do we handle the (fairly common) case of the submit button having an onclick handler that calls .submit() ? Should this dialog maybe only come up if the form has nonempty file upload controls? The rest looks fine.

> How do we handle the (fairly common) case of the submit button having an > onclick handler that calls .submit() ? Should this dialog maybe only come up > if the form has nonempty file upload controls? hrm, yeah nonempty :-)

I haven't tested this, but would it be theoretically possible to run a function which does something like this: function push_form() { document.forms[0].fileupload.value = "C:\autoexec.bat"; document.forms[0].submit(); } and in the body tag = OnLoad="javascript: push_form();" Therefore making David's point about refusing DOM access to fileupload elements even more valid. I can see the flipside - this also makes it impossible to check if the element has been completed, so anyone trying to check a form before submission (like almost every site) wouldn't be able to do so.

Scripts can not *set* .value on a file input, so the above would not work.

*** Bug 166103 has been marked as a duplicate of this bug. ***

Safari does what I suggested three years ago in comment 16: It doesn't have a text field in the first place. Just a "Choose File" button, with the icon and filename (not path) of the currently selected file displayed next to it in the UI font.

Which is what I suggested a day earlier, in comment 6. :-)

think we ought to go the route of restricting to the file picker and having a pref for user turn off the read only behavior. and try to do this for 1.8a(2). over to dan. hyatt any chance of sharing what safari users think of being resticted to just a file picker?

Chris, on mac having just a filepicker is absolutely the expected behavior (if nothing else, until OSX a filepath didn't even uniquely identify a file on a mac!). We have bugs on restricting to the filepicker on mac because that's what the users expect (filed by mpt, iirc).

A new techniqe has been found that can be used to effectively hide the browse... button from the control, thus making it look like an ordinary text box. This example [1] does actually repalce the browse button with an image, but could just as easily be used to have no button at all. It basically works by positioning a text box directly below the file upload control, and setting the 'opacity' of the file control to 0. The author obviously didn't realise the secuity problems with this, but it essentially defeats the whole purpose of not allowing other styles to be applied directly to file controls. [1] http://www.quirksmode.org/dom/inputfile.html

I created some examples to demonstrate how the techique I mentioned in comment 54 can be used, and put them on my website. http://lachy.id.au/dev/markup/examples/forms/file/

How about making the text field of the file upload control visually distinct from a normal text field? One thing that I can think of immediately would be to place an icon at the start of the text field, either a generic 'paperclip' icon, or one representing the chosen document - like the way the site icon works on the address bar.

*** This bug has been marked as a duplicate of 258875 ***