Closed Bug 405630 Opened 17 years ago Closed 17 years ago

<input type="file"> .value doesn't show full path name any more

Categories

(Core :: Layout: Form Controls, defect)

Product:
Core
Component:
Layout: Form Controls
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: duncan.loveday, Unassigned)

References

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2pre) Gecko/2007112005 Minefield/3.0b2pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2pre) Gecko/2007112005 Minefield/3.0b2pre

On earlier versions, doing something like this

<input type="file" name="fileBrowser" size="125" onchange="alert(this.value);">

Would report a full path name that could then be opened and read using XPConnect. But now I only get the file name, not the directory path. Is that intentional ? What's the workaround ?

Reproducible: Always

Steps to Reproduce:
1. Open an HTML file along the lines of <html><body><input type="file" name="fileBrowser" size="125" onchange="alert(this.value);"></body></html>
2. Click "Browse", navigate to some file and click "open"
3.
Actual Results:  
The alert doesn't show the full path, only the file name.

Expected Results:  
Earlier versions would show the full path.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
> Would report a full path name that could then be opened and read using
> XPConnect.

If your script is privileged enough to use XPConnect, it still does.  Untrusted script doesn't get the path, however.
Boris, thanks I read the dupe and it is now sorted. It's just that I was reading the file name from the form before acquiring privileges.
(In reply to comment #2)
Whoops, sorry I didn't catch the XPConnect reference.
Erm, "invalid, by design" isn't quite the same as "duplicate of the thing that made the situation you don't like."
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Component: Form Manager → Layout: Form Controls
OS: Windows XP → All
Product: Firefox → Core
QA Contact: form.manager → layout.form-controls
Hardware: PC → All
Version: unspecified → Trunk
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago → 17 years ago
Resolution: --- → INVALID
Phil, yes I agree. This bug actually reports the opposite symptom of the one it was marked to duplicate. And yes, this bug is invalid given the security constraints.
This should be re-opened.  The bug that fixed it:

<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=143220">Bug 143220</a>

talks about the "security considerations" of making the path available without ever actually identifying those security considerations.  So this change breaks probably a good 100,000 web applications without any apparent careful thought behind it!
As a followup, there are clearly *privacy* concerns with making the path available, but I have yet to hear a valid *security* concern.  The privacy concern is, of course, is someone has an embarrassingly named or otherwise sensitive path.  I think the *file name is far more of a privacy concern than path*, however.  File names tend to be far more descriptive than path names, and they tend to just sit in the innocuous "My Documents" directory.  

To me, this all points to backing out the change.  It breaks much and solves little.
It reveals usernames, for one thing.  Combined with a weak password, a bug in Firefox, or the use of a browser that allows http URLs to reference file URLs, that could easily lead to security badness.  But I don't like your implication that privacy doesn't matter.

I'm changing the summary to differentiate this bug from bug 219470.
Blocks: 143220
Summary: Input type="file" doesn't return full path name any more → <input type="file"> value attribute doesn't show full path name any more
Summary: <input type="file"> value attribute doesn't show full path name any more → <input type="file"> .value doesn't show full path name any more
Thanks for taking the time to reply thoughtfully to this.  OK, you can get the user name.  The attack vectors from there are:

1) A weak password.  A web site owner could make a brute force attempt to log in to your machine.  Just to be clear, though, we're talking about web sites where you've already selected a file for upload.  So you're on sites you trust enough to upload files to them.

2) Browsers that allow HTTP URLs to reference file URLs.  Do any of these browsers exist?  The fact that FireFox isn't one of them appears to nullify this vector as far as I can tell.

I agree #1 is something to think about.  I haven't seen a single case of this exploit ever being an issue, though, and all other browsers allow the full path behavior.

I certainly didn't mean to discount privacy but rather to clarify whether this was a privacy bug, a security bug, or both.  

I'm a little up in the air on this bug now.  The thing is, I know this breaks existing web sites, but I don't know it's a legitimate, real-world exploit.




I don't think the change broke as many sites as you think it did.  Our change made us match Opera.  We only got one report of a public site breaking, and that site has already been fixed (bug 417715).  There were several reports of it breaking internal apps (this bug and dups), but not a whole lot, and most of them can be fixed easily since they were about to ask for privs anyway in order to read the file.

My primary aim in poking this bug was to get a single valid attack vector this solves -- to make sure the thinking behind this is clear and that we're not just blindly checking off bugs.  The revealing of user names satisfies that requirement. 

