If you have a file:/// url in a web page it doesn't get downloaded however it works fine if the original page was on the local filesystem. Given the file: <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN"> <html> <body> <a href="file:///tmp/">file:///tmp/</a> </body> </html> It works fine on the local filesystem but put it up on a web server and it never downloads the content.
Adding people that might know more than I.
This is the correct behavior. A page loaded from the web should not be allowed to load pages from the local filesystem. Among other things, this allows an attacker to see if a specific local file exists. IE allows this behavior, and it has led to several vulnerabilities recently. (Notably, using IE to read someone's Netscape prefs.js file). Do you have code that depends on this behavior? I'm reassigning this to me, and if I don't hear any objections, I'm going to mark this INVALID.
Assignee: gagan → mstoltz
See this url in NS4. http://feed.0xdeadbeef.com/~blizzard/test.html How is this a vulnerability? Are you worried about someone doing something across frames or something?
See bug 16858 and recent IE exploit involving reading prefs.js file. Opening arbitrary file: URL's facilitates the sorts of problems IE is prone to lately...if someone can cause a file to be downloaded to your machine (in a cache file, or by having the user consent to download it to a known directory), and the downloaded file contains JS, then referencing it via a file: URL on a hostile web page would cause the JS to be run, and since it's coming from the local drive, it would run with privileges. I can see this leading to 'love bug' type scenarios. At the very least, it gives an attacker information about your local machine which should not be available.
I save html files to my hard disk often, so I don't see this as a complete fix for the security issue.
Ok, I can see how you have security concerns. It doesn't change the fact that as someone who is using mozilla in an embedding context I need to be able to handle file:// urls with another viewer than Mozilla. So, how do I find out when someone requests one? It never seems to make it to the nsIWebBrowser code.
Chris, I'm not clear on what you need. Can you give me an example?
Status: NEW → ASSIGNED
Adding a hidden preference for turning this security check off. Nominating nsbeta2.
Putting on [nsbeta2-] radar. Will not hold beta 2 for this. ramiro could land pref via mozilla...see brendan/waterson. If you can give us a top100 site, PDT would make [nsbeta2+]
Whiteboard: Fix in hand → [nsbeta2-] Fix in hand
Pref is checked in. I'm leaving this bug open as a placeholder for URL loading security issues which still need to be worked out. THis code is not in its final form yet, and the behavior of this pref needs to be tested after the code is finished.
Whiteboard: [nsbeta2-] Fix in hand → [nsbeta2-]
*** Bug 47988 has been marked as a duplicate of this bug. ***
The 'very bad behavior' quote is out of context. I was referring to the fact that Mozilla presents a link to the user, and when the user clicks on it, absolutely nothing happens. Mozilla should give some indication that the hyperlink was blocked due to security concerns. Perhaps this should be a filed as separate bug? Is there any way to differentiate between loading a local file as a "top-level" document, and loading it as part of another document? Thus, the only time one could access a local file from a remote site would be directly through a hyperlink, while loading a file as a smaller part of a page would be denied. I don't have a 'top-100' site, but I do have a web server script that runs on our internal network that provides 'file:' links to various nfs-mounted directories. I'd hate to disable this protection on everyone's browser (opening them to attacks from outside sites) just to allow them to view these url's. That application is available here: http://public.perforce.com/cgi-bin/p4db/dtb.cgi?FSPC=guest/brad_garcia&HIDEDEL=NO
Depends on: 24739
Target Milestone: M17 → M18
You wouldn't be "opening them to attacks from outside sites." Allowing local file links doesn't directly open up any exploits that I'm aware of, it just makes the environment a bit less secure. Netscape browsers through the current 4.7, and most versions of IE, allow local file links, so you're not exposing yourself terribly by setting "security.checkloaduri" to false. People have asked me to allow this on a site-by-site basis, like our per-domain DOM security policy mechanism, but I haven't seen a huge demand for this. I'm marking this bug FUTURE so we can revisit this issue after NS6.0 ships.
Target Milestone: M18 → Future
Thanks for the explanation. There is still the issue of a user clicking on a link and nothing happening. This makes for a bad interface and confuses the user. I can see users complaining to web site operators (or the IT staff, for intranet servers like ours) that the links on a page are bad. Expecting every user to have "security.checkloaduri" set to false is not the solution to this problem. When set to true, mozilla should tell the user that it is choosing not to follow the link. If you'd like to keep this bug around with a Target of "Future" to track this bug from a security standpoint, then I think it would be good to open a new bug about the user interface issue with a more immediate Target. Does this sound reasonable to you?
*** Bug 54286 has been marked as a duplicate of this bug. ***
*** Bug 67200 has been marked as a duplicate of this bug. ***
*** Bug 69975 has been marked as a duplicate of this bug. ***
It might be good to include, as part of the error message, a hint about how to relax the restriction for a specific website.
Sure, if that were possible. But it isn't yet.
*** Bug 69546 has been marked as a duplicate of this bug. ***
Changing description to "[RFE] Need console message when CheckLoadURI fails."
Summary: file:// urls from downloaded content aren't downloaded → [RFE] Need console message when CheckLoadURI fails
Target Milestone: Future → mozilla0.9
*** Bug 74747 has been marked as a duplicate of this bug. ***
*** Bug 75577 has been marked as a duplicate of this bug. ***
Fix checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
x86 linux 2001-04-18-08 I'm not seeing any sort of message being generated. This bug does not appear to be fixed. Where is the message supposed to appear? What is the message supposed to look like? And why don't I have the choice to re-open this bug?
Brad, the message is mainly for web developers, not users. Web developers know where to look for error messages, and if they see the message, they'll stop using file:// links. Getting in the user's face with dialogs is bad, especially when the fault lies with the content author, not the user.
That's just silly. The people who really have the need to see the error message are the users!!! The developers will already know what's going on. A user will think that the link is bad, and complain to the webmaster. And in my particular case, we're talking about an internal website, were there is no security risk of having such a link. > Getting in the user's face with dialogs is bad No, having an expected action fail with no visible reason is bad. A message in the status bar is not "in the user's face", it's reasonable. More importantly, it's expected! An "about:security" page is more in-your-face, but is still better than simply "ignoring the click", from a user point of view. And it's equivalent to clicking on a "rotted" link and getting a 404 message on a new page.
VERIFIED: Win32, but not MacOS or LINUX. Does the the data: url provided act as a test case for all plats, or do I actually need to point to a real file in each OS? Changed summary to describe feature. If we need to debate this further, please start a thread in the netlib newsgroup, or file new bugs. I see two possible RFE's: domain based security and logging to the normal console.
*** Bug 89046 has been marked as a duplicate of this bug. ***
I have a real existing file in intranet and a collegue sent me a *MESSSAGE* with the file:/// link in it (see #89046) and it does not work in the news nightly from yesterday (Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.2+) Gecko/20010709)....on WinNT.
Upps. wrong prefs.js, sorry :-))) Close and forget ...
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago → 18 years ago
Resolution: --- → FIXED
*** Bug 89917 has been marked as a duplicate of this bug. ***
Bug 84128 is a request to report this error so end users can see it. I think we are getting enough dupes where we need to put this at the top of list of errors to be fixed.
Whiteboard: send post-fix dupes to bug 84128
*** Bug 91164 has been marked as a duplicate of this bug. ***
grabow: See Mitch's 2000-05-25 15:12 comments on this bug for why we disallow all links from http:// to file:/// by default.
RELNOTE: NS6.1 "File URLs will not be read if they are inside a network based (HTTP) document. To disable this feature, set "security.checkloadURI" to false in your prefs.js".
qa to me.
QA Contact: tever → benc
Component: Networking: File → Security: General
QA Contact: benc → bsharma
Verified on 2001-10-22-branch build on WinNT Loaded the test case locally and through the web server, the behavior is as expected.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.