1.67 KB, text/html
8.15 KB, patch
|Details | Diff | Splinter Review|
3.40 KB, text/html
Sample code: <form><label for="attachment">Attachment:</label> <input type="file" name="attachment" id="attachment"><input type="submit"></form> If the input is something like: \\server\path\to\file\filename then Mozilla submits just filename as the value of attachment in the form. But: //server1/path/to/file/filename works properly and gives the full path to the file and the filename.
Confirming; a litle odd... I thought we _always_ did just the filename, never the full path (for security reasons).
Status: UNCONFIRMED → NEW
Ever confirmed: true
me too actually. we shouldn't submit information about the clients local path details. that's wrong and the server does not need that info at all. hmmm... i tested on my machine against a PHP server with slashes [/] (using $HTTP_POST_FILES['fileinput']['name']) and I the upload fails (i also captured the HTTP trafic and the file i tried to upload was not attached). (build 2002050908) Reporter: can you give us some more info about how you managed to post the file with slashes on win2000?
I artificially created the forward slashes on W2K so it's perhaps not a real world bug. I was experimenting in trying to see what delimiters Mozilla used to split the filename from its path. The reason I noticed this bug is that I want the full path to the file to be posted to the server. This is the way MSIE behaves and it's useful for my project. It allows users to add files to a database via a web interface and the full path information is required. I have some appreciation of the security issues you mention, but this is for an internal project so they do not apply to me.
i don't think we want to do that, although i coundn't find on the fly security specs that would oppose the transmision of the entire path (consulted: HTML 4.01, RFC2388, RFC1867). however the issue is not mentioned at all so i would think that it was rather forgoten. i would need to check this with our security guys first, but i doubt this will go trough. is true: if you use / on windows the name will be entirely sent but the submission of the file itself fails.
Priority: -- → P3
Target Milestone: --- → Future
There is no spec that says that, but we explicitly try not to send it to avoid sending information about the user's local filesystem. If we send the entire filename in that case, that may mean that Mozilla is simply unable to parse the filename--when that happens we have no choice but to send the whole filename. This is either: - INVALID (not a bug, //../../../ is not a valid filename) - network bug (file->InitWithPath should handle //../../../) I don't have any shares on this computer so I can't test whether we should be sending the file or not. But the problem is whether we handle the filename at all, not the format we send it in. CC'ing darin, who may have some input on that issue.
nsLocalFileWin only parses '\' as the delimiter. it assumes the path entered is native. we might want to allow '/' on windows, since iirc filenames under windows cannot contain the '/' char. cc'ing dougt and mstoltz.
In any case, this is a networking:file question.
Assignee: alexsavulov → darin
Component: Form Submission → Networking: File
QA Contact: vladimire → benc
Please use the testcase to check which data mozilla transfers when using a file input form field. Cheers Daniel Kabs Germany
Sorry, the testcase doesn't work as expected cause it overwrites the cgi parameters needed to call the testcase. Still, you can see the parameter "path" in the url bar after submitting the page and check its contents. Alternatively, save the testcase to your computer and run it locally. My mozilla, Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312, does strip all leading path elements and submits only the filename, if I use '/' as path delimiter. On my windows system it's vice versa, it only strips the path if I use '\'. Thus, can anybody please change the summary accordingly: s/backslashes/path delimiters Cheers Daniel
Hope this works better.
Attachment #122475 - Attachment is obsolete: true
The testcase works! It now resubmits the form parameters to access the attachment from bugzilla. Could any sufficiently empowered user please change the summary accordingly: s/backslashes/path delimiters/ or even s/if the input includes backslashes// Thanks.
The point is, we strip the path if we're actually sending the file. That's what we want to be doing. See comment 5 for the reason this bug is not marked invalid yet.
Hello Boris, ah, I understand now, sending the full clients pathname is just not wanted because of security considerations. Obviously I should have paid more attention to comment #5. But I didn't, probably because I disagree. Contrary to what is stated in comment #2, I *do need* the full pathname on the server (and only the pathname, not the file's content). So what do I have to do to make this page work on Mozilla? I use the "onload" handler of the <form> element to store the full path in a hidden form field. Now everybody is happy, I guess.
(In reply to comment #13) > Contrary to what is stated in comment #2, I *do need* the full pathname on the > server (and only the pathname, not the file's content). scripts can get at the pathname of the entered filename!? Can we fix that?
(In reply to comment #14) > scripts can get at the pathname of the entered filename!? Can we fix that? In http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-6043025 you can find the following note: Depending upon the environment in which the page is being viewed, the value property may be read-only for the file upload input type. For the "password" input type, the actual value returned may be masked to prevent unauthorized use. They don't say anything about "masking" the value of the file upload input type. Wouldn't that be a bit too paranoid?
It's obvious, that I am against Mozilla masking the filename :-) To circumstantiate my point, one more quote from the "Interface HTMLInputElement" (W3C DOM) about the value attribute of the input type form field: value of type DOMString When the type attribute of the element has the value "text", "file" or "password", this represents the current contents of the corresponding form control, in an interactive user agent.
>They don't say anything about "masking" the value of the file upload input type. >Wouldn't that be a bit too paranoid? if we allow it, we may as well submit the full path to the server. (although the difference is that this one requires having JS enabled...) -> form controls, I don't think this is a necko issue
Assignee: darin → nobody
Component: Networking: File → Layout: Form Controls
QA Contact: benc → core.layout.form-controls
ccing security folks. Resummarizing to reflect the problem we're left with.
Severity: enhancement → normal
OS: Windows 2000 → All
Priority: P5 → --
Hardware: PC → All
Summary: When submitting a file as part of a form the submitted value is truncated to only the filename (no path) if the input includes backslashes → Script can get the value of a file control, including the path
Target Milestone: Future → ---
I can't set this Bug to INVALID, but I'd like to vote to this effect.
(In reply to comment #18) > ccing security folks. Resummarizing to reflect the problem we're left with. I don't think security is a problem. Far from it, disallowing scripts to access the "value of a file control" would break quite a number of sites. I know portals for uploading digital camera images whose web interface takes advantage of the fact that scripts *can* access the "value of a file control".
IMO, scripts should have access to the filename, but not the path. That would be consistent with what servers get when the form is submitted.
Daniel, do these portals actually need to know the location of the file on the user's hard drive, or just the filename? We don't really want to give away the former, and I think we should fix GetValue() on the file control accordingly..
Darn, I shouldn't have told you about the possibility for scripts to access the filename in the first place. This bug could have been closed by now already. I wish I could undo my comment #13. ;-) Back to your question, Boris. An example for a web page that evaluates the value of the file control (aka. path) is at http://as.photoprintit.de/web/46382500/selectClient.do?type=print See the file control on the page? Its path is read and used in two places: First it's applied to the src attribute of an dynamically created image element to present a preview image to the user (this only works in IE, I guess because of FF's security restrictions). Second, a hidden form field is created with the path assigned to its value (I don't know what they do with that). I mentioned another example in comment #13: I wrote a web application that needs to read the filename. The files are choosen from a global intranet share. So we do not actually need to upload the file, the path is sufficient. But I guess, my own programming does not count as a valid argument... So basically I do not understand why you want to mask the path. Quite contrary, as I argued in comment #16 I think masking the path disagrees with the W3C dom specifications for "Interface HTMLInputElement": http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-49531485
> this only works in IE, I guess because of FF's security restrictions Right. > I don't know what they do with that Right. I question whether it would break; I'd need to see evidence that it does. > The files are choosen from a global intranet share. So this is an intranet app? This is why we have the ability for signed web pages or servers that the user allows to do so to request expanded privileges. If you want to have more access to the user's computer than a typical assumed-malicious page does, you need to use that mechanism. > So basically I do not understand why you want to mask the path. Because I don't want the whole internet to know what files live where on the user's (read "my") hard drive. Directory names are the user's private information, and a user selecting a file to upload probably doesn't want the server to have that information. > I think masking the path disagrees with the W3C dom DOM methods are restricted due to security considerations in all sorts of ways. This is generally understood to be the way things work -- the DOM spec doesn't spell out all the security restrictions (and in fact spells out very few). For example, per DOM spec you can get the documentElement property of a Document. In reality, you can do this only to those documents that are from the same origin as you, unless you request, and are granted, expanded privileges.
(In reply to comment #24) >> this only works in IE, I guess because of FF's security restrictions >Right. That's the reason why I use Firefox for everything *except* when I upload images to order digital prints online. By the way, this is quite a common and popular web application today. I guess you are going to test your change beforehand on a couple of upload portals to see if it breaks. > Right. I question whether it would break; I'd need to see evidence that > it does. I can only speculate: They might store the name for later reference e.g. when the user decides to delete an image from the upload list. But what happens, if all images have the same name? > Because I don't want the whole internet to know what files live where on the > user's (read "my") hard drive. Directory names are the user's private > information, and a user selecting a file to upload probably doesn't want the > server to have that information. If you do not want to expose the pathname, why not copy the files into a temporary folder beforehand? I usually upload files from folders named "D:\transfer" or "C:\temp" or "/tmp/images/" for that reason. I take path exposure as innocuous for I can think of worse attack schemes: Is it possible for a script to create file controls dynamically using DOM manipulation and *set* the path to well known files, e.g. "/etc/passwd" or "C:\hiberfil.sys"? If this is possible, the "whole internet" would not only know the pathnames but the contents of files you never wanted to upload! Cheers Daniel
> If you do not want to expose the pathname, why not copy the files Because most users are not aware of security issues, including this one. We should still protect them, though. > and *set* the path to well known files Of course not (as you could have tested yourself, had you taken the 2 minutes to write such a page). Any bug that allows that is treated as a critical security bug -- you can look through bugzilla for examples of such in the past if you care.
Opera gives only the filename, not the full path, when script reads .value on the input control which is consistent with what browsers send to the server. This flaw was raised recently on the Hacker Webzine http://www.0x000000.com/?i=476
Whiteboard: [wanted-1.9] → [sg:want][wanted-1.9]
Is this even an issue any more that you can't enter the filename?
Oh, wait, it is, why the heck do we do that?
12 years ago
Summary: Script can get the value of a file control, including the path → [FIX]Script can get the value of a file control, including the path
Comment on attachment 288696 [details] [diff] [review] We've got to stop dropping the ball I think it's a little weird to be changing the functionality based on if UniversalFileRead is enabled. Would prefer to have the full path in a new property only accessible to such callers instead. But r/sr=me either way.
Comment on attachment 288696 [details] [diff] [review] We've got to stop dropping the ball Doing that would mean either a property that always throws on get on webpages (bad for people doing for..in stuff) or hacking classinfo like we do for nodePrincipal. I prefer either doing what this patch does, or simply not allowing anyone (including chrome) access to the full path. Seems like that could affect some extensions, though... This seemed safer.
Attachment #288696 - Flags: approval1.9?
see also directoryName in Bug 390776
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Another issue: http://www.0x000000.com/index.php?i=479 due to two field inside one label its possible to steal focus yet again...
That has nothing whatsoever to do with this bug. Please file a separate bug on it? Make sure to include some steps to actually reproduce, because following the directions on that site I don't see the claimed bug on trunk. On branch it's an issue of course (in that clicking the textfield focuses the file input), but that's been known for a long time by anyone who cares. We have a bug no it somewhere; that's what prompted the changes on trunk to make the file input not focusable.
Is this worth taking on the 1.8 branch? As much as I'd like to I'm guessing the few complaints coming in mean we shouldn't change this behavior in a minor update -- to them it would just be gratuitous breakage.
I would be fine with taking this on branch actually. Haven't we taken security fixes on branch before that were known to break stuff?
Whiteboard: [sg:want][wanted-1.9] → [sg:want]
Added a section to "Updating web applications for Firefox 3": http://developer.mozilla.org/en/docs/Updating_web_applications_for_Firefox_3#File_upload_fields
I would also request that this be backported to 1.8.1. This is potentially very dangerous for whistleblowers or anonymous bloggers uploading files via webforms. I don't see how many webapps could need to rely on the full path of a filename, especially if other browsers are already returning just the leaf name here...
Boris: this looks like it'd be easy to land on the 1.8 branch, any reason we can't do that for 220.127.116.11?
I can't think of any offhand, other than the obvious compat issue...
The ebay breakage (bug 417715) has been fixed, perhaps it will be safe to take this on the branch now as changed behavior in the impending FF3 gets more attention now.
It would be good for the current FF2 and FF3 to match behavior, and fixing this also improves privacy so we want this on the branch now.
Flags: blocking18.104.22.168? → blocking22.214.171.124+
I don't think this is worth taking on the branch. The benefit seems small, there doesn't seem any interest in exploiting this in the wild.
Whiteboard: [sg:want] → [sg:want][needs branch patch?]
I'm quite confused. Boris' patch (comment #33) seemed to do exactly what we need here : allow trusted scripts to access the full path. This is absolutely necessary in secured intranets and unlikely to bother anyone else. The script must either be signed or the user must specifically (and tediously) allow this script to allow the UniversalFileRead permission. (Enabling this is a two-step process -- requiring the change to "signed.applets.codebase_principal_support" AND the PrivilegeManager form submitted by the user.) But now in FF3, it seems categorically disabled (and at any rate, I haven't been able to get it to use the full path, even though all the above steps were followed for allowing the script to do just that). (see comment #41). So what's the deal?
You definitely can open and read a file in FF3 if you jump through all the required hoops. Attaching an example - password for this zip is "ff3".
Same thing unzipped
Attachment #328847 - Attachment is obsolete: true
I'm sorry for the previous spam. I had read that the "enablePrivilege" setting must be inside the <script> scope. However, after playing with it some, I discovered it must be in the function that accesses the value, not just the file that this function is defined in.
Yes, you must be privileged in order to read the value from the form (as in my example).
I can't quite tell if this is fixed or not for what I care about. I work on an enterprise web based app that uses the full path in a lot of places for client side validation (shows an error indicator if not a valid filename or is empty), and the inability to get the full path breaks all of these cases, preventing save/ok buttons from being enabled. As a result, users must use IE or an older version of FF to access these upload pages. Will I be able to get a full path in FF3 as a result of the fix that was apparently made? In which release of FF3? Will I be able to get it with field.value, or will there be a different approach?
Jeff, either stick with FF2 or see the attachment in comment #50. => "Example of how to open and read a file in FF3 (and IE)" works well. I've just tested it.
Yeah, I saw your example, but I also saw that this bug is marked as "fixed", so I guess I don't know what "fixed" means. Unfortunately it's not reasonable to tell customers to tell all their users to make a change in about:config. Guess that means we're out of luck. :(
do note that IE8 is making the same change, for the same reason. So you probably need to find some other solution no matter what. Further, I would absolutely *not* recommend your users to go into about:config and tweak settings, especially security related ones like this on. Doing so runs serious risks of compromising your users computers. And yes, this bug is fixed. The way you can tell is by looking at the "Status" field at the top of the page which says "RESOLVED FIXED". This is one of those unfortunate cases where you, a good guy, want access to a tool that bad guys can use for evil. This one is especially unfortunate since this tool used to be available due to lots of this stuff being written long long time ago in more innocent times.
Oh, and this bug is about *not* making the full path available since that can be used by evil-doers for evil things. So "fixed" in this case means that we no longer make the path available.
Jeff, you can still get the filename, just not the path. That should be enough to tell whether the user has selected a valid type of file, right?
If all you want is to get the path (not open/read the file) then there's another possibility suggested in bug 405630 comment #40 using an Applet. That avoids having your users play about with settings or having to accept the rather severe warning that is shown.
Mozilla probably considers that to be a security hole in Java, so I wouldn't recommend relying on it staying around in the future.
(In reply to comment #53) > I can't quite tell if this is fixed This bug as filed is fixed. You can no longer get the full path. > client side validation (shows an error indicator if not a valid filename > or is empty) The latter will obviously still work. The former is a non-issue, since users can only select a file via the filepicker, so the path is always a valid filename, if nonempty. Note also that HTML5 Web Forms will have more hooks for doing what you want here. > Will I be able to get a full path in FF3 as a result of the fix that was > apparently made? The fix was fixing a security hole so that you can no longer get the full path.
I would imagine I don't actually need the full path for validation. All of our code which does that precedes my employment, so I'm not sure why the validation we do cares. So we can fix our code to work around this change, but it's a shame that for our currently released version users are just plain out of luck. And yes, I misinterpreted the original bug report so that's why I was confused by it being marked as "fixed". Thanks everyone. I've entered a defect against our product to get these validation problems fixed. :)
This was never a bug to begin with, but you've gone ahead and smugly broken many people's intranet applications. What is an attacker going to do with an ill-gotten file path? The answer, which seems to have eluded all of you, is NOT A DAMN THING. For a path to be useful, the user's system would have to have far more severe security problems. The very first comment demonstrates the usefulness of having the file path: files on the local intranet. We have very large files that we refer to in our intranet order system. They're so large that we'd much rather NOT upload them, but the file input is much more accurate than making people type the whole path. Your proposed work-around is an ugly, browser specific hack that requires the user to do things that non-technical people aren't going to understand. NICE WORK.
This is not a "browser specific hack". Opera does something similar to what we do. IE8 will do this for the "Internet Zone". http://blogs.msdn.com/ie/archive/2008/07/02/ie8-security-part-v-comprehensive-protection.aspx As noted in comments above, if you use privileged scripts then those scripts are able to get the full path name. That is our solution for intranets.
The path often contain the user account name which is quite useful for attempting to hack a users account. Once you have that you can attemp to get the password through brute force hacking, guessing (dogs name, kids name, fruit or any of the other common passwords), social engineering, or setting up a dummy site and hope that the user uses the same password. And like rod points out, every other browser is doing the same thing in current or upcoming releases. Could you perhaps use the input.files feature to solve your problem?
I have to say guys , you really dropped the ball on this one. This is a total example of tail wagging the dog and people trying to solve a problem that doesn't exist. Brad summed it up perfectly in comment 63 and all that will happen is people will keep using an older version of firefox and browsers instead of having to update their code.
I don't think that the solution comment #67 suggests is viable. If it is really a matter of security not to reveal the path when uploading a file, we have to both - prevent scripts from reading the path and - remove path from upload data stream This is true for enctype="multipart/form-data". On the other hand, there may be times when only the path is important, i.e. I am NOT uploading a file. In this case I don't see any problems in sending the full path. This behaviour should be implemented when enctype is set to "application/x-www-form-urlencoded". Anyway, what good is input type='file' when enctype is set to "application/x-www-form-urlencoded" and the path is stripped?
(In reply to comment #67) > Could we compromise and: > 1) Make the full path available to scripts. This will at least allow the > scripts to see if they can work around issues by other means. The path IS available to scripts if they obtain elevated privileges or are signed. The problem with allowing any normal script to read the path is it makes no distinction between a well-meaning web app developer and a malicious hacker. The two mechanisms mentioned make that distinction.
Ok, I'll try to spell out the problem again since apparently there is still confusion: The reason that access to the full path is limited is that sometimes the path contains sensitive information. For example in many OSs the path contain the account-name for the current user (this is the case on at least windows, OSX and linux). If an attacker got hold of the user-name for a user that gets you 50% there for guessing a users username+password needed to log in as the user. Getting the password can be done through guessing, dictionary based attacks, or social engineering ("Hi, this is the IT department, your user account 'foopy' is having problems, can you send us your password so we can fix it"). There are plenty of other ways that a directory name can contain sensitive information, such as "/google/documents/deals/GoogleYahoo2009/PR.txt" or "/documents/crappyboss/report.txt", however the above method of getting the username is likely the biggest problem. Yes, there is absolutely a lot of applications that could make use of the path name. Access to the path name was not removed because it was considered useless, but because it was considered potentially unsafe. This is one of those unfortunate situations where a feature is useful to you, the good guy, to do good things, but can be abused by bad people to do bad things. It is extra unfortunate that way back many years ago when this feature was added to web browsers this problem wasn't realized, and so many people have come to depend on it. However we still have to put user security first. So note that we are talking about evildoers grabbing usernames and other sensitive data that the user did not realize was exposed by simply choosing a non-sensitive file to upload. This means that it doesn't help if the data is just exposed to script since script can send the data to the server. I hope that makes it clear *why* we made this change. We are aware that it causes problems, but there is little we can do without putting users at risk. Also note that IE8 is making the same change, even when in IE7-compat mode. This is what I've been told in the past, and testing with IE8 beta2 confirms this. (However IE does sometimes do some things differently for the intranet zone, this might be one of those cases).
Whiteboard: [sg:want][needs branch patch?] → [sg:want][needs branch patch?] See comment 70 for why change was made
We have components which need the full path of the file. We get the file with full path and digitally sign the file through the components. If Firefox 3 will not return the full path of the file uploaded, it will stop our components to work. SO, you provide us a solution where we can get the Full path of the file. If you need any other information, please tell me....
If your "components" are trusted (e.g. an extension) then they can get the full path. Of course all that is already covered in this bug, which you _did_ read before commenting, right?
Yes I did. After I did it it showed me a Dialog box with Allow and Deny. The box had message like "Site is trying a UNSAFE Operation....... " . When I click allow it went ahead and if I say deny it stops. I am thinking one possibility - First time user Denies and selects the "Remember My Setting" option. Later he will always get the error. I need to know two things - 1. Is there any way I can suppress "Allow-Deny" box if the setting in about:config is done ? 2. Once he denies and select "Remember My Setting", how can he undo it so that he can get the "Allow-Deny" box again. We use "InstallTrigger.install" function to install the plugins from a XPI. Can we do something so that when our components are loaded in the page the saif settings gets enabled automatically. I tried to add a pref.js in the XPI with user_pref("signed.applets.codebase_principal_suppor", true); and pref("signed.applets.codebase_principal_suppor", true); in it, didn't work. Any idea ?
Sorry, that's beyond what I know. I assume the typo above is not in the real code ?
The typo is not exactly in the coding. But "InstallTrigger.install" is used to install a XPI file. What I actually meant is it should be possible to modify this config properties problematically some how e.g. if I am distributing a Digitally Signed XPI.
People should really take this discussion to one of the newsgroups, since it's drifting far away from the point of this bug (involving as it does as specific extension, etc). I'll be happy to help get this working for Priya, but I'm not going to do it here.
Boris, Can you tell me the URL where you can help me ?
Great - you fixed it, now re-break it. "If an attacker got hold of the user-name for a user that gets you 50% there for guessing a users username+password" You mean Unix is half as secure as windows because of "root"? The user's account is _not_ a secret - when I worked at Microsoft (and all other large organizations) we sent it out with EVERY SINGLE EMAIL! This is a major step backwards. I used to be able to preview images and graphically create cropping and scaling information before uploading.
As it happens, in current Gecko builds you can "preview images and graphically create cropping and scaling information" without exposing any of the user's private information (via the file api being standardized in the w3c). Sounds like a win-win to me.
> You mean Unix is half as secure as windows because of "root"? No, because windows also has well known privileged accounts like localadmin
What I was trying to do was get the file a users selects from the form and send it to a PHP program that uses the copy() function to upload it to the server. Is there any other way to upload a file via PHP? Other languages? Thanks, - Mark
> and send it to a PHP program Whatever code has the permissions to do that also has the permissions to get the full path.
You need to log in before you can comment on or make changes to this bug.