I think it's really hard to say how many sites it breaks, but in most cases the workaround should be fairly simple regardless.  For my site, the workaround is unfortunately using an Adobe AIR uploader because all I need is the path, and I'm never actually uploading the file anywhere.  I *think* that case is extremely rare, however, and I'll survive.

Thanks for your valuable time on this, Jesse. 
Adam, you can get the path using script - I'm doing it - the only thing this bug changes is that the script has to acquire privileges. Write to me directly at duncan.loveday@bt.com if you want me to send an example.
There should be switch to allow old behavior.  Major company sites are now imcompatible with v3. Site fixes are not anticipated per FEDEX website support. 

Steps to Reproduce:
1. https://printonline.fedexkinkos.com/StartNewJob.do
2. Browse
3. Add file to job list
Actual Results:  
Gives a bad file name error.

I certainly second the proposal to facilitate the old behavior, Michael, and the alerts the user is forced through when you request elevated privileges are unacceptable for the vast majority of sites (see Duncan's suggestion above).  The elevated privileges approach is an interesting workaround, but it's just scary for most users.
This happens in our entire product which uses Struts behind. The file upload forms do not work anymore, nor does the feature that uses this path to pass it to Java Web Start app. So to just put this in and expect that everyone who uses file input types that used to work spend the time to fix them without providing a workaround is a big problem. Even more so when IE and older versions of Firefox work.

We do not use any javascript to access the filed just a Java web app using struts and JSP and none of the file input types are populated. So I wonder what security do we break since this is the way the struts tags work and how exactly do we fix it ?
I'm posting to advocate re-opening this bug as legitimate on the basis that the DOM 2 HTML spec is being violated by the reported behavior.

The relevant clause describes the "value" attribute of the HTMLInputElement interface and is found here: http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-49531485

To summarize: for input elements of type "file" the value attribute is supposed to contain the current contents, ie. the entire path (if present), not just the file name.

The reported behavior breaks file upload applets (for example) that rely on HTML forms and the user agent for file picking.

While concern for privacy is laudable I think it is a bit overdone here as it was the user themselves that caused the path to be entered in the input element and it is displayed there.  Presumably their expectation is that, once submitted, that information will transit the 'net.
You must have missed seeing bug 143220 comment 23 and bz's reply.
"The current contents of the corresponding form control" is pretty vague, since there is no guarantee that a file upload control looks like a textbox (containing the entire path) with a button next to it.  In Safari, it just has a label showing the filename (not the path) next to the button.
(In reply to comment #27)
> You must have missed seeing bug 143220 comment 23 and bz's reply.

No, I saw that before I posted. There are a couple different points in that exchange; which one(s) do you feel pertain here?

(In reply to comment #28)
> "The current contents of the corresponding form control" is pretty vague, 

I will agree that it is vague but a charitable interpretation would favor the path over the name.

> since
> there is no guarantee that a file upload control looks like a textbox
> (containing the entire path) with a button next to it.  In Safari, it just has
> a label showing the filename (not the path) next to the button.

The point of mentioning that related to user expectations of privacy, not requirements on the user agent.  For what it's worth, <file input>.value on recent Safari on win/xp returns the path.


I want to quickly summarize the reasons for not sending the path, as I think they're highly suspect.

1) Privacy.  The path to the file could reveal some embarrassing or otherwise private information about the user's directory structure.  To be honest, I think this is ridiculous.  Who out there is creating directories with such revealing names?  Again, the name of the file is far more of a privacy concern, as it usually reveals far more.  What about the contents of the file itself?  People are uploading amateur porn for crying out loud.  Is the path to the porn really the private part?

2) Security.  The path can reveal things like the user name (/Users/fisk/...).  While I agree this raises a red flag, can anyone pinpoint how this could ever be used in an attack, let alone an attack that's ever occurred?  What's more, these are sites you're uploading files to.  Most of those sites require you to have a user name and password.  How often are those user names and passwords identical to the user name and password on your machine?  I would guess shockingly often.  Has even this ever been used in an attack, cases where the site actually knows your user name and password a good percentage of the time?  If so, how?  We need to flesh out these attack vectors much more thoroughly. 

I also advocate re-opening this bug.

-Adam Fisk
Here's a follow-up to Andrew's comment 26, 

"The reported behavior breaks file upload applets (for example) that rely on
HTML forms and the user agent for file picking."

I want to use the file picker in a form to choose an XML file.  My HTML document consists of a form for several selection criteria, a rule line and a results area.  After I select a datafile from one of several locations and click the display button, the XML file is transformed with Sarissa, and stylesheet formatting is applied below the rule line.  This keeps the selection criteria and the results on the same page.

My transformation script needs to know the full path of the datafile.  This worked in FF2, but does not work in FF3 (or Opera 9.5, also a bug report.)  A simple demonstration of the missing path information is the file I attached to duplicate bug report 444255.
Look, we know what the use cases here are.  The point is that we feel that exposing this information to untrusted scripts is dangerous for our users.

If you really feel the user should trust you with this information, you can attempt to request expanded privileges and read the full filename.  The user is free to deny said privileges, of course.
I think this is a little misleading, Boris.  Signing a JavaScript jar is far beyond the abilities of most web developers.  You have to download the source and compile it, first off.  Then you have to go through the signing process.  Most web developers don't know how to compile code. Even if they do, they have to make sure they have the proper versions of gcc, make, etc -- a huge burden.

Without the signed script, I believe you have to enable signed.applets.codebase_principal_support.  That's just way too much to ask of your users in any practical scenario.  

Am I missing something here, or is requesting expanded privileges not a realistic solution in the vast majority of cases?  

I also still think "dangerous" is too vague to justify this significant a change.
What exactly is misleading?

> Signing a JavaScript jar is far beyond the abilities of most web developers.

Yes.

> Without the signed script, I believe you have to enable [pref name]

Yes.

> Am I missing something here, or is requesting expanded privileges not a
> realistic solution in the vast majority of cases?  

You're not missing anything.  It's not meant to be done lightly.

This idea is bordering on lunacy but what if you could return the full path but in a form that couldn't ever be posted to the server ? That would keep the people who only want to use it for local scripting happy (no good for those who need to post the data).

Example: Have a data type like "nsUnpostableValue" or something that can be used like a normal string in scripts but never sent to the server. Make sure operations like string assignment, concatenation etc turn the result into an unpostable value if any one of the inputs are unpostable.
The idea of using data tainting instead of the same-origin mechanism that browsers use now has been suggested, indeed; there should be a presentation by Brendan on it floating around somewhere.

It'd require a pretty wholesale redesign of the security setup, and wouldn't help most of the duplicates of this bug, which do in fact do things that are equivalent to sending the data to the server, as far as I can tell.
There's a fairly painless workaround for this I can't believe I didn't think of earlier: a hidden applet.  The applet allows you to "play in a different [security] sandbox", and its FileDialog will give you the full path to the file.  Loading is also quick with newer JVMs.  

The applet code is here:
http://svn.littleshoot.org/svn/littleshoot/trunk/client/applet/src/main/java/LittleShootApplet.java

Class file here:
http://svn.littleshoot.org/svn/littleshoot/trunk/server/static/build/src/main/webapp/LittleShootApplet.class


With an applet with name="LittleShootApplet" loaded, you can run something like:

document.LittleShootApplet.fileDialog("onFileDialogFile");

function onFileDialogFile(path)
{
// Converts from a Java string to a JS string.
var javaScriptPath = path + "";
alert (javaScriptPath);
}

The alert will show you the path.  

This basically gets you back to the FF2 behavior (or any other browser minus Opera) with almost imperceptible differences from the user's perspective.

Hope that helps.

A couple people have asked me about the above applet solution, and I forgot to mention this method is completely bypassing the file input HTML element.  So, you just respond directly to an onclick of a button, for example.  If you need the file input text box and all, you need to manually recreate it using a text field or whatever.  One advantage here is it enables you to completely customize a "file input" element -- the button, field, everything.

Apologies to Jesse and Boris for bypassing things like this.  As frustrated as I was getting with this one, you guys are both clearly excellent FireFox stewards and models for open source development generally.  If there's some more concrete security hole, I'd even be happy to advocate to Sun they close it in the applet as well.  I just really needed that darn path!
> If you really feel the user should trust you with this information, you can
> attempt to request expanded privileges and read the full filename.  The user is
> free to deny said privileges, of course.

Well, that don't work. I am unable to access JS functions from a signed Javascript on a remote server since FF3.
(In reply to Boris Zbarsky [:bz] (still a bit busy) from comment #35)
> Look, we know what the use cases here are.  The point is that we feel that
> exposing this information to untrusted scripts is dangerous for our users.
> 
> If you really feel the user should trust you with this information, you can
> attempt to request expanded privileges and read the full filename.  The user
> is free to deny said privileges, of course.

See https://bugzilla.mozilla.org/show_bug.cgi?id=1311823
You need to log in before you can comment on or make changes to this bug.