143220 - [FIX]Script can get the value of a file control, including the path

Status: RESOLVED FIXED

(Core :: Layout: Form Controls, defect)

Description

[Ben Thompson]

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.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Confirming; a litle odd... I thought we _always_ did just the filename, never
the full path (for security reasons).

Comment 2

[Alexandru Savulov]

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?

Comment 3

[Ben Thompson]

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.

Comment 4

[Alexandru Savulov]

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.

Comment 5

[John Keiser (jkeiser)]

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.

Comment 6

[Darin Fisher]

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.

Comment 7

[Boris Zbarsky [:bzbarsky]]

In any case, this is a networking:file question.

Comment 8

[Daniel Kabs, reporting bugs since 2002]

Attachment: 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

Comment 9

[Daniel Kabs, reporting bugs since 2002]

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

Comment 10

[Daniel Kabs, reporting bugs since 2002]

Attachment: Testcase V2: HTML Page with form that submit the data to itself for analysis.

Hope this works better.

Comment 11

[Daniel Kabs, reporting bugs since 2002]

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.

Comment 12

[Boris Zbarsky [:bzbarsky]]

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.

Comment 13

[Daniel Kabs, reporting bugs since 2002]

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.

Comment 14

[Christian :Biesinger (don't email me, ping me on IRC)]

(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?

Comment 15

[Daniel Kabs, reporting bugs since 2002]

(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? 

Comment 16

[Daniel Kabs, reporting bugs since 2002]

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.

Comment 17

[Christian :Biesinger (don't email me, ping me on IRC)]

>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

Comment 18

[Boris Zbarsky [:bzbarsky]]

ccing security folks.  Resummarizing to reflect the problem we're left with.

Comment 19

[Daniel Kabs, reporting bugs since 2002]

I can't set this Bug to INVALID, but I'd like to vote to this effect.

Comment 20

[Daniel Kabs, reporting bugs since 2002]

(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".

Comment 21

[Jesse Ruderman]

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.

Comment 22

[Boris Zbarsky [:bzbarsky]]

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..

Comment 23

[Daniel Kabs, reporting bugs since 2002]

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

Comment 24

[Boris Zbarsky [:bzbarsky]]

> 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.

Comment 25

[Daniel Kabs, reporting bugs since 2002]

(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

Comment 26

[Boris Zbarsky [:bzbarsky]]

> 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.

Comment 28

[Daniel Veditz [:dveditz]]

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

Comment 29

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Is this even an issue any more that you can't enter the filename?

Comment 30

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Oh, wait, it is, why the heck do we do that?

Comment 31

[Boris Zbarsky [:bzbarsky]]

Attachment: We've got to stop dropping the ball

Comment 32

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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 33

[Boris Zbarsky [:bzbarsky]]

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.

Comment 34

[Biju]

see also directoryName in Bug 390776 

Comment 35

[Boris Zbarsky [:bzbarsky]]

Checked in.

Comment 36

[tha featurizer]

Another issue:

http://www.0x000000.com/index.php?i=479

due to two field inside one label its possible to steal focus yet again...

Comment 37

[Boris Zbarsky [:bzbarsky]]

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.

Comment 39

[Daniel Veditz [:dveditz]]

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.

Comment 40

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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?

Comment 41

[Eric Shepherd [:sheppy]]

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

Comment 42

[Mike Perry]

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...

Comment 43

[Daniel Veditz [:dveditz]]

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?

Comment 44

[Boris Zbarsky [:bzbarsky]]

I can't think of any offhand, other than the obvious compat issue...

Comment 45

[Daniel Veditz [:dveditz]]

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.

Comment 46

[Daniel Veditz [:dveditz]]

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.

Comment 47

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 48

[Otheus]

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?

Comment 49

[Duncan Loveday]

Attachment: 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".

Comment 50

[Duncan Loveday]

Attachment: Example of how to open and read a file in FF3 (and IE)

Same thing unzipped

Comment 51

[Otheus]

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. 

Comment 52

[Duncan Loveday]

Yes, you must be privileged in order to read the value from the form (as in my example).

Comment 53

[Jeff Shanholtz]

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?

Comment 54

[Daniel Kabs, reporting bugs since 2002]

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.

Comment 55

[Jeff Shanholtz]

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. :(

Comment 56

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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.

Comment 57

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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.

Comment 58

[Jesse Ruderman]

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?

Comment 59

[Duncan Loveday]

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.

Comment 60

[Jesse Ruderman]

Mozilla probably considers that to be a security hole in Java, so I wouldn't recommend relying on it staying around in the future.

Comment 61

[Boris Zbarsky [:bzbarsky]]

(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.

Comment 62

[Jeff Shanholtz]

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. :)

Comment 63

[Brad]

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.

Comment 64

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 65

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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[0] feature to solve your problem?

Comment 66

[Stewart P]

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.

Comment 67

[Vinny Joe]

I am adding my voice to those who find the current implementation wanting.

We have an app where we distinguish between root-folder/src/app1/web/index.html and root-folder/src/app2/web/index.html. We pick the file, upload it, and on the server strip out the common prefix root-folder/src/; leaving app1/web/index.html and app2/web/index.html. With FF3, as is, our app is broken. 

In my case, I can consider adding the app1/web value to some new non visible input field on the form; for that to happen I still must have access to the full path from the browsers javascript environment. I have the ability to send only the information I need without revealing the whole path - the browser by default does nothing damaging, but gives me enough rope to leverage myself. 

Others have pointed out very reasonable use cases where the current behavior causes undue grief. I fully acknowledge that for others the above technique may not suffice.

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.
2) As *default* behaviour send only the file name when the form is submitted. However there should be a way to enable full path. That way Firefox is not "blamed" for putting the full path on the upload stream.

As for IE8 implementing it, based on the url listed a few comments above, I got the impression the full path was not submitted in the upload data stream, but there was no mention of the full path not being available via the browser script environment. 

I would like to separate the issue into two concerns: 
1) the full path being sent out by default on the upload data stream by the browser.
2) the full path being available via the browsers script environment.

In my opinion, #2 should be standard, and #1 should be configurable to deviate from the default.

Thanks for taking the time to read this.

Comment 68

[Daniel Kabs, reporting bugs since 2002]

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?

Comment 69

[Duncan Loveday]

(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.

Comment 70

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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).

Comment 71

[Priya]

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....

Comment 72

[Boris Zbarsky [:bzbarsky]]

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?

Comment 73

[Priya]

Our Components are trusted... 
We are copying the dlls to system32 using an exe.
For copying the plugins, we have used install.rdf as suggested by one of the posts in Bugzilla.
We are calling LoadLibarary() in the Plugin to load the dlls.
Our code is something like this:
Declaration of HashData Function:
CString HashData(LPCWSTR bstrData, LPCTSTR bstrDataFileName, LPCTSTR bstrHashAlgorithm);
Definition:
NS_IMETHODIMP nsScriptablePeer::HashData(LPCWSTR bstrData,const char *bstrDataFileName, const char *bstrHashAlgorithm,char **_retval)

The second parameter accept the Full path of the file to be hashed.

We have been passing the path of the file using javascript. 
Now, in FF3 how do I get the full path in the extension.

Comment 74

[Duncan Loveday]

Priya, did you try acquiring elevated privileges as in comment #50 ? I'm not an extension developer but that definitely works in regular javascript code.

Comment 75

[Priya]

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 ?

Comment 76

[Duncan Loveday]

Sorry, that's beyond what I know. I assume the typo above is not in the real code ?

Comment 77

[Priya]

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.

Comment 78

[Boris Zbarsky [:bzbarsky]]

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.

Comment 79

[Priya]

Boris,
Can you tell me the URL where you can help me ?

Comment 80

[Boris Zbarsky [:bzbarsky]]

http://groups.google.com/group/mozilla.dev.security/topics?lnk=srg

Comment 83

[ff]

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.

Comment 84

[Boris Zbarsky [:bzbarsky]]

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.

Comment 85

[Duncan Loveday]

> You mean Unix is half as secure as windows because of "root"?

No, because windows also has well known privileged accounts like localadmin

Comment 86

[Mark]

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

Comment 87

[Boris Zbarsky [:bzbarsky]]

> and send it to a PHP program

Whatever code has the permissions to do that also has the permissions to get the full path.