Closed Bug 57770 Opened 20 years ago Closed 15 years ago

Using styles, clipboard to confuse text entry into file upload control


(Core :: Security, defect, P1)






(Reporter: jruderman, Assigned: dveditz)


(Depends on 1 open bug)


(Keywords: csectype-spoof, sec-high, Whiteboard: Patch in bug 258875)


(1 file)

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 :)
Attached file demo
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.)
Keywords: rtm
Priority: P3 → P1
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 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.
QA Contact: czhang → paw
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. 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.' <>

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
Whiteboard: [need info]
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.
Depends on: 39098
PDT marking [rtm-]. Not that serious, no fix in hand.
Whiteboard: [need info] → [rtm-]
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.
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

...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
QA Contact: paw → ckritzer
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
Blocks: 6133
Blocks: 4033, 67873
Mass changing milestone to Moz1.0 - stuff targeted for late spring/early summer.
Target Milestone: --- → mozilla1.0
Blocks: 7258
Less important bugs retargeted to 0.9.9
Target Milestone: mozilla1.0 → mozilla0.9.9
Target Milestone: mozilla0.9.9 → Future
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?
Keywords: mozilla1.0
Whiteboard: [rtm-]
Target Milestone: Future → ---
--> qa
QA Contact: ckritzer → bsharma
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 

I'm going to make a few assertions, please correct each of them in turn as 
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 
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 
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 
> 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";

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.
Summary: easy to trick users into uploading files using styles, clipboard, and file upload control → Using styles, clipboard to confuse text entry into file upload control
*** Bug 166103 has been marked as a duplicate of this bug. ***
OS: Windows 98 → All
Hardware: PC → All
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. :-)
Flags: blocking1.7?
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?
Assignee: security-bugs → dveditz
Flags: blocking1.8a?
Flags: blocking1.7?
Flags: blocking1.7+
Flags: blocking1.7+ → blocking1.7-
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).
Flags: blocking1.8a1?
Whiteboard: [sg:fix]
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.

I created some examples to demonstrate how the techique I mentioned in comment
54 can be used, and put them on my website.
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.
Whiteboard: [sg:fix] → [sg:fix] Patch in bug 258875
Whiteboard: [sg:fix] Patch in bug 258875 → [sg:high] Patch in bug 258875

*** This bug has been marked as a duplicate of 258875 ***
Closed: 15 years ago
Resolution: --- → DUPLICATE
Depends on: 567362
Keywords: csec-spoof, sec-high
Whiteboard: [sg:high] Patch in bug 258875 → Patch in bug 258875
You need to log in before you can comment on or make changes to this bug.