links to "file:" URLs within "http:" page don't work.

VERIFIED DUPLICATE of bug 40538

Status

()

Core
Networking
P3
major
VERIFIED DUPLICATE of bug 40538
17 years ago
16 years ago

People

(Reporter: Brad Garcia, Assigned: Gagan)

Tracking

({testcase})

Trunk
x86
Linux
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-3 i686; en-US; m17) Gecko/20000807
BuildID:    2000080712

Placing a link to a URL starting with "file:", within a page
that was accessed via a "http:" URL, does not work.  Clicking
on such a link results in no change to the display.

Reproducible: Always
Steps to Reproduce:
1. Create a simple webpage, like: "<a href="file:/home/http/html>my file</a>".
Call it file.html
2. Place this file somewhere on a webserver so that it can be accessed via a URL
starting with http:
3. Make sure the file/directory "/home/http/html" exists on the machine running
your browser
4. Load the webpage, and try clicking on the link to the file/directory.

Actual Results:  After clicking on the link, the display was NOT updated to show
the file/directory.

Expected Results:  Mozilla should have displayed the file/directory given by the
URL.

I gave this a severity of Major, since a major feature of a web browser is the
ability to follow hyperlinks.

Comment 1

17 years ago
Try a <A href="file:///home/http/html">my file</A>.

The file:/<path>/<file> don't appear to work. Dunno if thats a bug or not though.
(Reporter)

Comment 2

17 years ago
Same bug when testing Gregory's suggestion.  Gregory said that "file:/path/file"
doesn't work for him - I did not see that problem.

The file URLs work fine in Mozilla if you either type the url in the navigation
field, in the "Open Web Location" dialog, or if you click on it from a page
whose URL itself starts with "file:" (whether with one slash or three).  The
only time it doesn't appear to work is from pages with "http:" URLs.
Keywords: correctness, testcase

Comment 3

17 years ago
Created attachment 12560 [details]
testcase for 47988

Comment 4

17 years ago
I searched bugzilla and can't find a dupe of this so i am marking as new
2000080808
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 5

17 years ago
CC'ing myself and Adding one little note: The bug is only present if you dont
try to open the link in the same window. Oh and finishing my system info. Sorry
for not including this stuff in my last comment.
2000080808-M18/Linux/i386
Redhat 6.9.5 (Pinstripe)
kernel 2.2.16

Comment 6

17 years ago
over to Networking
Assignee: asa → gagan
Component: Browser-General → Networking
QA Contact: doronr → tever

Comment 7

17 years ago
cc andreas, this is a dup I think

Comment 8

17 years ago
I guess this url is caught by the nsScriptSecurityManager. There may be a pref
to allow file access from http. I will investigate a little bit.

Comment 9

17 years ago
Yes, it's the ScriptSecurityManager that stops the uri and that is no bug. It's
a security feature. Disabling the pref "security.checkloaduri" from all.js
should allow you to load the file URI if you really want to do such a bad thing.
Marking INVALID.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → INVALID
(Reporter)

Comment 10

17 years ago
If this is a security feature, then it is very broken.  If I "right click" on
the link instead of "left click", then I *am* able to get to the new site.

Also, I think it is very bad behavior to refuse to follow a link without giving
some indication that there is a reason other than "the browser is broken".

Lastly, why is this a security issue?  Why shouldn't I be able to have some
foreign site direct me to a file on my local machine?  This should at least be
allowed by default for directories, plain text or html files (ie, anything that
doesn't execute, but is merely displayed).  I can think of many legitimate uses
for this.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---

Comment 11

17 years ago
i agree with Brad it is a very broken inconsistant "feature" and should be
removed or at least off by default

Comment 12

17 years ago
Agreed, it is inconsistent. cc-ing mstoltz for the security issue. What is the
intention here? How should it work?
Thanks for your input as to the inconsistencies. However, inconsistencies are not 
a justification for removing this security feature. I realize this security check 
(nsScriptSecurityManager::CheckLoadURI) is not called everywhere it should be 
(it's not currently called for IMG tags, for example) and it looks like right-
clicking a link takes a different code path which doesn't have the check. I'm 
going to make this consistent by adding the check everywhere it's needed. 

The reason this is a security issue is that it facilitates exploits. Although web 
scripts are denied access to the content of pages coming from other sites, even 
being able to load those pages in a window can allow some malicious behavior. For 
example, accessing a user's prefs.js file (easy to find if the user is using the 
default profile) inside a SCRIPT tag causes the prefs file to be executed as 
Javascript, which allows stealing your email settings, among other things. That's 
just one example. With some types of tags (such as STYLE), pointing at a local 
URL allows an attqacker to determine whether a local file exists at a particular 
location. In general, it's a bad idea. This "feature" of being able to point at 
local files has led to a bunch of exploits in IE. Brad, the 'very bad behavior' 
is on the part of sites which attempt to make use of your local drive. 

  I realize that this is a tradeoff between security and functionality. Any 
concrete data (rather than opinions) which you can give me on the necessity of 
allowing local files to be loaded by remote content would be very helpful. Are 
there popular, large-scale, 'top-100' sites which depend on this behavior? Are 
there corporate users who need it, and for whom setting "security.checkloaduri" 
to bypass this restriction is not an option? Am I overstating the security 
vulnerability here? 


*** This bug has been marked as a duplicate of 40538 ***
Status: REOPENED → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → DUPLICATE

Comment 15

17 years ago
Verified dupe.
Status: RESOLVED → VERIFIED

Comment 16

16 years ago
Brad, a do you mean "Open Link in New Window?" That's the rough equivalent of
opening a new window, typing in the link, and hitting return.

I don't think there is any security risk there, based on Mitchell's comments, so
the security handling would be different, and consistent with the underlying
problem.
I believe there is a security risk in "Open in New Window," roughly the same as
clicking on a file: link. There's no reason I see why the same security check
should not apply to both.

Comment 18

16 years ago
I was wrong about a previous comment, Referer is inherited, but it still
wouldn't go anywhere. What happens in a new window that would be bad?
As an example, on Unix systems, clicking a link like
<A HREF="file:///dev/zero"> will cause the browser to start writing an
infinitely large file of zeros. There are similar problems on Windows.

As another example, pointing an IMG tag at a file:// URL allows an attacker to
determine if a file exists at a given location on the user's disk (if the file
doesn't exist, the image will have zero size).

If you or your company want to be able to use file:// links from http:// pages,
set the pref "security.checkloaduri" to false.

Comment 20

16 years ago
I understand those risks, but are they in any way releated to "Open Link in New
Window?" To my knowledge, we just take the link and put it a new window. Are
there javascript events that get involved with this?
Choosing "Open Link in New Window" is equivalent to just clicking on the link,
securitywise. The security issues described above stem from the browser opening
and reading an arbitrary local file, which is what happens when you "open in new
window," just the same as clicking a link normally. The problem doesn't
necessarily involve javascript.
You need to log in before you can comment on or make changes to this bug.