Bug 143220 - [FIX]Script can get the value of a file control, including the path
 Summary: [FIX]Script can get the value of a file control, including the path
 Status: RESOLVED FIXED [sg:want][needs branch patch?] See co... dev-doc-complete, privacy Core Components Layout: Form Controls (show other bugs) Trunk All All -- normal with 4 votes (vote) --- Boris Zbarsky [:bz] (still a bit busy) Jet Villegas (:jet) (view as bug list) 480764 405630 417715 436116 Show dependency tree / graph

Reported: 2002-05-09 04:31 PDT by Ben Thompson
Modified: 2010-07-12 17:40 PDT (History)
31 users (show)
reed: wanted1.9+
dveditz: wanted1.8.1.x+
bzbarsky: in‑testsuite+
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Attachments
Testcase: HTML Page with form that submit the data to itself for analysis. (1.58 KB, text/html)
2003-05-05 03:35 PDT, Daniel Kabs, reporting bugs since 2002
no flags Details
Testcase V2: HTML Page with form that submit the data to itself for analysis. (1.67 KB, text/html)
2004-10-20 02:09 PDT, Daniel Kabs, reporting bugs since 2002
no flags Details
We've got to stop dropping the ball (8.15 KB, patch)
2007-11-14 10:10 PST, Boris Zbarsky [:bz] (still a bit busy)
jonas: review+
jonas: superreview+
mtschrep: approval1.9+
Details | Diff | Splinter Review
Example of how to open and read a file in FF3 and IE (1.53 KB, application/zip)
2008-07-10 02:17 PDT, Duncan Loveday
no flags Details
Example of how to open and read a file in FF3 (and IE) (3.40 KB, text/html)
2008-07-10 02:25 PDT, Duncan Loveday
no flags Details

 Ben Thompson 2002-05-09 04:31:44 PDT Sample code:
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. Boris Zbarsky [:bz] (still a bit busy) 2002-05-09 08:48:02 PDT Confirming; a litle odd... I thought we _always_ did just the filename, never the full path (for security reasons). Alexandru Savulov 2002-05-09 13:47:38 PDT 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? Ben Thompson 2002-05-10 01:06:03 PDT 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. Alexandru Savulov 2002-05-12 00:52:46 PDT 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. John Keiser (jkeiser) 2002-08-31 13:57:11 PDT 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. Darin Fisher 2002-08-31 16:55:07 PDT 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. Boris Zbarsky [:bz] (still a bit busy) 2003-04-11 11:02:47 PDT In any case, this is a networking:file question. Daniel Kabs, reporting bugs since 2002 2003-05-05 03:35:26 PDT Created attachment 122475 [details] Testcase: HTML Page with form that submit the data to itself for analysis. Please use the testcase to check which data mozilla transfers when using a file input form field. Cheers Daniel Kabs Germany Daniel Kabs, reporting bugs since 2002 2003-05-05 03:46:33 PDT 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  Daniel Kabs, reporting bugs since 2002 2004-10-20 02:09:48 PDT Created attachment 162679 [details] Testcase V2: HTML Page with form that submit the data to itself for analysis. Hope this works better. Daniel Kabs, reporting bugs since 2002 2004-10-20 02:15:43 PDT 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. Boris Zbarsky [:bz] (still a bit busy) 2004-10-20 08:08:58 PDT 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. Daniel Kabs, reporting bugs since 2002 2004-10-21 02:57:17 PDT 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
element to store the full path in a hidden form field. Now everybody is happy, I guess. Christian :Biesinger (don't email me, ping me on IRC) 2004-10-21 06:02:46 PDT (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? Daniel Kabs, reporting bugs since 2002 2004-10-21 11:26:42 PDT (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?  Daniel Kabs, reporting bugs since 2002 2004-10-21 13:13:53 PDT 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.  Christian :Biesinger (don't email me, ping me on IRC) 2004-10-21 13:57:42 PDT >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 Boris Zbarsky [:bz] (still a bit busy) 2004-10-21 14:54:50 PDT ccing security folks. Resummarizing to reflect the problem we're left with. Daniel Kabs, reporting bugs since 2002 2004-11-25 02:04:48 PST I can't set this Bug to INVALID, but I'd like to vote to this effect. Daniel Kabs, reporting bugs since 2002 2007-01-13 12:45:11 PST (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".  Jesse Ruderman 2007-01-13 23:43:19 PST 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. Boris Zbarsky [:bz] (still a bit busy) 2007-01-14 08:30:27 PST 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.. Daniel Kabs, reporting bugs since 2002 2007-01-14 14:48:55 PST 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  Boris Zbarsky [:bz] (still a bit busy) 2007-01-14 17:45:38 PST > 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. Daniel Kabs, reporting bugs since 2002 2007-01-16 08:20:06 PST (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  Boris Zbarsky [:bz] (still a bit busy) 2007-01-16 09:14:10 PST > 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. Jesse Ruderman 2007-03-14 23:12:49 PDT *** Bug 374015 has been marked as a duplicate of this bug. *** Daniel Veditz [:dveditz] 2007-11-13 23:47:51 PST 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 Jonas Sicking (:sicking) No longer reading bugmail consistently 2007-11-14 00:32:27 PST Is this even an issue any more that you can't enter the filename? Jonas Sicking (:sicking) No longer reading bugmail consistently 2007-11-14 00:42:27 PST Oh, wait, it is, why the heck do we do that? Boris Zbarsky [:bz] (still a bit busy) 2007-11-14 10:10:14 PST Created attachment 288696 [details] [diff] [review] We've got to stop dropping the ball Jonas Sicking (:sicking) No longer reading bugmail consistently 2007-11-14 10:51:43 PST 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. Boris Zbarsky [:bz] (still a bit busy) 2007-11-14 11:34:38 PST 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. Biju 2007-11-14 18:55:30 PST see also directoryName in Bug 390776  Boris Zbarsky [:bz] (still a bit busy) 2007-11-14 22:16:14 PST Checked in. tha featurizer 2007-11-19 09:10:22 PST Another issue: http://www.0x000000.com/index.php?i=479 due to two field inside one label its possible to steal focus yet again... Boris Zbarsky [:bz] (still a bit busy) 2007-11-19 09:21:34 PST 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. Jeremy Baron 2007-11-27 05:36:48 PST *** Bug 405630 has been marked as a duplicate of this bug. *** Daniel Veditz [:dveditz] 2007-12-21 13:56:11 PST 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. Jonas Sicking (:sicking) No longer reading bugmail consistently 2007-12-31 14:48:48 PST 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? Eric Shepherd [:sheppy] 2008-04-15 13:59:47 PDT 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 Mike Perry 2008-04-19 22:14:51 PDT 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... Daniel Veditz [:dveditz] 2008-05-21 11:37:28 PDT Boris: this looks like it'd be easy to land on the 1.8 branch, any reason we can't do that for 1.8.1.15? Boris Zbarsky [:bz] (still a bit busy) 2008-05-21 14:00:53 PDT I can't think of any offhand, other than the obvious compat issue... Daniel Veditz [:dveditz] 2008-05-24 09:48:18 PDT 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. Daniel Veditz [:dveditz] 2008-05-28 11:25:58 PDT 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. Robert O'Callahan (:roc) (email my personal email if necessary) 2008-05-28 16:20:44 PDT 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. Otheus 2008-07-10 02:06:19 PDT 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? Duncan Loveday 2008-07-10 02:17:24 PDT Created attachment 328847 [details] Example of how to open and read a file in FF3 and IE 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". Duncan Loveday 2008-07-10 02:25:48 PDT Created attachment 328849 [details] Example of how to open and read a file in FF3 (and IE) Same thing unzipped Otheus 2008-07-10 02:41:51 PDT `I'm sorry for the previous spam. I had read that the "enablePrivilege" setting must be inside the

 Note You need to log in before you can comment on or make changes to this bug.