Open Bug 84128 Opened 23 years ago Updated 3 years ago

Need user-visible message when CheckLoadURI fails (eg, for links to file: urls)

Categories

(SeaMonkey :: UI Design, defect)

Product:
SeaMonkey
Component:
UI Design
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

People

(Reporter: garsh, Unassigned)

References

(
URL
)

Details

(Keywords: helpwanted, relnote, Whiteboard: This is NOT about enabling file: URLs but about a clear error message.)

Attachments

(7 files, 1 obsolete file)

LAN link not supported popup
14.81 KB, image/jpeg
Details
Mozilla 1.3
48.65 KB, image/jpeg
Details
This is a bogus attachment -- how do you submit a comment on a bug without a file attachment?
4 bytes, text/plain
Details
Dialog of proposed patch v0.2
12.84 KB, image/jpeg
Details
Patch v0.3 - dialog should only appear from a user generated event
9.27 KB, patch
Details | Diff | Splinter Review
Patch
2.63 KB, patch
Details | Diff | Splinter Review
Patch v0.4 - attempt at event dispatching
19.93 KB, patch
Details | Diff | Splinter Review
2001-06-03-21 linux x86, but should be applicable on any platform. When clicking on a 'file:' link on a page that does not have a 'file:' URL itself, the new page does not get loaded. Currently, the following message is printed in the Javascript console: The link to file:///... was blocked by the security manager. Remote content may not link to local content. However, normal users are not going to open the javascript console to look for error messages. *Especially* when the pages in question don't even contain javascript! (aside - why is it called a javascript console? Shouldn't it be called a "debugging" console?) When a user clicks on such a link, the user must be told why the action failed, otherwise the user is confused. I would suggest one of the following remedies: 1. Print a message in the status bar at the bottom of the page. But some users might miss this, since the status bar seems to be pretty useless anymore for giving accurate status. 2. Load a new page that gives the error message. This is less likely to be missed by the user. It's similar to clicking on a rotted link and getting a "404" page. This could also give more detailed information about the problem, and ways to work around it. This is related to bug 40538. Also, a solution to bug 47128 might also prove to be a solution to this problem.
Over to user interface design. We need a spec for the UI here.
Assignee: dougt → mpt
Status: UNCONFIRMED → NEW
Component: Networking: File → User Interface Design
Ever confirmed: true
OS: Linux → All
QA Contact: tever → zach
Hardware: PC → All
The error message isn't meant for end users, it's meant for developers. In that sense, it's kind of like an uncaught JS exception, which also shows up only in the JS console. If site developers see this message, they should correct their pages so the error doesn't happen and then it need never be a problem for the user.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WONTFIX
> The error message isn't meant for end users, it's meant for developers. Of course. But the point of this bug report is that the users need a message too. > In that sense, it's kind of like an uncaught JS exception, which also > shows up only in the JS console. But this doesn't help the user figure out what happened. > If site developers see this message, they should correct their > pages so the error doesn't happen and then it need never be a > problem for the user. Wrong. This does NOT mean that there is something wrong with a site. This is a security feature that mozilla implements that causes it to simply ignore the user when the user clicks on a perfectly-legitimate hyperlink. Neither Netscape nor Internet Explorer implement this restriction. I understand the rationale for having this feature, but a user should be given an indication of why the browser is ignoring her when she clicks on a hyperlink. The current behavior is bad.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
A link to local content is not "perfectly legitimate." I've given my .02 on this issue, but if someone wants to implement yet another user dialog, that's fine, I won't object.
To clarify, this is would be "fix" to what some people consider is the incorrect behavior in bug 40538.
I think fixing bug 47128 is the best way to fix this bug. (I'd mark this bug as a dependency, not a dup, in case there's a problem with the CheckLoadURI message not showing up because it's shown on the JS console as a message rather than an error or warning.)
Marking as dependent on 47128
Depends on: 47128
URL: file:///
No longer depends on: 47128
No, bug 47128 is for script errors, and (as Brad already said) this isn't a script error. It's a you-can't-go-there error. We don't consider an easily missable status bar message to be sufficient for any other you-can't-go-there errors, and it's not sufficient for this error either. Ideally, this is bug 28586 material; but that bug doesn't look like it'll be fixed any time soon. An alert would be better than nothing (which is what we effectively have now), *provided that* the page author including half a dozen <img src="file:///whatever">s didn't result in half a dozen alerts. So, what's the story here? Can we have different treatement for <img src="file:///whatever"> than we do for <a href="file:///bar">hum</a>? If not, why not?
*** Bug 88727 has been marked as a duplicate of this bug. ***
*** Bug 90902 has been marked as a duplicate of this bug. ***
+mostfreq - starting to get more dupes, which are lost to networking:file.
Keywords: mostfreq
*** Bug 91164 has been marked as a duplicate of this bug. ***
*** Bug 93761 has been marked as a duplicate of this bug. ***
*** Bug 99036 has been marked as a duplicate of this bug. ***
I've got internal pages which are compilations of links to local content. If some feel this is a security problem, pop up a confirmation dialog to make sure the user understands. Totally ruling this out is anoying.
*** Bug 100485 has been marked as a duplicate of this bug. ***
*** Bug 101146 has been marked as a duplicate of this bug. ***
I fail to see how this is a security issue. If I choose to click on a link that goes to my local site, who is this going to hurt, and how? The referring page's server can't do anything with this, nor even be aware that the user has selected the link. Let's even assume that the malicious web site has placed a file on my local machine (somehow), and tricks me into accessing it through a file: link. What damage could mozilla do by loading this file? In any case, this needs to be some sort of user setting. There are a myriad of useful things one could do with file links. (I'm writing here because I'm unable to do one of them...)
P.S. Note that the handling of file: redirects is also poor--partially parsed server redirection html.
> The referring page's server can't do anything with this Example. Site http://foo has an <img src="file://whatever"> link. It detects that the image load succeeds (the onload event for the image is fired). This tells that site that you have a file with that name on your hard drive. The JS sets a cookie to that effect. > What damage could mozilla do by loading this file? Depends on whether you have a helper set up to automatically handle files of that type and how buggy that helper is... In the worst case, there are not-too-difficult scenarios that allow an attacker to execute arbitrary code on your machine this way: 1) Place some code somewhere (eg a browser cache) 2) Point to that file with a file:// url 3) Exploit that fact that file:// urls have a lot more rights than http:// urls > In any case, this needs to be some sort of user setting. It is. :) user_pref("security.checkloaduri", false); will disable this check.
kurt: lets get a new bug on the redirect issue.
Blocks: 101207
Redirect bug is bug 101207.
RELNOTE for 0.9.4: use text from bug 40538 + "Currently, the errors are visible only in the javascript console."
Keywords: relnote
I think I should put up a documentation page explaining why this restriction is there, and how to turn it off. I seem to be getting the same complaints about this over and over, and explaining it over and over.
I think creating the document explaining the restriction is a good idea. Your best bet would be to have mozilla pop up a page containing this document whenever a user attempts to click on one of these restricted links. Then this bug could be closed. :^)
I see all sorts of neat examples of how local file URLs can be exploited in image tags, etc. What I would like to know is, if a web page contains a simple hyperlink, with no javascript event handlers, like so: <a href="file:///usr/share/doc">Local Linux Documentation</a> And a user clicks on it, what security issues are there? And if there aren't any, then why can't exceptions be made to the security restrictions for such safe uses?
*** Bug 101207 has been marked as a duplicate of this bug. ***
Brad, look at bug 101207. I mentioned some relevant security concerns there. I'm going to write them all up on a webpage soon so that people can either tell me I'm being too paranoid or stop pestering me about this issue.
I can understand why allowing a plain hyperlink to things like file:///dev/* are bad. But this is different from the security issue, for two reasons: 1) If the user clicks on this plain-old hyperlink, there is no data being sent back to any server, so there is no security concern. 2) These links are JUST AS BAD if the page containing them is a "file:" URL as they are when the page is an "http:" URL. So these sorts of links should be rejected regardless of the page from which they've come. Currently, they are not. They probably should be.
Mitchell, in general response, and specifically to your last comment in bug 101207, I commend you for your attention to these security concerns. I agree with them--they are all indeed valid. Please try not to be offended (or exasperated) when others fail to anticpate them. The question is, however, to what extent mozilla should go in addressing wider security concerns. For example, you mention how file:///C:/con/con will crash some Microsoft systems, and how file:///dev/... on unix systems could theoretically cause damage. For the latter, I question this, at least on Linux and Solaris. For both, though, I would suggest that the stringent CheckLoadURI policy would not be sufficient to inhibit such activity. One could receive a malicious html page in email "save this to disk...", etc. In this case, the only safe thing would be to disable file:// entirely... In essence, I would argue that such exploits are the fallacy of the OS, not the browser, which merely acts as a conduit. I don't think Mozilla need be a tool to correct the problems of the OS. This would be tantamount to expecting sendmail to scan for virii, hate mail, etc... In any case, the reason, which I'm sure you're aware of, for the numerous bug reports on this issue, is that the user is not expecting any such security action (other browsers don't block file://), no information is presented when this happens, and no preferences setting addresses this. I don't think putting up a web page describing the situation will suffice. Thus, I suggest that mozilla be augmented to pop up a dialog when such an attempt is made, stating, "This page is attempting to access a local file which is potentially dangerous. Do you wish to allow access to file://...?" With buttong stating "Yes, just this one time", "Yes, and for all future attempts", "Not this time", and "No never". In this manner the situation is clear, as are the options, which allow for a permanence. This should effectively deal with everybody's concerns.
I think Kurt's solution will make us all happy. The dialog could even have a 'show details' button with further clarifications why file:// is potentially dangerous. Although, for the 'javascript switched on' case, the warning should be a bit stronger.
+ nsenterprise - if you read all the dupes, you can see this affects corporate users b/c of frontpage and corporate groups that like to publish file URLs over HTTP index files.
Keywords: nsenterprise
It was for enterprises that I added the "security.checkloaduri" pref. Enterprises can turn the check off. I'm re-evaluating this whole issue and I will post a more detailed response in a few days. In the meantime, read my lips - no new dialogs. :)
See also bug 86486, "URL: Invalid protocols in HREF links fail silently".
Summary: Need user-visible message when CheckLoadURI fails → Need user-visible message when CheckLoadURI fails (eg, for links to file: urls)
marking nsenterprise-; will be reevaluated for nsenterprise in future release.
Keywords: nsenterprise-
*** Bug 104842 has been marked as a duplicate of this bug. ***
*** Bug 108490 has been marked as a duplicate of this bug. ***
*** Bug 117006 has been marked as a duplicate of this bug. ***
Gents, I understand the concern for security, but to disable the ability to view local files from Mozilla makes it feel like a broken browser straight out of the box. Half the links on any decent intranet page won't work if local file links simply do nothing. I think viewing of local files should be made a part of the default feature set ASAP!!! If you want to add an option in Security to turn this off or post a warning that is fine, but as it stands I have to load Netscape to view internal documents under Linux and that sucks... I'm very happy with Mozilla in everyway except this bug. I know this has got to be easy to fix why has nothing been done for 6 months?!?!
The popup error message is clear, but the wording could still be tweaked, especially for Mozilla. I've attached a screen shot of the dialog. The message is "Netscape does not support linking directly to files on the LAN. You'll need to use IE or File Explorer to navigate."
"You'll need to use IE or File Explorer to navigate." Um... not too helpful if you're on something other than Windows. Ever hear of something called "Linux" or "VMS" or "Unix"?
Also, my "file://" file isn't on any "LAN," it's on my local hard drive... I suggest: "Security violation: links to local files currently disabled."
I think we really want the users to stay with Mozilla. So a hint which prefs variable to set to to enable this unsecure feature (with a short explanation) would be very helpful. I don't think we have to redirect the users to another browser ! See comment #43 : "Security violation: links to local files currently disabled. To enable this feature, you can set the variable security.checkloadURI in your prefs.js. But be aware that you open a possible security hole, esp. in connection with javascript!"
I think we should have more of these 'more info' buttons like we do in prefs. Then people can customize the the detailed message w/ a URL. mpt: any suggetsions for some default text?
*** Bug 126183 has been marked as a duplicate of this bug. ***
I don't know if this is relevant, but when someone posts a news message using Outlook Stationery it includes a <base href="file:..."> URL which fazes MailNews.
This should IMHO be fixed via the mechanism for bug 28586.
Depends on: errorpages
*** Bug 126935 has been marked as a duplicate of this bug. ***
I added the user_pref("security.checkloaduri", false); in my prefs.ini to see if this fixes my problem described in bug 126935. It did not. I still can not go from secure pages to a file:// URL. I also put an image in the secure page that accesses a JPG on my local hard drive. This worked! IMO the effect of the setting should be exactly the opposite. Under no circumstances I want a external web page to be able to access files on my PC. The security holes this creates have been discussed above, and I fully agree to this. But I want to be able to jump to file:// URL's from secure pages. A optional warning dialog would be usefull. If this does not work Mozilla is virtually useless in corporate environments. In a corporate environment, users also surf the web, so the security loophole can not be accepted (except for normal links as mentioned above). I also think that a warning dialog could pop up if a non-file: page uses file: in any way - probably it tries to use a security hole.
To make matters worse - the image mentioned in my last posting can also be accessed with user_pref("security.checkloaduri", true); So what we got is all the security loopholes but we still can not use file:// URL's.
That would be bug 69070
*** Bug 127987 has been marked as a duplicate of this bug. ***
Blocks: file://
*** Bug 131119 has been marked as a duplicate of this bug. ***
*** Bug 138769 has been marked as a duplicate of this bug. ***
*** Bug 142462 has been marked as a duplicate of this bug. ***
This is about using BASE HREF tags in local HTML docs, which I do very often. Suppose I include the following tag in a local file: <BASE HREF="SOME_URL">. Mozilla honors clicks on file: links when SOME_URL is also a file: URL; but ignores clicks on file: links when SOME_URL is http:, or other. It is nice that Mozilla tries to treat a local document with a specified base URL as though the document actually lives there. But ignoring my clicks on file: links, just like they would be ignored if the page actually _were_ remote, might be too much (might not be, I am not sure). But wait, there's more: With <BASE HREF="SOME_REMOTE_URL"> Mozilla ignores my clicks on file: links (to open them in the same tab/window). But Mozilla currently _allows_ file: links in such documents to be opened in _new_ tabs or _new_ windows (right click, "Open in New Tab/Window"). Mozilla does _not_ allow this for genuine remote documents (that is, for documents that actually reside somewhere other than file:///something, Mozilla ignores my requests to open file: links in a new tab or new window). At the very least, IMHO, this second issue (an inconsistency) should be fixed, and maybe this bug is not the place to discuss it. But following either of the following two humble suggestions would address both of these issues: -Either- (a) Even if a document includes a base href, we still know whether the document itself is local or not. Therefore, in the case of local pages that use the base tag with a remote URL for the HREF attribute (<BASE HREF="SOME_REMOTE_URL">), Mozilla should _honor_ requests to open file: links, whether in the current window/tab, or in new window/tab. -Or- (b) When a local document specifies a BASE HREF, it should be strictly applied. Therefore, in the case of local pages that use the base tag with a remote URL for the HREF attribute (<BASE HREF="SOME_REMOTE_URL">), Mozilla should _ignore_ requests to open file: links, whether in the current window/tab, or in new window/tab. The more I learn, the more I favor option (b), because (1) (as in Brad's Comment 29, reason #2), the file: protocol can be dangerous on its own, regardless of whether the file: resources are included in remote _or_ local documents; and (2) when the nice set of preferences and warnings gets implemented ( :) ) this will cause local documents with remote base href's to be treated in all ways just like actual remote documents. (This is why Kurt's Comment 30 Preferences seem to be best for _all_ cases, but I'm just trying to make sure that my BASE tag cases are considered also). Re: Andreas' Comment 50 and Comment 51 - For https: documents that have non-https: resources to be included (even http:), I think what IE6 does is to give the user a warning pop-up window that says something along the lines of "This document contains both secure and unsecure parts. Would you like to load the unsecure parts as well?" This goes along with the suggestion for adding a preference for these kinds of issues, though. Hopefully the suggestions for preferences can be applied both to including mixed permission level resources in the same document as well as to honoring/ignoring requests for file: links to be opened. They sound like related issues to me.
In the second part of my comment, "But wait, there's more: With <BASE HREF="SOME_REMOTE_URL">...", I mean "With <BASE HREF="SOME_REMOTE_URL"> in local documents..." Kind of an important thing to omit.
Andreas: please see bug 93787. David: I do not qa this feature, but I have read a lot of the bugs, and I don't think anyone has explored this BASE issue. Please create a new bug. This bug is supposed to be ONLY about the lack of a visible error when checkloadURI fires and cuts off a link click.
I just ran into this bug, and this really sounds like a case where security is hindering perfectly legitimate user actions. I think this should be fixed, since users expect simply this to work (and as mentioned, it does in IE and NS). Just telling them this is not supported because Mozilla thinks it is better for the end-user is a good way of getting rid of Mozilla users. I do agree that this can be a security issue, and that it should be configurable. However, the current prefs.js setting has two problems: - if I have to tell our users that they need to mess with their Mozilla prefs.js file, they simply take another browser. And if they do modify prefs.js, it is the IS department that will have to correct the mistakes. - the prefs.js setting is global, so if I set security.checkloaduri to false, our corporate users can access the file:// urls that point to our intranet, but they are also vulnerable for exploits when they surf the internet. I may miss something, but why can't this work like IE does, i.e. never open file:// urls automatically but ask the user if he wants to open or save the file? The user is informed, and has a choice (i.e. opening corporate intranet files, but cancelling other, potentially dangerous file urls). Alternatively, it could be linked to the presence of a http proxy. If there's a http(s) proxy configured one could assume that html pages that have _NOT_ been loaded through the proxy are on the local net, and that file:// urls on such pages are safe. This might work for a lot of corporate users, but does not solve it for everybody... In the end, something like IEs security zones does feel like a decent solution for this problem...
*** Bug 153386 has been marked as a duplicate of this bug. ***
I would like to reiterate what Gert-Jan Vons just said "... this really sounds like a case where security is hindering perfectly legitimate user actions." I was getting ready to recommend Mozilla as one of our intranet acceptable browsers, however I cannot do this as long as file:// links within web pages are disabled by default, or a security risk if enabled. I understand not knowing how to address this until the underlying issues are resolved (eg. security zones) but it really is *bad* that Mozilla is *silent* about it. There needs to be some kind of message or people just think Mozilla is broken. It took me the better part of an hour to wade through the bug database before finding out that broken file:// links are by design. Most people will not put themselves through that effort (witness the high number of duplicate and related bug reports). I personally will keep using Mozilla until somebody closes the middle-click bug <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=148418">148418</a> (so please don't), at which point I will reluctantly go back to IE.
Can we get this soon? The majority of new bug activity in Networking:file is whining about the lack of user feedback on this feature. I've even had to create a bug that is left in file to mop up the duplicates, because the current behavior is so irrational and the causative components are so far of the beaten path nobody that doesn't already understand this behavior knows where to go in bugzilla. +asa & timeless: This should have been release noted, but is not in the 1.0 notes. Can we add an entry please?
Please display an error message when one is trying to click on "file://". I discussed this problem under other circumstances as bug 107540 until someone mentioned this security feature and how to stop this. A hint would have saved several days of trying and testing because the system did not show up why it ignored file: ´s. Popup a message and offer the user the possibility to decide by himself if he thinks this is a severe problem. On our intranet we have hundreds of DOC files that should be read by other departments and they are all linked as "file:" on dozens of HTML pages. Do you imagine what the reaction was when neither NETSCAPE nor MOZILLA would display these pages? I nearly changed over to the IE but thanks to the discussion I will stay with MOZILLA.
I support the suggestion to let the user decide if he wants to open the file: link.
This bug seems to be getting more attention now that Mozilla 1.0 has been released. We're already up to 14 votes. This bug describes the minimum amount of work necessary - that is, displaying an error message. There are other bugs dealing with allowing the link to succeed. The correct fix (see bug 47988 and bug 40538 for discussion) is to realize that accessing a file: URL from an http: URL is NOT ALWAYS a security issue. If there are no javascript hooks on the parent page that would allow the web server to detect a file: access, then why shouldn't we simply allow the access to succeed? This will probably solve the problem in the most desirable way for all of the intranet cases described. Please also realize that the developer who normally works in this area has no desire to fix this bug. So if we have any hope of getting this fixed, somebody else will probably have to do it, unless we find someone with great powers of persuasion. I've found that I am not that person. :^) Personally, I've about given up. My links don't work, having to edit a text file to turn off this security feature seems bogus, having to turn off a security feature at all seems bogus, expecting all other users of the intranet to turn it off is bogus, displaying the error message in the javascript console (even though there is no javascript involved here) is bogus, and NOT showing an error message in the browser proper is bogus.
One of the problems with the visiblity of this bug is that the duplicates have been scattered among three bugs: 1- The "ISSUE" bug I created in File, to try to keep the duplicate reports to a minimum. 2- The original feature bug had many "no error" bug duped into it. 3- This bug. So, on the mostfreq report, it shows up in the lower third. Right now, there are 21 dupes, so it is in the middle of the pack. If someone really feels strongly about this, they could correct the duplicate count by finding the misduplicated bugs and duplicating them to this bug. If you want to volunteer for this duty, contact me by email (please don't run off and start changing a lot of bugs unless you know exactly what you are doing). (At some point, I will do that in File because this is needlessly bloating my component).
Benjamin, Perhaps it would be best then to file one bug to handle all aspects of this, and then dup *all* of the bugs to that one bug? Then we could leave it up to a willing-and-able developer to choose whether they wish to fix this by displaying an error message or by allowing the file access. And certainly, the summary for this bug is pretty cryptic (that's my fault, sorry). Any all-encompassing bug should probably have a simple synopsis like "file URL's fail to open", so that more users can find it. Opinions? Good idea? Bad idea?
*** Bug 157885 has been marked as a duplicate of this bug. ***
I can see where bug 157885 is similar to this, but there is no mention of file:// links within mailnews that I can see of in any comments. People need to be aware it affects mailnews too especially when people have access to shared drives and want to save having multiple copies of documents/spreadsheets by linking to it on a shared area.
The creation of "issue" bugs is not a common practice in bugzilla, possibly done only in Networking:*. The MailNews bugs are managed by a separate group.
*** Bug 161468 has been marked as a duplicate of this bug. ***
I understand that a file link from within an http page can pose a security risk. However, there are legitimate uses for such links. Where I work (a healthcare system with over 15,000 employees), we have documents on corporate servers, and our intraweb page has links to those documents. (These are not html servers; they are file and print servers.) I don't like the security.checkloaduri solution because it removes all protection, and it can be difficult to implement across the enterprise. I recommend that when a user clicks on a file link from within an http page, a dialog box appears that warns the user, giving the name of the file. The user can click "OK" or click "Cancel". This approach is similar to the other warning dialogs that appear (for example, when a page contains both encrypted and unencrypted data.) Some sort of dialog box is needed. I spent several hours "debugging" this until I found the relavent listings here in Bugzilla. Remember: some of the people using Mozilla are testing the web pages they are developing. Thanks for your consideration.
No, bad idea, sorry. If you are working in a large intranet and have to click on all those dialog boxes for every page to view, you will quickly find yourself working with some better brand of browser. This needs a more general solution, maybe something like the detailed hostlist used for cookies, certificates etc. At least the 'checkloaduri' solution is an acceptable workaround for now, as this will only be activated for about 20-30% of all users.
This *REALLY* needs to be looked at for the next release. mpt: Did you plan on doing the code for this? If not, can we re-assign?
Keywords: mozilla1.2, nsbeta1
This REALLY REALLY needs an option to disable this "security" feature, since it is currently preventing us from converting many people away from IE and Windows to Mozilla and Linux. I could not get the user_pref change to have an effect. It is essential this becomes an option, as it is hindering real work. These HAVE to be made options otherwise people and especially companies which rely on these features will be unable to make the change -- do you want people to use free software or not?!
what line did you add to prefs.js? you shouuld use about:config to verify your results, and you use use all lower-case (someone spelled URI w/ uppercase somewhere and it stuck, but the prefs system is caps sensitive).
I don't care one whit whether people use free software. I about not exposing users of software I write to security exploits. It has been made abundantly clear that IE does _not_ care about this. Should we emulate IE in this irresponsible attitude?
This is not about emulating IE's insecure behavior, this is about not being able to use functionality in environments considered secure. I like Mozilla's security approach, I don't want file links to work for any internet site, but I do want them for corporate websites, for my home web server, and so on. And that's exactly why the prefs.js setting is not a solution, since enabling it makes file urls work for *any* website. As long as Mozilla doesn't sport something similar to IE's intranet/internet/... zones, I'd be happy with an option (not in prefs.js but in the preferences dialog, users should be able to find it!) that enables file urls for sites that are excluded from the http proxy for example. Not an ideal solution, but better than nothing IMHO.
Not a bad a idea ! But I would still vote for the explicit 'secure sites' list, as the necessary infrastructure for such lists is already there (see cookies, images, etc.). Maybe with the non-proxy sites included as default entries ?
So this is a 'security feature' is it?!?!? Next you'll be saying that Mozilla crashing is a 'security feature' to stop peoples children looking at pr0n sites. For goodness sakes you can only hold peoples hands so much and if they choose to ignore a warning box then the results are down to them. Prehaps a better way to approach it would to be have a warning with specific approval list or an 'intranet zone' as suggested.
Gert: file a bug that describes what you want. (For example, I suggested bug 93787 as one possible solution). You should be aware that there are some problems with the way internet zones are designed as well, so I don't think you'd ever see anyone implement exactly what MS has done. Mark: please, avoid comments that sound idiotic. I could, for example suggest that we reduce airport security because I think it wastes my time... I'd like to emphasize that people should be doing as much background reading as possible before commenting on things like architecture and security. Use some common sense, if mozilla broke something that is commonly used, and there are more than 25 comments in a bug, someone probably told us. On the other hand, I've been finding two things that are interesting about this bug: 1- Very few people know that you are not supposed to use file URL's to publish content. RFC 1738: The file URL scheme is unusual in that it does not specify an Internet protocol or access method for such files; as such, its utility in network protocols between hosts is limited. RFC 1630: There is clearly a danger of confusion that a link made to a local file should be followed by someone on a different system, with unexpected and possibly harmful results. Therefore, the convention is that even a "file" URL is provided with a host part. This allows a client on another system to know that it cannot access the file system, or perhaps to use some other local mecahnism to access the file. The suggestion that nfs: and afs: be created a separate protocol schemes in the original RFC suggests that file was meant for locally mounted files only. 2- Even fewer people currently understand enough about the security issues I know I don't, and I get asked to provide networking expertise on security issues pretty regularly. Anyone not familiar with how this security exploit works should read up before commenting. The fact is that Mozilla has a stated goal of making security a very high priority. I agree that this feature was not implemented with much consideration, but that can be fixed by focusing on finding solutions. At this point, I think the consensus is that hiding the error message in the javascript console is too deeply burried. Lots of people live and die by publishing file URL's, I don't know why, but it is part of the computing environments in many places. (They also publish a lot of completely incorrect file URLs, you can look in Networking:File for that). My personal experience is that hacking the pref, esp. in Mac OS, is really time-consuming and error prone. It would also leave you badly exposed to anyone who wanted to server you a page that could read your local files. So, what we need are two things: 1- A code fix in this bug. 2- Other bugs, that are filed as RFE's for other solutions (maybe allow file URLs that are remotely mounted, allow file URL's on pages that are in your default domain, etc.)
per asa - going to xp-apps.
Assignee: mpt → blaker
Status: REOPENED → NEW
Component: User Interface Design → XP Apps: GUI Features
QA Contact: zach → paw
*** Bug 164653 has been marked as a duplicate of this bug. ***
*** Bug 166582 has been marked as a duplicate of this bug. ***
*** Bug 166482 has been marked as a duplicate of this bug. ***
Blocks: 135830
*** Bug 167806 has been marked as a duplicate of this bug. ***
Having just stumbled onto this bug the hard way (my searches for dupes didn't show up) I thought I'd add my US.02... Yes, this needs to get fixed, and soon! Now that Mozilla's stable, there's a bunch of people at my company (and a fairly large one, at that) who have been Making The Switch. But this is kind of a showstopper for us. I understand now the security implications of file links - and they make good sense. However, the fact of life is that I don't have the political pull to kick the people who run our Intranet IIS (gack) server into providing us server-visible links to the entire network storage hierarchy. Thus, as merely a lowly webmaster for part of my department, I am forced to do things like: &lt;A HREF="file://///BIGSERVER/share/my_app"&gt;Browse MyApp distribution&lt;/A&gt; Yuck... but my other choice is to mirror the entire application distribution hierarchy onto the webserver - double yuck. So, I've heard two solutions to this which - between the two - sound like gold to me. 1) Allow a list of websites, vaguely similar to IE's zones, that can have escalated privileges. Yeah, something could theoretically spoof the site... perhaps allow for a IP/mask to be checked against? 2) Pop up a dialog when the user clicks on a file: link. The link you have clicked on is directed at a local file. This is a security risk, and may allow harmful code to be executed. Do you want to open this link? Yes/No/Always for this link/Always for this site/Never for this site/Never Those two options could possibly be combined into a single structure of sites and/or links which are allowed as file: links. The other route that should perhaps be pursued is an Evangelism path... spreading the word, perhaps through articles in webmaster publications, that file: links are bad - and possible solutions to avoid them. This could perhaps be carried so far as that people skilled at writing CGI and ASP could write scripts that would fetch an approved list of files and directories from the local file schema and (in the case of files) present them for download, and (in the case of directories) present them as a list of HTML. (I am unfortunately not that person. I am slowly learning Perl in my freetime but I am not a CGI programmer... I do C++ right now.) In any case, I've rambled enough, but in summary: 1) If we want Mozilla to have a chance of displacing IE, this needs to be fixed. 2) Shooting the users in the foot is bad. Giving them a gun isn't, as long as you explain that they could shoot themselves in the foot if they're not careful. 3) Yet Another Dialog Box isn't a bad thing, dammit. Users need feedback... if we were writing a developer-only tool... well, things would be different.
I just checked the release notes 1.1, still no hint on this problem there. Can somebody quickly put a note under the 'Security' chapter that file links do not work as expected ? That would at least save people a lot pain (see the comment above). TIA.
*** Bug 168669 has been marked as a duplicate of this bug. ***
I'm not a native speaker, but here's my try: " Because of possible exploits, 'file:///' links to local resources from within a 'http://' page are blocked by default. Currently, there is no user visible message (bug 84128). To enable these links, set the variable "security.checkloaduri" to false in the user.js file."
That seems to cover the browser side of things but there also needs to be mention of it not working in emails too.
Oh yes, here's the revised note: " Because of possible exploits, 'file:///' links to local resources from within a 'http://' page or a mail message are blocked by default. Currently, there is no user visible message (bug 84128). To enable these links, set the variable "security.checkloaduri" to false in the user.js file."
Jo end user will want a tick box somewhere in preferances not to go hacking through a file that they may not know the whereabouts of. Besdies which you shouldn't need to be able to hack at a prefs file to use a browser. Voting for a simple tick box under prefs/privacy & security.
I'd rather vote for a very smart system to distinguish a user clicking on an url from other ways of loading it and allowing that specific case (the same way you can type the url to address bar).
Having a tick box is a short term answer but I'd like to see that replaced in the long term by a graded access as per RFE bug 135830
I have no problem with the security issue underlying this bug. It's entirely reasonable that file: URLs shouldn't be accessible from pages loaded from http: URLs. I'd written a simple server that searches an index of documentation. As an option it allowed the server to return file: URLs. When I tested the server with Mozilla it didn't work as expected. As a result I've seen the error of my ways and have changed the server so that it doesn't return file: URLs. And it's all the better for it. However, that isn't what this bug report is about. This report is about the lack of any sensible feedback when the user clicks on an impermissible link. I spent something like two hours trying to figure out why my server wasn't working as I'd expected, with detours into the proper handling of 301 and 307 HTTP responses (bug 48202) and the inconsistent behaviour of file: URLs with the middle mouse button (bug 148418). It was really annoying to waste two hours of my life tracking down the problem only to find that it's a well known issue that could easily have been remedied months ago with a dialog. I am angry that the Mozilla developers should have so little respect for the time of others that they haven't implemented this simple fix.
And still no word in the release notes: see comments #89, #91-93....
Nav triage team: nsbeta1-
Keywords: nsbeta1 → nsbeta1-
1: users should be warned when they attempt to do dangerous things, not ignored. 2: this needs to be in the release notes. PLEASE! if you want to be able to use file:// from an http: served page in an intranet setting like I do, vote for bug#93787
(a) Whatever one feels about the security issue, there really has to be _some_ sort of feedback in this case. It's completely unreasonable for mozilla to block the link silently, not least because it wastes so many people's time working out why it's done that, eventually finding this bug report, and working their way to the bottom. (b) Surely the resolution is more subtle than just `file: URLs are evil, use http: URLs only'. As a concrete example, the case where this bit me was using a little wiki on an intranet to keep track of, for example, different documents and trees on the intranet -- a flexible and locally-sharable bookmarks page, in other words. Now I _could_ work out a way of referring to the local shared disks via http, but (i) this would make this wiki solution effectively unusable, and more importantly (ii) if I make a mistake implementing that, I've accidentally exposed our whole shared filestore to the public internet. In other words, working around this security feature means that I'd have to worry about a whole new class of security problems, and I would have effectively _lowered_ the security of the whole setup. The only realistic way of dealing with this feature is to disable it entirely, which is not a win for me, since it means I'm just as exposed to the real security problem as I would be if the feature didn't exist.
Blake, ny status on this bug?
Perfect solution would be enabling the user to configure a list of domains from where requests to file:// are allowed.
regarding comment #103: That's what bug#93787 is about. If that's what you want to do, please go vote for it as well. This bug is about mozilla silently ignoring the FILE:\\ requests rather than being noisy about it, as I would prefer.
Just FYI, I may soon re-enable links to file: URLs if I can figure out how do do it without opening any security holes.
*** Bug 185468 has been marked as a duplicate of this bug. ***
*** Bug 186207 has been marked as a duplicate of this bug. ***
I am impressed that *any* problem that has generated this much controversy merits some kind of attention. For instance, I would not have had my difficulty if there had been an error message saying "By default you are not allowed to follow file:/// links in pages loaded from the network because the results can be unpredictable. There is a parameter in all.js [name it here] to change trhis if you need to." I agree with another poster in this comment chain: No matter what a purist may think, why turn people away from using Mozilla because of something they need in this world even if in a better world they would not need to do it?
keyword update. Blake + Paul, this bug is pretty high up on the duplicate list, as well as not even being correctly marked a dupe because of problems with writing the correct bug. Can anything be done to fix this for the next big release?
Keywords: mozilla1.2, nsbeta1-
Ben, I'm going to try and relax the CheckLoadURI policy if possible so that a dialog is not needed. I stand by my assertion that adding a dialog is not the right thing to do.
Ok, no new dialogs. How about a message on the status bar at the bottom of the window? "Security restriction: file:// not allowed from this domain."
As a user, I would rather get a dialog box than a message error on the bottom status bar, unless you make the status bar flash red for 2 seconds, to get the attention of the user. I rarely check the status bar at the bottom and if I click on a link that does nothing, I will not necessarly think of checking the status bar. We users are simply not used to look at the status bar, since 99% of the time we never have to look at it. Actually, until I have read the last comment, I did not know it was called the status bar. BTW, flashing the status bar red for 2-3 seconds with a 0.5s interval is a good way to get the attention of the user. I worked on GUIs implementing this and got positive feedback for such a feature. Users see right away the error whitout the dialog on which a button needs to be pressed and hide the main window.
*** Bug 170654 has been marked as a duplicate of this bug. ***
*** Bug 188107 has been marked as a duplicate of this bug. ***
Another functionality not mentioned before that is blocked by this bug: in online education it is not uncommon to send out CDROMs with content, and to link to materials on such CDs via file:/// URLs (with dynamically set drive letter/name). So once again users of Mozilla-based browsers don't have useful functionality that users of other browsers have. Does anyone really think this is a good thing? Boris said he doesn't care, but if you guys don't care whether your users are happy, then why on earth are you doing this mammoth project? Just for yourself? Besides, there is always so much talk about standards compliance within Mozilla. Clicking on a file:/// link is supposed to open that file, if the link is valid. That's the standard. Where is Mozilla compatible with that? Instead, Mozilla just sits there, doing nothing. A real quality user experience. Alt-F4 or Command-Q would be the most common user response.
I said I don't care whether people use free software in general. This is not the same as not caring whether people use Mozilla. But yes, I, personally, work on this project just because I sorta feel like it. ;) Mitch _is_ working on fixing this bug. It's just taking a while because the problem of not opening up security holes is a little delicate, ok?
If I had a nickel for every "Mozilla would be great if it weren't for bug XYZ" comment I have to read, I wouldn't have to work here :) Seriously though, I am looking for a way to remove this restriction on file: URLs without popping up yet another dialog. Trust me, you don't wand another dialog. Links to file: URLs from non-file pages ought to work - the trick is that we want to disallow scripts from linking to file: URLs, and it's hard to distinguish link clicks from script-initiated loads sometimes.
> Seriously though, I am looking for a way to remove this restriction on file: > URLs without popping up yet another dialog. Mitchell, you just made my day! I think that would be the perfect solution to this problem. > the trick is > that we want to disallow scripts from linking to file: URLs, and it's hard to > distinguish link clicks from script-initiated loads sometimes. Understandable. I wish you the best of luck! I'll be downloading the nightly the minute you get a fix in. :-) Thanks again!
*** Bug 193901 has been marked as a duplicate of this bug. ***
One source of my confusion about this bug (sorry for the duplicate bug filing) was that when I right-click on a file:// link embedded in an http:// page and select "properties"... the resulting "Element Properties" dialog that gets popped up says, "Link Properties [...] Will open in: Same window"... It might be nice if the "Element Properties" dialog would indicate that in fact, the link will NOT be opened in the Same Window!
David, the bug you're looking for is Bug 91108
As with many earlier comments, I just ran into this bug for the first time. I have the same problem as comment #101: The wiki I am setting up doesn't work well with the Mozilla client because it can't use file: links, and the only alternative seems to be opening a huge possible security hole by opening the entire intranet through the web server. (Please let me know if there is an alternative!) However, I understand the seriousness of the issue, and appreciate that the Mozilla Developers are thinking so far ahead of security issues as to foresee this and take a stand on it 1.5 years ago. If there is any way to get the file: to work safely it would be a great boon to wiki users. Thanks!
There is actually a bug/workaround for getting the linked file in mail messages which have a file:// link in to open. Make sure you have no browser windows open. Right click on file:// link and select open in new tab New browser window opens and file in link opens in correct application. Logged this as bug 197252
Attached image Mozilla 1.3 —
I have Windows XP SP1, Procesor Intel 2533 MHz, 750 MB RAM. If I use Mozilla v. 1.2.1 it's all OK.
*** Bug 197092 has been marked as a duplicate of this bug. ***
Blocks: majorbugs
*** Bug 199295 has been marked as a duplicate of this bug. ***
*** Bug 200051 has been marked as a duplicate of this bug. ***
*** Bug 202262 has been marked as a duplicate of this bug. ***
*** Bug 191895 has been marked as a duplicate of this bug. ***
*** Bug 151253 has been marked as a duplicate of this bug. ***
*** Bug 169682 has been marked as a duplicate of this bug. ***
*** Bug 203416 has been marked as a duplicate of this bug. ***
*** Bug 203472 has been marked as a duplicate of this bug. ***
As per the comments below, I added the line user_pref("security.checkloaduri", false); to every .js file I could find with no change in the behavior. I still get the security message in the javascript console, and I cannot open the file. Any further ideas? I am running NS 7.0.2 on various OS's. Thanx! -Michael
*** Bug 206889 has been marked as a duplicate of this bug. ***
To continue to put the case forward to get this fixed I want to say that this issue is making _thousands_ of people regularly have to resort back to using IE/Netscape. Surely you pity us? The 3 things that seem to effect most people are: 1) CD-roms that self-reference material via file:/// URLs 2) wiki's 3) LAN sites that index files on the LAN (very common where I work).
My idea to distinguish for corporate Intranets between Intranet webpages (file: allowed) and Internet pages (file: not allowed) is to use the proxy settings. Usually, proxy config should be done so that Intranet pages are accessed directly and only external pages go through the proxy. No new dialogs necessary and would work seamlessly in a correctly set up enterprise Intranet.
Please, for the love of God, can this be fixed. Mozilla has a perfectly good mechanism for preventing/allowing cookies/pop-ups/everything else from a site; why can't this be applied to file:/// URIs as well? I'm missing work being updated on our corporate Intranet because I refuse to bow down to Billy Gates any more than I have to in this job (I run WinXP but with Mozilla, OpenOffice.org and Abiword instead of the M$ equivalents) and it's getting frustrating, not just for me but for my boss as well. I hate IE. He will make me go back to it if Mozilla can't handle file:/// URIs (and also as <iframe> sources) sometime soon. I understand the security arguements that have gone on for... TWO YEARS! Dear God! ... but pity those of us who are trying to actually use Mozilla in our day-to-day lives but aren't savvy enough to code for it!
Steve, you can always put 'user_pref("security.checkloaduri",false);' in your .mozilla/<user>/<xxxx>/user.js file to get around that problem (with the slight inconvenience to expose yourself to theoretically possible security threats, if javascript is switched on). Of course, this is not an excuse not to get this bug fixed in a proper way...
beanladen@arcor.de - Are you using Linux? The file: .mozilla/<user>/<xxxx>/user.js doesn't even seem to exist in Windows XP. I can't find user.js anywhere. The closest I can find is: D:\Documents and Settings\scottb.BRIDGEPOINT\Application Data\Mozilla\Profiles\default\kzmw3s1k.slt\prefs.js Even though that file has the wrong name, I tried adding 'user_pref("security.checkloaduri",false);' to that file just to see if it would work -- no effect.
Scott: Just type in your comment and press 'Commit' -- no attachment needed (provided you use the web page to submit your comments). Yes, I'm using Linux (of course ;-), and you nearly hit the right place. But prefs.js shouldn't be touched (at least not while Mozilla is running) since it is overwritten. Instead, put a new file user.js in the same directory where that file lives. It's intended to be created by users to put in their personal prefs.
Creating a file called user.js and adding: user_pref("security.checkloaduri",false); to it has no effect (even tried rebooting). I also noticed pref.js has: # Mozilla User Preferences // This is a generated file! Right at the top. So I tried adding user_pref("security.checkloaduri",false); to it again, with Mozilla closed. Now I get "An error occured reading the startup configuration file. Please contact your administrator. SyntaxError: illegal character. #Mozilla User Preferences." I edited the file with TextPad. Is textpad inserting hidden characters? What text editor should I use in Windows so this doesn't happen?
No idea, maybe a Mickeysoft - expert should answer here. For a quick solution, you can also type 'about:config' into Mozilla's URL bar and edit the value by right mouse button 'modify' (or New boolean, if it's not there).
> I edited the file with TextPad. Is textpad inserting hidden characters? > What text editor should I use in Windows so this doesn't happen? I expect "Notepad" would be sufficient for this. e.g. Start | Programs | Accessories | Notepad Notepad is suitable for /short/ files that must be plain ascii text. Your editor likely lets you save in 'plain text' mode too.. check your editor's "File | Save As" dialog window for an output format chooser.
OK, finally some progress. Adding: user_pref("security.checkloaduri",false); to prefs.js under ...\Documents and Settings\<user>\Application Data\Mozilla\Profiles\...\...\pref.js (in Windows XP) and making absolutely sure not to hit "Enter" (by placing user_pref... on a previously blank line), allows files to be loaded from file:// links in a web page, BUT ONLY if the file link refers to a "letter" drive! So: file://Z:/Project/Schematic.pdf works, but file://network_drive/Group/Project/Schematic.pdf does not, where I have had Windows map Z:/ <==> network_drive/Group This is still a big problem for corporate intranet Twikis. You just aren't going to get all users to map network drives the same way. Is there any way around this, or is this expected behavior?
file://network_drive/Group/Project/Schematic.pdf is not going to work like you might think... try this instead: file:////network_drive/Group/Project/Schematic.pdf
>> try this instead: >> file:////network_drive/Group/Project/Schematic.pdf It actually takes 5 "/'s": file:///// but that did it! Thanks! It also doesn't break Internet Exploder (I'm guessing that's the correct way to do file link anyway, but you can't take anything for granted with M$). Time to go fix the file links on our TWiki site (should have used a TWiki variable the first time...) and link this bug report so people can use Mozilla for file:///// access...
Hello all... Success for me too! I found my prefs.js file, but no user.js file; figured that maybe it isn't made by default and tried creating it, just to put the 'user_pref ("security.checkloaduri",false);' in. So now I can see the intranet. Fab. However, having to go through this process, while a matter of course for those of us used to using and configuring Linux boxes, really isn't acceptable for our Windows/Mac-only bretheren; and as such, with intranets cropping up everywhere, I'd say (this is my EUR 0.02 worth) is going to hold back Mozilla from being deployed more in businessy circles. Which is a shame, because as browsers go Moz 1.5a is about as good as I've ever seen in my multitude of years. BTW - happy birthday to me =) Steve
I am just curious if anyone has any info regarding this bug. Bugzilla Bug 84128 Need user-visible message when CheckLoadURI fails (eg, for links to file: urls) I edit prefs.js file and reboot the machine i am also using <SCRIPT SRC="file://///Automation/username.js" Language></SCRIPT> and i am using Mozilla 1.4. and its not working for me. Just curious if that fix in Mozilla1.5. Please let me know, I really appriciate your help.
I am just curious if anyone has any info regarding this bug. Bugzilla Bug 84128 Need user-visible message when CheckLoadURI fails (eg, for links to file: urls) I edit prefs.js file and reboot the machine i am also using <SCRIPT SRC="file://///Automation/username.js" Language></SCRIPT> and i am using Mozilla 1.4. and its not working for me. Just curious if that fix in Mozilla1.5. Please let me know, I really appriciate your help.
Pawan: Please read comment 146 to comment 149 . Absolutely no need to reboot (even if it is Mickeysoft....), just stop Mozilla before edits and restart it afterwards. P.S.: I added you to the bug mailing list just that you see this message and the progress.
Hello All, Did anyone try this on Linux machine. Because, My server is running on Win2k and I want to accsse some file locally ( client side ) from Linux. In Win2k, I says <Script src="c"\temp\user.js"> so its work but how would I include linux path. In linux system I have file in /root/temp/name.js. Any help .. Thank s
*** Bug 220069 has been marked as a duplicate of this bug. ***
Attached patch Proposed patch v0.2 (obsolete) — — Splinter Review
This patch introduces a dialog that prompts if the user wants to load the file from a denied protocol or not. There is also an added preference to control whether this dialog appears or not. The wording of the dialog box probably still needs some work.
Taking from blake@blakeross.com
Assignee: blake → bugzilla
Accepting and adding dependency to bug 220711
Status: NEW → ASSIGNED
Depends on: 220711
Comment on attachment 132371 [details] [diff] [review] Proposed patch v0.2 This will lead to crashes all over, just like the image confirmation dialog did (except worse, since this is called from more places). Whatever you do, you may not pose dialogs from inside this function without heavily modifying the callers to deal with the ensuing mayhem.
Attachment #132371 - Flags: review-
Adds ALLOW_CONFIRM_FILE so CheckLoadURI knows when it is being called from a user generated event and thus preventing crashes as mentioned by bz.
Attachment #132371 - Attachment is obsolete: true
Attachment #134430 - Flags: review?(caillon)
Comment on attachment 134430 [details] [diff] [review] Patch v0.3 - dialog should only appear from a user generated event So, after thinking about this some, I don't really like the idea of spouting out an alert from this code path, even based on a pref. I think the ideal solution would be to display an icon of some sorts in the statusbar upon notifications of any new messages on the Console (Note that I did not call it the JS Console, because it really should be renamed one of these days). I suppose this is similar to what iCab does, and also similar to what IE does....
Attachment #134430 - Flags: review?(caillon)
I disagree with Christopher A. Aillon's assesment in #161 that "the ideal solution would be to display an icon of some sorts in the statusbar". That is only a bandaid that gives user feedback, but does not address the underlying problem, which is that the browser/newsreader does not respond the way people want it to. I agree with Ian Neal in comment #96 that "Having a tick box is a short term answer but I'd like to see that replaced in the long term by a graded access as per RFE bug 135830". The browser behaviour needs to be modified so that it works in the corporate/LAN environement without compromising security.
> That is only a bandaid that gives user feedback Which is precisely what this bug clamors for. There is a bug to implement security zones, similar to IE, which should let the user specify which types of sites are allowd to access file: URIs. When that gets implemented, feel free to toggle the prefs around. I don't foresee us changing the default policy to blanketly allow file: though, since there are abuses in the wild. That notwithstanding, any decisions to that effect would happen elsewhere.
> I think the ideal solution would be to display an icon of some sorts > in the statusbar upon notifications of any new messages on the Console. I wouldn't call that ideal. Regular users want nothing to do with the "console". Regular users should not be required to look at the console to find out why a perfectly functioning browser cannot follow a perfectly legitimate hyperlink. You really should just redirect them to some page (call it "about:file") that explains what happened and what they can do to fix it (once Bug 135830 is fixed).
My point was, that caps backend should not do anything with UI. It should send out a notification which the UI can listen to that loading a file URI failed. The UI can do whatever. Since there are already bugs that ask for console output to be displayed with a status icon, I mentioned that.
caillon: so this bug depends on bug 47128?
*** Bug 226085 has been marked as a duplicate of this bug. ***
Blocks: 70871
I vote for the solution as described in Comment #139 From Steve Anderson. When the user clicks on an file-URL in an http-Document, a question dialog appears asking for "accessing file-URLs from that site 'http://the.document' allowed" - "yes", "no", "always", "never" . Additionally should there a prefs-dialog like the one for "popup-window-blocking" or "password-saving" to manage these entries of URLs. So coporate users can allow access to file-documents from intranet-servers, because they already have access to these files through the operating-system and mozilla delivers only the hook to the file. So no security reasons staying against this mozilla-file-access.
ditto comment #168 and #139.
*** Bug 228027 has been marked as a duplicate of this bug. ***
I posted this comment with Bug #122022 because was not sure where to place it. The bottom line for my location is that this problem of link blocking forces us into the IE camp. I do not care if you call it a bug or a security "feature". If Mozilla will not permit me to access a file on a server (NT, 2000, etc.) from a link from within a web page, then my people are forced to use IE to get there. As long as the link is valid, any kind of message as to why Mozilla has deciced not to permit the action is worthless to the users--they will just start using IE full time.
Ken: See comments #146 to #149. There's no need to ever switch to IE again !
> See comments #146 to #149. I can see where that might be a *big* problem for a large company to deploy to hundreds or thousands of users, if the admin has to tweak individual user preference files. Is there a way to configure this mod into the ~mozilla/defaults/pref/* files, so the admin can pre-tweak the defaults, before distributing mozilla to the network? Then mozilla would come up with the correct defaults for the entire facility, and the user wouldn't need to make any changes.
Greg: Of course there is a way. I'm on Windows right now so I can't tell you the exact location in Unix, but on Windows, it's in C:\Program Files\mozilla.org\Mozilla\defaults\pref\all.js. There's this line: pref("security.checkloaduri", true); Just change true to false and you should be done. This file (all.js) contains the defaults and is processed first. Then the platform-specific defaults file (for example, winpref.js), then the user's prefs.js file, and then the user's user.js file.
This issue has been cranking on for two years now!!! I've attempted, using Linux and Windoze, to access a file on my network server using M$IE, various flavors of Mozilla (with the user prefs modified), Netscape, Opera and OffByOne. I cannot access the file with any browser from any computer on my network -- much less via the internet -- except by using the browser running on the server itself, of course. Just what is this purported security problem? It seems to me that file:///C:/xxxxx.../foobar.xxx will only open such a file on the user's machine. If it exists there. What am I missing?
This issue has been cranking on for two years now!!! I've attempted, using Linux and Windoze, to access a file on my network server using M$IE, various flavors of Mozilla (with the user prefs modified), Netscape, Opera and OffByOne. I cannot access the file with any browser from any computer on my network -- much less via the internet -- except by using the browser running on the server itself, of course. Just what is this purported security problem? It seems to me that file:///C:/xxxxx.../foobar.xxx will only open such a file on the user's machine. If it exists there. What am I missing?
> It seems to me that file:///C:/xxxxx.../foobar.xxx will only open such a file on > the user's machine. If it exists there. > > What am I missing? Networked file systems, including NFS and SMB. These are accessible by every machine as if they were local files, but they are really located on a central server. Very convenient for businesses. There are other possibilities as well. You could have an internal company "help" site which wants to link to some standard help documents on the user's own machine.
Brad: I don't think that's what Roger was asking. Roger: Mitch and bz explained the security problems with allowing http: pages to link to file: URLs: http://bugzilla.mozilla.org/show_bug.cgi?id=84128#c20 http://bugzilla.mozilla.org/show_bug.cgi?id=101207#c4
I'm just getting around to this Bug now, reaching it from all the dupes and related bugs. This has been open since 2001-06-05. That was 2 1/2 years ago! Hey, I love Mozilla, but bugs that stir up this most controversy need to be fixed quicker than that. I vote for Kurt's comment (#30) on 2001-09-25 (still over 2 years ago) - the user should be asked if they want to allow this access. In comments #155, Ian posted a pic of a nice dialog patch! As a serious, long-time user, I'd be happy w/ this dialog. If someone can get that working, this user would be thrilled! (I don't understand the developers' reluctance to implement dialog boxes.) Mitchell, you haven't commented on this bug since 2003-02-06. Can we get an update?
> (I don't understand the developers' reluctance to implement dialog boxes.) Possibly its because dialog boxes get in the way. (They require action from the user to dismiss them). Displaying a message page does not. (The user doesn't have first acknowledge the message before proceeding to, say, select a bookmark or click the Home button.) (You might say that replacing a page with links with a message page gets in the way because the user has to go back, but consider opening multiple links in new windows (or tabs): Each new window/tab should show the result of opening (or attempting) to open the respective link.)
There's nothing wrong with using a dialog to inform users that a link doesn't work, as long as it turns into an error page when browser.xul.error_pages.enabled is set to true (see bug 28586). But if the dialog allowed users to bypass the restriction, Mozilla wouldn't be much more secure than IE wrt file: URLs, and that would be a problem.
Mitch Stoltz wrote on netscape.public.mozilla.security in a thread titled "file:// protocol security workarounds?" on 2003-04-08: "I don't want to allow users to exempt certain sites from the policy, for two reasons: 1) It's fairly easy for a malicious site to masquerade as a legitimate one. 2) In general, asking users to make on-the-spot security decisions is dangerous."
Forgive me if this seems like just adding to the spam, but to me, the security issue seems to be purely hypothetical. Has anyone ever documented a successful abuse of a file: URL, aside from the famous file:///con DOS bug? (That, obviously, can be solved without crippling the browser.) And as for the statement quoted in comment 182, and the opinion expressed in comment 181, I can only say that if I wanted someone to think for me and tell me what I can't do because it's dangerous for me, I would have hired a nanny instead of buying a computer. But, I guess I should go read the newsgroup then... Also, if it's "fairly easy for a malicious site to masquerade as a legitimate one", then that's a completely different bug that should be fixed. Perhaps then we can trust the user to be able to make an informed decision about their own files?
> "I don't want to allow users to exempt certain sites from the policy, for > two reasons: > > 1) It's fairly easy for a malicious site to masquerade as a legitimate one. > 2) In general, asking users to make on-the-spot security decisions is > dangerous." Since when is exempting certain sites from the policy an on-the-spot decision? That might apply to exempting via a dialog box, but make sure sites can be exempted permanently. Just make sure Mozilla doesn't prevent me from what I do with Netscape 4.7: - I bookmark some local files with "file:" bookmarks. - I upload the bookmark file/page to a public server so I can access my bookmarks from other machines too. - On the original machine, I get the remote bookmarks page and click on a link to a local file and get the local file.
Most of the cases where file: urls should work are those where a user clicks on a link and wants it to open in the browser. This situation is analogous to the user typing the url into the url field. Most of us wouldn't need a dialog at all if Mozilla could separate this case from all the others and treat it the same as typing of the url.
> Most of the cases where file: urls should work are those where a user clicks on > a link and wants it to open in the browser. This situation is analogous to the > user typing the url into the url field. Most of us wouldn't need a dialog at all > if Mozilla could separate this case from all the others and treat it the same as > typing of the url. EXACTLY!!!!! Disable file: links in javascript code. Disable them for images. Disable them for everything EXCEPT a plain old hyperlink. Now, I'm not sure how easy this is to do, since "<a>" tags can contain attributes that cause javascript to run. But ideally this is what we'd like to happen.
Ben, you seem to have some supervisory role in Mozilla. Mitchell is unwilling to make this change, despite users constantly asking for this for 2 1/2 years. Can you assign this to someone who *IS* willing to "give the users what they want"? The attention to security detail is very admirable. But the file: URL is "legitimate" in today's world, and Mozilla needs a way to handle this. The message in the Javascript Console is NOT adequate. At the least, fix that problem. At the most, give users the dialog box! Sincerely, Jim
Jim: When a component owner makes a decision you don't like, you can't just ask people to assign the bug to someone else who might make a different decision.
Well, Jesse, you've settled the Mozilla matter for me: Out goes Mozilla from my machines. This bug, the "won't print last page" bug, the inability to quickly and easily incorporate/edit plug-ins, and so on are evidence enough that Mozilla is a geek toy and not a worker's tool. Ta Ta! One last caveat: Get the ego-driven geeks out of Mozilla's chain of "fixers" and get mission-oriented achievers in.
These are the holes caused by letting sites link to local files: A1. If the browser *or any helper app* (e.g. RealPlayer) puts untrusted files in a predictable location, any page can link to that file and thus read every file on your hard drive. A2. Holes in same-origin policy (cross-domain) become read-any-file-on-your-hard-drive holes. o But same-origin holes are already considered serious enough to block releases (they let sites steal cookies, passwords, and info on intranet web servers). A3. DoS attacks against the browser or even the OS using file:///con/con or /dev/stuff. o DoS attacks are not a big deal. o This DoS can happen right now with bug 69070. o This DoS could be fixed through bug 29079. A1 is the most serious.
Several people proposed allowing link clicks but not script loads (comment 117, comment 186). That wouldn't fix any of the security holes I listed, so it would be pointless. All a site would have to do is get you to click a link to a file: URL. Allowing *only target="_blank"* links to file: URLs would solve A2. But that would be really weird, and it still wouldn't solve A1 or A3.
A1 is a real problem, but blocking links to file: URLs isn't the only way to fix it. I can think of three ways to fix A1: F1. Block links to file: URLs. (What Mozilla does now) o Annoying to some intranet users. o Insufficient for A1 because users also save web pages. o Insufficient for A1 because users also receive zipped HTML files. F2. Avoid creating predictable filenames. o Annoying to users who download files. o Annoying to users who play with their profiles. o Relies on psuedorandom numbers being unguessable. o Infeasible because helper apps have to get it right, too. F3. Tighten the same-origin policy for local files. o Annoying to web developers who test heavily scripted sites locally. Since F3 is the only one of the solutions to A1 that's actually secure, and I filed bug 230606 for it. Fixing bug 230606 would allow us to get rid of the "http: may not link to file:" policy (except for a few special cases, like the SRC of a script element). But bug 230606 should be fixed even if the linking policy is not relaxed, because it's a security hole by itself.
First, if the developer assigned to this bug isn't willing to do ANYTHING about it, then yes, it *IS* reasonable to ask that someone else be assigned. Second, a question to those who would say otherwise---explain how, with Mozilla as it is today, one can do all of the following: 1) Load a centralized web page (e.g., corporate site) 2) Access file: URLs in that (trusted) web page that point to trusted locations on a local (e.g., networked, but not via a web server) hard drive. As has been pointed out time and time again, this is *VERY* common practice in a LAN environment (and not just commercial sites---I have similar links here at home, too). 3) Access file: URLs from a trusted web page on their own hard drive (e.g., could be a site they develop, their own index page, help docs, etc.). 4) Not have to worry about sites *OTHER THAN THOSE TRUSTED LINKS/SERVERS* and the security problem(s) they might pose. As someone else recently pointed out, the developers are not in a position to make the decision (as to which sites to trust) for the rest of the world. As it is now, I've only seen two choices mentioned here---trust everyone or trust no one. Neither of those choices is valid...and as long as this bug has been around, it's safe to say that something's been done about it beyond that. So, knowing that the real solution (to all of the above) was coded a long time ago, would someone kindly put this to rest by telling the rest of us how it friggin' works? Are we secure from sites that we don't consider trusted? How does Mozilla know---does it follow the M$ method, and try to read our minds? Are we supposed to assume (as I'm forced to do today) that Mozilla *CAN* read our minds and trust only what we mean for it to trust? In other words, how do we, as individuals and/or network managers, etc., tell Mozilla that the following list of file: links are trusted, and others should generate an (obvious---e.g., error page) error, so the user knows that they've either avoided a crack attempt, or that they need to add access to a link? As I said, neither of the (supposedly-current) solutions I've seen mentioned here (all or nothing) are valid. So, please, just explain what the *REAL* solution (to the need for trusted file: URLs---and/or trusted servers that link to file: URLs---while avoiding security problems with *UNTRUSTED* ones) is and how to implement it with any reasonably recent version of Mozilla. Thanks, --jim PS: If I sound frustrated, it's because I am. I honestly can't understand why this has gone on for so long. :-(
Attached patch Patch — — Splinter Review
Comment 193 raises an interesting point.... Assuming I understand this code correctly, this patch does more or less what that comment asks for. If "security.checkloaduri" is true (so not all sites are allowed to access file:// urls), we go on to look up the relevant capability policy pref. If the pref says it's ok, we let the check succeed. The syntax for the pref is identical to that at http://www.mozilla.org/projects/security/components/ConfigPolicy.html#jspolicies except with "javascript" replaced by "checkloaduri" and the default is disabled; you have to explicitly set allAccess to enable it. This patch may allow us to just set about:blank to allAccess (questionable, I know) and fix bug 69070. Like the comment says, it would be better if we passed in an nsIPrincipal, not a nsIURI, as an origin. I _think_ most callers have easy access to a principal; the few that don't probably should.... caillon, Jesse, what do you think of the general idea? Note that this adds no UI for editing this pref, which makes the usefulness somewhat doubtful. But it does allow people dealing with intranets to just edit their settings to make that server trusted.
> These are the holes caused by letting sites link to local files: > > A1. If the browser *or any helper app* (e.g. RealPlayer) puts untrusted files in > a predictable location, any page can link to that file and thus read every file > on your hard drive. I don't want to allow "sites" to read local files. I want to allow my *browser* to read local files. I don't care how the browser gets to them. Is there not some way to distinguish these cases? If the browser is viewing the local file, allow it, if the browser is going to send the local file off to some site, disallow it?
Brad, see comment 178. The comments linked from there explain how a site can use the browser (but not the site) reading a local file as a security exploit.
Regarding comment #191: I can right-click on a file:/// url, copy it, paste it to the url field and press enter. No security risk, right? Why not just do the same (automatically) if I left-click the link? It could bypass javascript, target etc. and just open the link.
> No security risk, right? Wrong. That's what Jesse's A1 and A3 points are all about. If a site can get you to load a file:// url of its choice, whether it be by setting document.location, getting you to click on a link, or getting you to copy and paste the URL, it wins. Clearly the latter two are harder than the first one to accomplish for the site, and the third is harder than the second. But the security issues are exactly the same once the file:// url is opened.
bz - I am presuming that for imap the following policy should work: user_pref("capability.policy.policynames", "imapok"); user_pref("capability.policy.imapok.sites", "imap://mailservername"); user_pref("capability.policy.imapok.checkloaduri.enabled", "allAccess"); where mailservername is the same as the mailservername from aSourceURI of imap://user@mailservername:143/fetch%3EUID%3E/staff%3E26
-> Default bug owner for component
Assignee: bugzilla → guifeatures
Status: ASSIGNED → NEW
Ian, I have no idea. Care to test? The patch needs testing in general; I just checked that it compiles... All this apart from the wisdom of allowing email to load files off your hard drive.... ;)
enabling this for mail is insane.
bz - I have tested with sites arguments of the form imap://mail and imap://user@mail and neither of them work. If you are in a corporate environment with a shared file store then I think it makes sense for users to be able to put links in emails to files on that shared file store. It is not as if we are enabling this functionality by default, the user would have to edit prefs.js manually.
most corporate mailboxes are exposed to the outside world, mine always have been. This means someone can spam you w/ an exploit.... mails are generally sandboxed, even from other emails. The idea of making mails not sandboxed from your local file system is pretty poor since it means they can get at those other emails which we took effort to prevent.
Which brings it all round to the original reason for this bug being logged, if user A sends user B (both at the same company) an email with a link to a file on a common shared area then user B would expect to be able to open that file by clicking on the link instead of what they currently get which is no visible response. No visible response makes user B pick up the phone and ring the helpdesk and eventually leads to requests of "Why can't we have a mail client that works?" I'd like to have a more secure solution than setting "security.checkloaduri" to false. If more checks have to be put in place for imap than http then let's look at what they should be.
So far at work, when people send around corporate addresses, they're \\server\share\path, not even in a link, just plain. They expect outlook client to linkify as the receiver. while it's possible for \\server\share to be dangerous \\localhost\c$, i don't think they're generally as dangerous. Forcing a file to exist on a remote host in a network environment should be safe except for the case when a virus has taken control over that remote host and is sending everyone on the intranet an email. What do you do for that case? Clearly such virus/wormlike creatures exist....
Ian, does the patch work for an http site, for starters? Imap has more security checks elsewhere, so I'd like to know whether the approach even works (and whether it's desirable).
> If a site can get you to load a file:// url of its choice, whether > it be by setting document.location, getting you to click on a link, > or getting you to copy and paste the URL, it wins. No, I win, if it's my own site and my own link.
timeless - My users are a strange lot and were brought up on Netscape 4.x so know how to insert, link and select a file but have no idea about server names or share names. So their links appear in the form of file:///H:/corporate/policies/it.doc. I presume that mozilla knows or can find out which drive is it's system/OS drive so should be able to avoid links with that drive letter in e.g. if drive is W then avoid file:///W:/, \\localhost\w$, etc bz - To create test version I applied your patch to nsScriptSecurityManager.cpp and did make in caps/src. I tested with the following entries in prefs.js user_pref("capability.policy.httpok.checkloaduri.enabled", "allAccess"); user_pref("capability.policy.httpok.sites", "http://web3/"); user_pref("capability.policy.policynames", "httpok"); Added a simple page to web3 that contains the following: This is a test <a href="file:///H:/Finance/test.txt">link</a> but still get the following error message in JS console: Security Error: Content at http://web3/test.html may not load or link to file:///H:/Finance/test.txt.
> user_pref("capability.policy.httpok.sites", "http://web3/"); Drop the '/' at the end of the hostname and it should work (see the instructions again). At least it works here, now that I've had a chance to test. > imap://user@mailservername:143/fetch%3EUID%3E/staff%3E26 I suspect you want to use "imap://mailservername:143" as the site name in prefs here.
To be precise, the "The sites line has this format:" part of http://www.mozilla.org/projects/security/components/ConfigPolicy.html says: Don't include the path portion of the URL (the / after the host name or anything after it). This page should probably mention that you need host:port for non-default ports, though. I realize that "143" is the default IMAP port, but the IMAP code never tells the necko URI impl that, so... That's probably worth filing a bug on.
Jim: I don't have that kind of capability. Can we please agree on two points, and not debate them further? 1- The security hole is valid. If you don't understand this risk, please read the related bugs and/or file a Documentation bug. 2- The bug is valid. The errors need to be handled by somthing other than JavaScript Console. Too many people complain about this not making sense. That being said, lets talk about the solution implementation only. I will try to do a dupe cleanup this month, which will accurately reflect the number of dupes this bug actually has.
Ben, yes, I agree with both of your points. So, here's hoping you clever Mozilla programmers will agree on a course of action! Anxiously awaiting, The Users (well, at least this one, and the hundred others who've Commented on this bug)
bz - I can confirm that it works for both http and imap using the syntax you quoted. Timeless' comment#206 to do with excluding access to the local HD needs to be factored in. This patch would fix bug 135830. As far as user-visible notification this, as commented elsewhere, needs to show only when the user has actually clicked on a link, not at other times.
In case someone wants to create UI that won't crash the app, the right place to do something is probably in nsGenericElement::TriggerLink. That could either pose a dialog (poor, imo) or dispatch an event on security check failure that the UI could use to pose the dialog. In fact, someone could get spiffy and use said event to pose a dialog that would offer to whitelist that site (using say the caps patch I attached) and call click() on the anchor if the user decides to whitelist. That does somewhat defeat the purpose of the security check, of course....
Perhaps, given the hooks, this dialog could be supplied as an extension?
I am heartened at the recent surge in activity on this issue and hoping a solution is forthcoming! Ben's comment #212 is right on the money.
Hear, hear! This bug is not about whether the security restriction should be there or how it should work, it's about the fact that *if* something is blocked, for *whatever* reason, the user should be made aware of what happened! When I ask a program to do something, it should *never* *ever* just fail to do it without any response or explanation whatsoever. It took me hours to debug this problem and having found this bug report I can't believe that it is now two and a half years old and still NOTHING has been done about it...
*** Bug 233102 has been marked as a duplicate of this bug. ***
I've filed bug 233108 to track the patch in comment 194, since people seem intent on having this bug be about something else and since it's pretty clear that no patch will ever go in that is attached to this bug.
This patch doesn't compile probably for a very obvious reason but I keep going round in circles and work-related projects are limiting my thinking time - anyone spot the problem or is it beyond help?
*** Bug 234996 has been marked as a duplicate of this bug. ***
*** Bug 236823 has been marked as a duplicate of this bug. ***
I understand that the security issue is that there is not as much protection built into "file:///" and there is in "http://". If that is the case, why not modify the software to give both the same security features? That way Mozilla can access server based files just like IE and other browsers out there. Lets face it, in the Enterprise environment servers are going to be used as storage resources and "file:///" will have to be used to access those files, whether Mozilla.org people approve of it or not. So either Mozilla.org programmers find a way to make this transparent to Mozilla browsers or Mozilla will fade out and never make in the Enterprise environment that corporations are working in today and will be working in tomorrow!
*** Bug 242409 has been marked as a duplicate of this bug. ***
(In reply to comment #218) Well, by now the bug is 3 years old, and while it appears some work has been done to fix it, we users still don't have a workable solution. Any chance to get this fixed in 1.8? I keep having to go back to one of the earliest comments: yes, linking to local or LAN file:// URLs is often a perfectly legitimate thing to do, at least as legitimate as the use of cookies. Now with cookies users have the option of allowing them based on the site trying to set them, and on a variety of other criteria. The use of file:// URLs brings more security risks than cookies, so the security controls open to the user should be at least as fine-grained as those for cookies. Simply denying the use of this important functionality is of course not an option. But just opening all doors wide via the "checkloaduri: false" setting isn't either. Looks like by now everyone agrees on that. But how can implementing the interface be so hard, given that it already exists for cookie- or popup-handling? And why was there so much initial resistance to doing this?
*** Bug 247269 has been marked as a duplicate of this bug. ***
Can you please implement comment #88? This would be the perfect solution (having a list of sites which can point to local files just like what mozilla has for cookies, etc). As it is, this very bug hits me several times per day :-(
*** Bug 249295 has been marked as a duplicate of this bug. ***
As I had yet another discussion about this bug/feature with a customer today (seems like a neverending story to me), I second the numerous requests for some sort of message being displayed to the user if a 'file:' URL is deliberately not opened by Mozilla/Firefox.
*** Bug 252573 has been marked as a duplicate of this bug. ***
I just hit this problem today. Luckily, I was looking at the Javascript console or I would never have figured out what had happened. Mozilla really needs an OVBIOUS error dialogue when it does not want to load a file. I'm using Mozilla 1.7 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616
What is the problem here? Three years, two months and ten days and the problem still needs to be properly addressed . . . and fixed! When someone not on a local net clicks on a "file:" URL, his/her browser is going to try to open same on that or a LAN computer -- not on the server or on some computer not on that particular local network. For instance, on one page I have a link to "file:///C:/analog/statistics.html" which works for me since I have such a directory and such a file on my C: drive (and I have modified my copy of Mozilla). But if you do not have such a subdirectory and filename on the particular computer you're using, when you click on that link with a modified copy of Mozilla, you should get a "The file /C:/analog/statistics.html cannot be found" message. As has been emphasized at vast length here, if you're using an unmodified version of Mozilla, then you get absolutely nothing. I agree that if one is using an single computer for business/personal uses and as a web page server, THEN there's a problem -- a problem correctable with the purchase of a cheap computer to act as a server and some decent firewall software. But hindering Mozilla's functionality to serve such a small base would seem unsupportable.
Roger Pariseau: I completely agree... but, as a sidenote, have you filed your vote for the bug? Have you seen bug 163993? It tracks most-voted and most-CC'ed bugs... so, attention is actually being paid, to at least some extent. If I had infinite time, I'd jump in and take a shot at learning the codebase and fixing it myself - but in my current incarnation I don't think it's in the cards.
*** Bug 259285 has been marked as a duplicate of this bug. ***
*** Bug 260130 has been marked as a duplicate of this bug. ***
I am using Firefox 1.0PR I tried adding the following capability.policy lines to my user.js in the hopes to allow my intranet servers to link to file:/// links on UNC file shares in our intranet. user_pref("capability.policy.localok.checkloaduri.enabled", "allAccess"); user_pref("capability.policy.localok.sites", "http://myintranet"); user_pref("capability.policy.policynames", "localok"); The error message shown in the javascript console is the same as always: Security Error: Content at http://server1/test.html may not load or link to file://///server2/file. I also noticed that the capability.policy settings do not show up in about:config even though all the other settings in my user.js do show up. I actually went and tried the following: user_pref("c", "test"); user_pref("ca", "test"); user_pref("cap", "test"); user_pref("capa", "test"); user_pref("capab", "test"); user_pref("capabi", "test"); user_pref("capabil", "test"); user_pref("capabili", "test"); user_pref("capabilit", "test"); user_pref("capability", "test"); user_pref("capability.", "test"); user_pref("capability.p", "test"); and the last two entries (anything after the word capability) are not listed in about:config even though other settings included in the same user.js are listed in just fine in about:config. Is this CAPS patch not in Firefox 1.0PR? Is there some sort of overall CAPS enabling setting that must be turned on first? Does this fix only work on file links to local files not files using a UNC path? Am I just doing something silly wrong? Any ideas?
Daniel - I never got pref.js/user.js to work for Firefox (only Mozilla). However, this should work, and is easier: 1. Type about:config into your Mozilla-based browser's Address bar and hit Enter. 2. Find the security.checkloaduri preference. 3. Change the value to false (This fix seems to work for Mozilla's Firefox as well as Mozilla proper.) Someone posted this on our internal twiki (at work), so I don't know where he found out about it, but it seems to work.
Heh.. actually, it is listed in a comment above. I can use security.checkloaduri, but it basically opens the computer wide to allowing any website to have access to the file:// protocol which I don't want to do. The concept of the CAPS selective permissions is a good idea in my opinion, and I was disappointed that I couldn't get it to work. Thanks very much for the attempted assistance. Hopefully someone who knows about the CAPS implementation (or lack thereof) in Firefox will comment soon. (In reply to comment #238) > I never got pref.js/user.js to work for Firefox (only Mozilla). However, this > should work, and is easier: > ... > Someone posted this on our internal twiki (at work), so I don't know where he > found out about it, but it seems to work.
So after 3 years this bug is still marked as NEW, and I now can click a link off any untrusted site which will auto-install extensions into Firefox, but I can't make my site link to a local file! Well done guys, now where's my copy of lynx. Mmm, lovely textmode browsing... TIM
@comment #240: Touché. IMHO this is a bug that should block aviary1.0, since it makes deploying Firefox in a business envirioment really difficult (you need to copy the user.js for EVERY user. How nice on a Terminal Server... And then that is even an "hack".)
I wholeheartedly agree. In fact I've already said the same thing about related bug 70871.
more than 3 years and no solution yet? with 1.0RC1 thing went worse again. local images loaded via 'img src="file://' and 'im=new Image(); im.src="file://' will be denied to (without even fireing their onError handler) What potential damage could a local image do? By simply denieing access to all file:// you successfully hinder dozends of usefull web appications. Any changes to userprefs is _not_an_option_. Why issnt there simply a "Site xyz requested access to 'file://whatever.jpg'." with options for Grant/Deny Access once/always. (and dont forget to report the users selection to the script)
Being able to load an image into an IMG tag is highly useful for previewing and it's harmless (keep reading to the end for why this is so). For example, click the "Browse..." button on an input type=file, read the value, then assign it to an IMG tag. Then you get a live preview. I also read the file into an Image object, get the width/height, then assign the image to the "backgroundImage" of a div element then set the div element's width and height. The most discouraging part of all this is that I've spent about the last 6-9 months making my website building software compatible with Mozilla as well as MSIE. The former as a way to encourage open source software as developing for IE only is much easier. Because I do a lot of complex stuff in Javascript that involves event handlers, rich text editors, etc. it took a lot (and I mean a LOT) of effort to get it to work in both browsers. I've been testing with Mozilla under the assumption that Firefox would work the same. Anyways, version 1 of Firefox launches and I may have to scrap the support for open source browsers because a big part of the app depends on live previews of images. I lose a lot of important functionality without it. So, I know that everyone is working **** this browser, and I want to commend them, but I also want to note that I've been working **** software that would help boost the open source software model even though, as a percentage of my clients, it is quite small. With several hundred thousands websites built on my technology, this could boost Firefox as well. I understand about linking to files being a potential security risk, but there are no direct exploits with loading an image. All you would know is that an image actually exists. If the file is not a valid GIF, JPG or PNG image, you could simply throw the "onerror" event off the image and not load it. There is no damage that I can see done by knowing that a valid image exists on a system.
Here's a "crazy" idea. Why not ship with the ability to open file:// allowed, and let anyone paranoid close the facility on their own? This coupled with the same alerts you get the first time you enter something into a form, go from secure to insecure http and so on; this would be about a trillion times better than we have at the moment. I'm not a C coder, but I am a programmer. I know this would be simple to do. It seems we're being held back by security evangelists who are content to relegate the need of an important feature based on an idealistic view of how things should be. The real-world users are being kicked because we want to do something that we're used to doing on IE and/or Netscape prior to version 7 and/or Opera and/or Konqueror and/or Safari and/or Lynx... It's been over a year since I first dipped my oar in, and still nothing approaching a solution - and this after the release of Firefox 1.0...
I second the options from comment #244 and #245. For something so useful (and a low potential for misuse), Firefox shouldn't be so picky. It should especially not complain if: - The URL is static and the user clicks on it. This could be abused by a virus (like download it and open the HTML docu and then click on a link to install). But I doubt that Firefox can help in this scenario. - If the destination is a Firefox window (ie. when it is a request to open the file in Firefox) unless Javascript can connect to another window (tabbed browsing?) because it mustn't matter what I load in another browser window. - And if you want to keep it tight, then there must be a simple option to change the behavior *AND* a descriptive error message *WHY* Firefox refuses to open the URL I just clicked on. Just silently failing is a bug.
This is a serious offer for US $1000 to anyone who can champion a change in the image processing code for Mozilla. This code will help improve Mozilla/Firefox and should not introduce any security concerns. Read to the bottom to find out how you can authenticate this offer. As I mentioned in an earlier post, I have spent 6-9 months writing Mozilla-safe code at great expense and I'm willing to spend a little more. I appreciate everyone who has worked **** making security an important issue in Mozilla/Firefox. The changes I am proposing would not cause security problems but would provide great benefits to user's of the Mozilla browsers. I think these changes should be made regardless of whether a monetary reward is offered but the reward is to help expedite this process. I need to know as soon as possible whether I should scrap my Mozilla compatibility code. To receive the US $1000 here is what needs to be done: 1. The updated code must make it into the actual release of Mozilla and Firefox. It cannot be a patch that must be compiled in. In other words, it must mean the approval of the Mozilla team. My apologies as I don't know the exact process that code changes must go through to become part of the release. 2. Mozilla/Firefox must be able to load local images into: (a) a Javascript image object (b) an HTML IMG object and (c) the background-image style of any HTML element. Currently, a silent error is being thrown that the user never sees if the image is loaded from a local drive or any protocol other than HTTP. 3. For security reasons, I recommend that if the image is not a valid GIF, JPEG or PNG file, that the "onerror" event is thrown on the image. I think some developers removed the ability to load local images because you could tell if a given system file existed by setting an image src to that file. By throwing an error on any non-image, this should remove this security concern. If you are serious about fixing this but have concerns about the authenticity of this offer, please email me at sunny@citymax.com. I will set up a trust account with our law firm McCarthy Tetrault. McCarthy Tetrault is a Canadian law firm but they have relationships with U.S. firms. I'll work out a way where you can verify this. I am the CEO of MeZine Inc. which owns CityMax and a number of website builders and website building technologies. Thanks, and please let anybody know about this offer who is in a position to expedite the changes. Thanks.
(In reply to comment #243) > What potential damage could a local image do? Please read the bug that made the change. The damage ranges from "crash the system" on some versions of Windows to "hang the browser" on Linux to "leak information about your hard drive to the server" on any platform. > Any changes to userprefs is _not_an_option_. Why issnt there simply a > "Site xyz requested access to 'file://whatever.jpg'." with options for > Grant/Deny Access once/always. > (and dont forget to report the users selection to the script) Because users don't read dialogs. Why don't we just ask the user whether the site should be allowed to reformat their hard drive while we're at it? (In reply to comment #245) > Why not ship with the ability to open file:// allowed, and let anyone paranoid > close the facility on their own? Because that would be equivalent to shipping with the ability to crash the user's computer (see previous paragraph in this comment), say. Note that the proposal in comment 247 is never going to get checked into the tree. Also note that in current trunk builds (and hence in Mozilla 1.8a5 and Firefox 1.1) you are able to allow sites access to your hard drive on a per-site basis. It will still be full read access, so the sites you white-list will be able to read arbitrary data from your hard drive (as well as the hang and crash issues mentioned above and all that). But if you trust a site enough that you trust it not to crash your computer, I guess you can also trust it to not read your files...
Why not simply add a yes/no question much like those for submitting unencrypted content to Google's query page? "This site is attempting to load information from your computer. This is usually a bad idea. Would you like to continue anyway? Yes/No. [x] Remember this decision for this site" Why's that a problem? Aside from the UI design itself, would the above satisfy everyone's impressions of this bug?
(In reply to comment #249) > Why's that a problem? Aside from the UI design itself, would the above satisfy > everyone's impressions of this bug? No. This bug is not about having a checkbox that says 'I don't care about security, just give me the file!!!'. This bug is about not hiding the error message when the browser applies its security policy. Go back to the top of the web page and read the description.
(In reply to comment #248) > Because users don't read dialogs. Why don't we just ask the user whether the > site should be allowed to reformat their hard drive while we're at it? Mozilla and Firefox actually have a fantastic way of preventing people from just hitting 'OK' without reading the dialog box, though. If you install an .xpi file you can't hit the 'Install' button straight away, and as a result you can't help but read the dialog. That's the sort of thing Microsoft would patent in a heartbeat!
(In reply to comment #250) > (In reply to comment #249) > No. This bug is not about having a checkbox that says 'I don't care about > security, just give me the file!!!'. This bug is about not hiding the error > message when the browser applies its security policy. Go back to the top of the > web page and read the description. Never the less, having a dialog about security as an alternative to silently failing is certainly one possible solution to the silently failing problem (what this bug IS about) and is preferable to silently failing. In fact, the original report of the bug suggests opening a new page with the error message. This page could also suggest how to avoid the error. It might as well be a dialog to allow the blocked behavior. So I do not understand why you said the security dialog solution doesn't apply to this bug. You could at least suggest what bug the proposed dialog solution DOES apply to.
> Also note that in current trunk builds (and hence in Mozilla 1.8a5 and Firefox > 1.1) you are able to allow sites access to your hard drive on a per-site basis. > It will still be full read access, so the sites you white-list will be able to > read arbitrary data from your hard drive (as well as the hang and crash issues > mentioned above and all that). But if you trust a site enough that you trust > it not to crash your computer, I guess you can also trust it to not read your > files... However, if Mozilla still silently fails, this bug will still be relevant. BUT now you have something useful to offer the user in a message and/or dialog: "Error: Untrusted web sites may not access your local data! If you trust this site, add it to the list of trusted sites" 5 possible buttons: Close (default) Close and do not show this error again Never Trust this site (adds to blacklist) Trust Once Trust this site Always (adds to whitelist)
Possible UI for this type of security error: Have y'all noticed how Internet Explorer is handling similar types of security errors in WinXP SP2? They beep and add a one-line tool-tip colored error message just above the the window content. The action of shifting the content window down makes it quite noticeable. If you click the message, you get more info and the option (if permitted) to allow the risky behavior. One actual IE message when trying to install Macromedia Shockwave Player: "This site might require the following ActiveX control: 'Shockwave Player 10' from 'Macromedia, Inc.'. Click here to instal..." Clicking the message gives a context menu of the following options: * Install ActiveX Control... * What's the Risk? * Information Bar Help Mozilla could do the same, or preferably use the status bar (it would need to be clickable).
Comment #250 has hit it on the head. The problem isn't just the security hole; it's the silent failure. Right now, guys, we've only got the ILLUSION of security... because you know what's gonna happen when someone goes to view their Intranet site, and they click on a link and it doesn't work? They're gonna say, "Oh look, Firefox/Mozilla is broken, they've f$*@ed it up, guess I'd better use IE." I watch it happen every day here at work, from Mozilla *supporters*. So, all that's really been accomplished right now is that people can stand back and say, "Well, at least it wasn't Firefox that caused the problem," when what's really needed is a way for users to be notified that they're asking to do something potentially unsafe. We're at better than three years now, and this is really more of a holy war now than a discussion - which is why I've kept my neck out of it. Can we at least agree that a noisy failure (i.e., an alert of some kind) is better than a silent failure? Huh? Please?
Okay my understanding of this issue as it pertains to image loading is this: 1. It is unknown how, but it is possible that, a malformed link could potentially link to and then execute a program, even if it is after a dialog that warns against it. This makes sense to me. In an effort to remove this *possibility*, all access to local files is restricted from pages that are sourced on the Internet. 2. The image loader uses the same url checking code (including the restriction to file://) as the "link code" mentioned above. Because of this, images cannot load locally also. But: 3. What I am having a hard time understanding is why images *have to have* the same restrictions as links. I can understand the restrictions on links since it is possible to execute arbitrary programs even if it happens after a confirmation button. But, since you cannot execute *images* loaded into a browser, why is this restriction placed on images? Now my first guess would be allocation of resources (it would take some work to allow access to images but not to links where the security is currently processed in one place) but is there any other reason? Is this an issue of inconvenience or is there a technical reason for disallowing images to access local files. Couldn't we modify the security restrictions on image handling code? I mean even if you did load a ".exe" file as an image, it would certainly just show a broken image since the browser can't read it. Remember, I am simply talking about loading an image into the browser. And yes, I know there are exploits with buffer overflows on images, but that has nothing to do with local file access. These buffer overflows are easier to exploit by simply putting the image on the Internet. So, thank you for your patience in following this. I just can't see any reason why loading a local image is a security problem? The only thing you are giving up at all is the width/height of an image and the fact that the image exists. At most, this could tell you what OS the browser is running by looking up a standard image but you can get this from user_agent anyways. And I realize that my "offer" has been blocked but I haven't seen a good reason for this yet. I have seen many well reasoned arguments against linking to files and potentially running them, but I haven't seen, as of yet anyways, a well reasoned argument against loading images from a local resource. I would like to hear one before I give up on this and all the work I've done to get Mozilla compatibility in my app.
Proposal for a solution: 1. If the URL of the current document is file:/// and the URL to load is also file:/// just open the second URL. Both files are local, so there is no way data can leave the country. If the new document is a binary executable, abort (with an error dialog). Firefox is for *displaying documents*, not to run programs. If the new document is something else, display it (don't run scripts and the like). 2. If the URL of the current document is http:// and the new URL is file://, abort with an error dialog: "Document tried to open local data". Don't fail silently. It doesn't matter how the new URL comes into being (JavaScript, Link, user click). Tricky part: Users should be allowed to type in a new URL. 3. If the current document URL is not http:// and not file://, then I can't see a way to open another do
digulla@hepe.com: stop proposing. you're wrong. you haven't thought this through. you're spamming many poor people and giving them false hopes. not all file: urls are local. file://///evil.hacker.com/attackhost/evil.html is not local to file:/// file:///afs/evil.edu/a/t/attackhost/evil.html is not local to file:/// file:///home/e/v/evil/attackhost/evil.html while conceivably local to file:///home/v/i/victim/ is not friendly and they both may not be local to file:///tmp
(In reply to comment #258) > digulla@hepe.com: stop proposing. you're wrong. you haven't thought this > through. you're spamming many poor people and giving them false hopes. Can we please focus on solutions here? I think everyone here has heard enough reasons why it doesn't work. I would like to hear how to make it work. > not all file: urls are local. > file://///evil.hacker.com/attackhost/evil.html is not local to file:/// > file:///afs/evil.edu/a/t/attackhost/evil.html is not local to file:/// > file:///home/e/v/evil/attackhost/evil.html while conceivably local to > file:///home/v/i/victim/ is not friendly and they both may not be local to > file:///tmp So you are talking about network filesystems here? Since I don't see any way for Firefox/Mozilla to find out if a file is on the local computer or not (I certainly wouldn't want that; when I mount a network drive, I know what I do), I suggest that we have to rely on the sysadmins here. While it's true that some innocent user out there might be burned by this, I'd like to ask that you judge the majorities: How many people out there have external FSs mounted which can contain malicious pages? Frankly, I don't like the idea to beat people into security with Firefox. In situations like this, where the vast majority suffers from a feature which can only harm in extremely unlikely situations, so be it. No computer software can ever be perfectly safe in all and every fringe situation.
>you can't hit the 'Install' button straight away, and as a result you can't help >but read the dialog and as the next step, you can't help but uninstall the product.
If I want others to use our WIKI on our internal LAN, I guess the best I can do is tell them to set up their user.prefs, or user.js, or whatever. Or maybe I can convince the Network Administrator to do this for me? Oh, that's right, he's a Microsoft Man. That's OK, I can send out an e-mail telling everyone what to do. Let's see, they have to figure out where their user.prefs file should be-- or can they type something arcane in a window now? What, there still isn't a menu choice, even an advanced one under preferences to set this up? Oh, yes, I can hear them laughing. Over two years ago I gave up on supporting Mozilla for the Wiki. Funny thing is, none of the folks using IE to access my WIKI have had their hard drives wiped out. I guess it's just impossible to find a solution and keep the purity of Mozilla. Don't get me wrong, I love Mozilla and use it every chance I get. However, I won't be one of those who bashes Microsoft for IE security glitches-- at least it does what I need it to do. (Please don't flame me too badly, gentle readers!)
Product: Core → Mozilla Application Suite
part 1: another symptom: Clicking on a bookmark toolbar item for a file:... URL doesn't even work. This completely ridiculous! "Security" that completely breaks functionality isn't security--it's brokenness. (But see my next comment.)
I wrote: > This completely ridiculous! Agh! (Lack of verb.)
(Part #2:) Suggestion: Track security level of operations requesting opening URL, modeling after the Java privileged block API. Hey, would the following idea address both sides of the problem (preventing arbitrary pages from requesting file:... URLs while allowing the user to request them)? Java Privileged Block API In Java, when some action requiring special priviledges is requested, the VM (effectively) scans the call stack back to some higher-privileged reference point and finds the lowest privilege level of all pending methods on the stack. That privilege level is used to attempt the operation. (For example: A browser's general applet support code has privilege to open arbitrary connections. When it loads an applet's code, it gives the applet code privilege only to open connections to one host. The socket-connection method checks the privilege of the call stack to decide whether to allow a connection. If the browser calls the connection method, the call stack has full privileges and any connection can be opened. When the browser invokes the applet, if the applet calls the connection method, the call stack has only limited privileges, and only certain connections may be opened. Note that if the applet calls some miscellaneous support code in the browser and that code calls the connection method, the call stack _still_ has only limited privileges, because the stack contains one or more stack frames from the applet. (There's also a way for browser code called from the applet to regain higher-level privileges if needs them to perform some action for the applet.) ) For more information on this Java mechanism see http://java.sun.com/j2se/1.5.0/docs/guide/security/doprivileged.html . Applying To Mozilla It seems that that kind of mechanism would be applicable to Mozilla. The equivalent of the call stack would be a chain of actions starting with a user input action (e.g., activating a link), going through various handling actions (e.g., invoking untrusted Javascript), and extending down to each of the possibly multiple URL-loading actions indirectly triggered by the user input action. Generally, user input actions (clicking on a button or link, or entering a URL directly) would reset the privileges to the highest level. Handling actions would reduce the privilege level appropriately, especially for actions that invoke or otherwise "listen to" untrusted code or data. Consider several scenarios: If the user clicks on a plain (non-Javascript) link, handling that click proceeds directly to trying to load the URL. Since user actionshave full privileges, and there are no intervening handling steps that reduce the privileges, any URL can be loaded. If the user clicks on a javascript: link, privileges are decreased before executing the script, so that if execution of the script then tries to load a URL, the URL load is attempted only with the reduced privileges allowed for scripts (probably also according to the source of the page containing the script), and some URLs might not be loadable. Similarly, the action of executing a script in a loaded page is a nested or chained action that has reduced privileges, as is loading images in a page. I think a model/mechanism like this could go a long way toward making Mozilla rationale (not refusing to load file:.. URLs directly requested by users) while allowing for security concerns to be addressed. Comments?
> Clicking on a bookmark toolbar item for a file:... URL doesn't even work. WFM Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6) Gecko/20041203 Firefox/1.0+
(In reply to comment #265) > > Clicking on a bookmark toolbar item for a file:... URL doesn't even work. > > WFM Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6) Gecko/20041203 > Firefox/1.0+ Oops. Never mind. It was a file:... URL that was valid in Netscape (4.x) when booted from Linux but not valid when booted from Windows, where I tried it in Mozilla and thought Mozilla was rejecting it. (However, this does show that Mozilla needs to give feedback for URLs that can't be loaded as well as giving feedback for disallowed URLs.)
Flags: blocking1.8a6?
we're not going to hold the release for this. setting the blocking- flag.
Flags: blocking1.8a6? → blocking1.8a6-
You frickin' well *should* hold the release for this. Otherwise (by past evidence) it's never going to get fixed. And it NEEDS to get fixed.
Gavin: they way this bug will get fixed is to get a working patch written and reviewed. I do not know enough about event dispatching at the moment to produce a working patch, so, unless you can write such a patch, please direct your efforts at finding someone that can.
Keywords: helpwanted
Well, marking for the next release then.
Flags: blocking1.8b?
Flags: blocking1.8b?
Flags: blocking1.8b-
Flags: blocking1.8a6-
(In reply to comment #270) > Well, marking for the next release then. Since we have been waiting since 2001 for this bug to be addressed, can we PRETTY PLEASE get some priority on it? Those of us who have intranets are dying out here! Our ONLY option is IE right now. Thanx!
You can always set security.checkloaduri to false, as suggested in comment #20. (Yes, I agree, that this bug should be fixed, but IE is not your only option)
Until such time as there is a MSI packager (bug 52052 or bug 268740) and some way of pushing out configuration defaults, there is no practical way to push out the suggested prefs change in a corporate managed environment (if you know of a way around this, please tell me!). However, if a simple update allows them to access the files from the intranet, then that becomes a more manageable way to enable this (since new users would get the fixed software, and not have to deal with default updates).
I'm a Unix guy, so I don't know how hard it is to create an .msi package, but from talking to windows sysadmins and developers, I gather it's not exactly rocket science. Certainly every single linux distribution has managed to include mozilla in their native package format (rpm, or deb, or whatever). But apart from that you can roll out any change the way we do it: When a windows workstation logs on to a domain, it loads a logon script from the domain server and executes it. That script can be modified to do whatever you need to be done (change prefs.js or the registry, install software, etc.). [Of course we don't modify the logon script itself - it just looks in a standard place for other scripts to execute]
*** Bug 241382 has been marked as a duplicate of this bug. ***
Flags: blocking1.8b2?
Flags: blocking-seamonkey1.0a?
You might shout at me for that, but if we were able to ship lots of other releases with that, we'll be able to ship an alpha of the new suite project with that as well. That doesn't mean that a good, tested and reviewed patch can't go in, but I doubt this will happen in the next two weeks (noone knows though).
Flags: blocking-seamonkey1.0a? → blocking-seamonkey1.0a-
*** Bug 292346 has been marked as a duplicate of this bug. ***
No longer blocks: majorbugs
*** Bug 301454 has been marked as a duplicate of this bug. ***
For Firefox, there's the locallink plugin that allows easily changing this behavior. After well over a year of Moxilla being my preferred browser, this has made me switch to Firefox, although I hate its general lack of configurability. There is now an alternative to using IE or waiting until the year 2525 for this bug to get fixed.
*** Bug 302426 has been marked as a duplicate of this bug. ***
*** Bug 303226 has been marked as a duplicate of this bug. ***
*** Bug 303104 has been marked as a duplicate of this bug. ***
Hi, Quite a lot of time and people asking for this bug to be fixed. We're just the n+1-th... Like many people, we have a search engine that produces Intranet file:///// links, and people complain about firefox not being able to open it (without any explanation). We were almost to believe that FireFox doesn't implement network shares links... We at last found that it was not a misimplementation, but a feature... Telling our people to modify a .js file is really _not_ an option. That fix is not safe anyway. But I'm wondering: I understood how file:// links can be harmful, but _can_ file:///// links be harmful? In particular, can file://///localhost/foo be harmful? If not, I see no reason why a mere check for 5 slashes be done, and just allow _that_ use, which is what the biggest majority of people are asking here.
#283: > In particular, can file://///localhost/foo be harmful? As I understand it (but I'm no expert in Mozilla's handling of URLs) all file URLs are treated the same and therefore have the same potential for harmfulness. In particular, file://///localhost/... is not less dangerous than other file URLs because you don't control the contents of your own hard disk completely - among other things it contains the browser cache into which an attacker may previously have injected a harmful file. That said, I don't think forbidding links to file-URLs is a solution. I looks like a band-aid. Mozilla should be able to open file links securely. I don't know what that would take. Probably some kind of compartmentalization. A rather extreme approach would be to treat every document on file://* as a site on its own: It can link to other documents but javascript cannot access them - just like javascript on one http site cannot access documents on another.
#284: > #283: > > In particular, can file://///localhost/foo be harmful? > > In particular, file://///localhost/... is not less dangerous than other file > URLs because you don't control the contents of your own hard disk completely > - among other things it contains the browser cache into which an attacker may > previously have injected a harmful file. But the problem here is _not_ the content of files: http:// urls can point to very dangerous files too you know :) The problem with file:///windows/system32/etc. urls is that special privileges _are_ applied, which can pose security issues. My question is hence rather "do file://///localhost/windows/system32/etc. urls apply special privileges too ?" I don't know, but I'd guess they don't (since with 5 slashes, the access to files would go through the network file shares stack), and hence a file://///localhost/ url is just not more dangerous than http:// urls.
Are special privileges applied to file-URLs? I don't think so, and in any case I am very much of the opinion that they should not be. But lets assume that file URLs are not more privileged than http URLs. Then they are still more dangerous than http URLs because of the mixing of data: Javascript embedded in a page on http://www.example.com/ can only access data (documents and cookies) from http://www.example.com/. Assuming that there is a single entity (person or organisation) responsible for www.example.com, they can only steal or manipulate data they control anyway (note that this model has a problem with user homepages - http://www.example.com/~alice may be able to access data from http://www.example.com/~bob, but lets ignore that for a moment). However, the file://-Namespace is not compartmentalized into sites. Javascript embedded in a page accessed via a file-URL has access to all documents accessible via file:-URLs. So if someone manages to get a malicious HTML file on either my local disk or on a file server accessible to me AND gets me to open that file, he has access to all files I have access to. I believe that treating the file://-Namespace as a single "trust domain" is wrong. (This is about the Javascript trust model only - if you start an exe file, it doesn't matter if you got it from the web or the local disk - you're 0wned anyway)
As has been said earlier, the first fix can be much more simple: Just provide a decent error dialog when Firefox refuses to open a file because of this. Preferably one which explains what is going on, why Firefox behaves this way and how to fix it (about:-page, add key, etc). The next step should be a set of regexp-items in the config plus a nice prefs page for it which say: site <regexp> is allowed to access files <regexp>. For example: site *.mycompany.com allowed file:///n:/some/dir This would work for javascript and anything else, it would be simple and as secure as the user and/or admins want it to be.
@comment 287: Hear hear! Finally a decent solution that should work and that won't take too long to configure. If FF can be installed remotely with these settings in place, maybe FF FINALLY can be used in companies to access the intranet. IMHO, this bug is one of the most serious ones. FF CANNOT be accepted before it's able to work with the intranets of companies.
hjp@hjp.at: I agree. The lack of compartmentalization for file: URLs is a problem regardless of whether web pages are allowed to link to file: URLs, and with proper compartmentalization, it would be fairly safe to allow web sites to link to file: URLs. See bug 230606.
Here we go again. Firefox 1.5 appears to have broken the ability to open files on a corporate server, using the file:/// URL option. At least I am not able to get it to work by making changes in all.js or entries in user.js. I am past caring about all the arguments about security, etc. The fact is that corporate environments need, use, and rely heavily on this capability whether the mozilla security purists like it or not. IF YOU REALISTICLY EXPECT CORPORATE NETWORKS TO EMBRACE FIREFOX THEN PROVIDE THIS CAPABILITY WITHOUT ANY HITCHES--BY NOT DOING SO, YOU ARE TELLING CORPORATE ENVIRONMENTS TO GET LOST BECAUSE YOU DO NOT CARE ABOUT THEIR NEEDS. As long as this requirement is not met, IE will continue to rule and mozilla will eventually be forgotten.
(In reply to comment #290) > Here we go again. Firefox 1.5 appears to have broken the ability to open files > on a corporate server, using the file:/// URL option. At least I am not able > to get it to work by making changes in all.js or entries in user.js. Yep, you're right. *Bangs head against wall* I use about:config to make changes, and having moved to 1.5 I can see that it has retained my setting for security.checkURI that made it work on pre 1.5, but it's ignoring it and not showing me intranet files again. *sigh* > I am past caring about all the arguments about security, etc. The fact is that > corporate environments need, use, and rely heavily on this capability whether > the mozilla security purists like it or not. To be fair, it's only been an active bug for four and a half years. Four and a half years of to-ing and fro-ing, security purists on one side and users who need the functionality on the other. I like the suggestion in comment 287, and it might get rolled into Firefox somewhere in the next four and a half years if we close our eyes and wish really hard and promise to be good to other boys and girls.
In ff1.5 you should use something along the lines with: (havn't tested myself) user_pref("capability.policy.policynames", "localfilelinks"); user_pref("capability.policy.localfilelinks.sites", "http://intranetserver"); user_pref("capability.policy.localfilelinks.checkloaduri.enabled", "allAccess");
(In reply to comment #292) The code is certainly an intuitive solution that anyone could easily come up with, NOT! Unfortunately I tried the code in my user.js but it still did not make any difference. If I can not get the functionality back, I will have to junk Firefox. > In ff1.5 you should use something along the lines with: (havn't tested myself) > > user_pref("capability.policy.policynames", "localfilelinks"); > user_pref("capability.policy.localfilelinks.sites", "http://intranetserver"); > user_pref("capability.policy.localfilelinks.checkloaduri.enabled", > "allAccess"); >
I just updated to FF1.5 and I have the same problems (access to from intranet pages to files on network drives). Can a firefox developer please have a look at the source, find the person who disabled security.checkURI without telling anyone (especially not us), notify the project administration that this persons access to the sources needs to be terminated? He's maybe not a security risk from a software perspective but certainly from a marketing perspective plus he made me look very bad at my current company. In the meantime, can someone with access to the sources please find and properly document a way to make this "feature" behave so the few thousand corporate users can work again?
(In reply to comment #294) >Can a firefox developer please have a look at the source, find the person who >disabled security.checkURI without telling anyone (especially not us), notify >the project administration that this persons access to the sources needs to be >terminated? Doubtful, given that the change was cleared by two top security representatives. >In the meantime, can someone with access to the sources please find and >properly document a way to make this "feature" behave so the few thousand >corporate users can work again? http://kb.mozillazine.org/Links_to_local_pages_don%27t_work
Yeah, this is fine. But can't local urls (file:///c:/windows/...) be disabled by default _without_ disabling unc urls (file://///servername/share) too? If not, why? (There had never been any answer on this) Do unc urls pose security issues too? (Same remark)
(In reply to comment #296) This appears to be the case of the tale wagging the dog. As a programmer, I have always been taught and have worked with the understanding that the software is to be written for the user as the primary goal and be written for the convenience of the programmer--when there is a conflict the user should win. Apparently the mozilla programmers to not subscribe to this philosophy. This is a demonstrated need for the corporate environment. Assuming that I have figured out the correct syntax (which I am not sure that I have) I would have to insert a lot of different sites to make this work. A typical corporate site has hundreds of different possible site/folders to be accessed. This is ridiculous to expect anyone to enter all those or to enter a unique string for every user--it is not going to happen. Like it or not the requirement exists, not withstanding the security risks. The mozilla folks should stop taking the convenient programmers approach of blocking the option. If as much time had been spent in designing a new approach as has been spent on defending their position, they would probably have had a solution already. If a programming solution can truly not be found, then they need to 1)make the "unsecure" approach easily enabled for even the novice; 2)publicize the hazards if the option is enabled; is At a minimum the mozilla prog; and 3)let the corporations make their own decisions. My bet is that the corporations will still use the capability because they can not get along without it and because other browsers (IE in particular) allow it. As I said this appears the mozilla tale wagging the corporate dog for their own personal purists' gratification. I can see no other reason why they are so adament against letting corporations make their own decisions. > Yeah, this is fine. But can't local urls (file:///c:/windows/...) be disabled > by default _without_ disabling unc urls (file://///servername/share) too? If > not, why? (There had never been any answer on this) Do unc urls pose security > issues too? (Same remark) >
To get this thing going, I just created bug #318775. Please have a look. If you like the proposed solution, get everyone you know to sign up for an account here and to vote for the solution so that we get a fix before Christmas.
*** Bug 318775 has been marked as a duplicate of this bug. ***
(In reply to comment #299) > *** Bug 318775 has been marked as a duplicate of this bug. *** > Wow! Ten minutes from posting to killing. Must be some sort of record! How about equally quick action in addressing this long-standing issue? I side with the folks who'd like to see user-selectable options from within Preferences.
I don't care for the killing. Give me your vote and when I get enough votes, I'll reopen the bug until it gets fixed :-)
(In reply to comment #292) > In ff1.5 you should use something along the lines with: (havn't tested myself) > > user_pref("capability.policy.policynames", "localfilelinks"); > user_pref("capability.policy.localfilelinks.sites", "http://intranetserver"); > user_pref("capability.policy.localfilelinks.checkloaduri.enabled", > "allAccess"); > And next snapshot it may be user_pref("some.other.really.long.place.youll.never.think.to.look", "securitymode_blowyourheadoff"); but the fact remains that we still need a real solution. Firefox/Mozilla has made an awful lot of headway - but *still*, nobody here can run it, if they ever need to be able to link to a filesystem object. People keep asking "but why would you ever want to do that?" I give you two answers: first, denying reality doesn't change it. Just ask the current U.S. gub'mint if ya don't believe me :) Secondly - you want a real answer? How about the fact that sometimes people want to put a "pretty" web frontend onto what is basically just a bunch of files on a fileshare someplace, and people outside the department don't know about the existence of that fileshare. And your IT department doesn't hand out write permissions to the webserver to the entire department, so storing the files within the webserver's space is pretty much out of the question. But, you'd like people who don't know about \\foo\bar\baz\my_dept_files to be able to get at some stuff from one of the leaf nodes of the company webpage. How would *you* propose doing that? Yeah, I know, a Linux box in the corner running Apache might be an answer - but someone's gotta run that, and provide backups for it, and so on, and so forth. Sometimes that works... and sometimes it don't. From this side of the screen, it sure looks like what the development team is doing here is shouting that the sky is chartreuse with lavender stripes. Clearly it isn't, because there are a whole lotta users of this planet who're saying it's blue, or occasionally grey or white or black - but not chartreuse. It might be nice to be able to go up there with a paintbrush and repaint the sky, because chartreuse and lavender might be prettier... but you've got your work cut out for you. I'd bet my annual salary that you'd be not be able to convince everybody at *my* company that would need convincing not to ever link to a file:// URL ever again... and that's just one company, and really not that big of a one. Call it a security risk, but let's face it... the only secure computer is one with no network connections and no peripherals. You have to, at some point, acknowledge some level of risk - and MORE IMPORTANT is the fact that this level of risk is not the same for everyone. Hence, the repeated - and by now quite long-toothed - request for a way to control this behaviour that's not an undocumented, cryptic moving target. (Just as an aside, has anyone ever run a report of "what's the oldest bug/misfeature that's still outstanding"? I gotta imagine that this one's pretty close.)
People, we're straying off topic. This bug is not about whether Firefox should permit access to file links or not, or whether it should require five slashes or only three. That's a different bug. This bug is about whether, having *already decided to block access*, Firefox should actually deign to tell the user what's going on, instead of just silently logging an error to the JS Console window (which nobody has open anyway).
Actually this bug is nothing to do with firefox, it's for the app suite...
Funny reading through this. I'm a IT dev for a midsized company and was trying to help a colleague work out why UNC links on an intranet page didn't work in FF when they worked in IE. Judging by the length of this "bug" I can see it'll never be fixed. I'm a Firefox user myself, however we will now be mandating a corporate policy that Firefox isn't a supported browser. I'm not going to hang around and follow this discussion - I have real work to do - I just wanted to let you know that this dumb policy is, well, dumb. Paul
What bothers me is that FF is built on the premise of being capable and flexible. Yet when we ask for an option (not necessarily a default, just a basic capability), the purist security faction limits such basic capability in the name of security. If we were that incapable of determining relative risk/benefits of certain options, I'm surprised we have the ability to run Java script, real audio, Windows Media files ... heck even image libraries have been exploited so perhaps we should not enable the viewing of images too. As an IT manager with an intranet that is a part of a busy and thriving enterprise, I see the need for this every day, not just sometimes. I don't want to exclude FF from our approved browsers because it won't work in a simple business application like accessing files on a network share. For our needs (and I think the needs of most businesses that want to use FF), we really need an option in the GUI (not lost in the user prefs) to enable linking to network shares, perhaps with a dialog saying "you are about to perform an unsafe operation", but with the option to "remember this action" or otherwise permanently dismiss it after the first time. We have multiple file servers and we need the ability to use a web server to help centralize where files are located for day to day use. Everything from expense report forms to document-controlled data is distributed throughout the enterprise, we need an efficient way to get to them.
Adding "This is NOT about enabling file: URLs but about a clear error message." into the Status Whiteboard, hoping that posts like the latest two posts will not appear again. file:/// URLs can already be enabled in about:config.
Whiteboard: This is NOT about enabling file: URLs but about a clear error message.
You are correct. To bring my comments more in line with the scope of this bug, please add the file:/// URL enabling capability to the dialog alert box then. Sorry for the OT rant.
Re #305: With FF 1.5, File URLs can *not* be enabled with about:config anymore. You have to edit prefs.js (user.js won't do either) with a text editor, merge some arcane strings with other arcane strings and restart FF 1.5 about five times until it starts to work. As for those who want a nice UI to enable file:///-URLs, there's but Bug 318775 for this. If there is enough interest, I'll reopen that one again. Right now, nobody seems to be really interested.
That re should have been for #307. Sorry for that.
I have read the latest comments with interest. I feel like those who control what is and is not incorporated into Firefox are trying to play slight of hand with me. The bug report #84128 and is basically about people finding out they can not easily access files on corporate file servers and then they find out that they are knowingly being blocked without any kind of notification. Some where along the line bug report #122022 got broke out which supposedly deals only with the fact that Firefox does not easily permit access to files on corporate file servers. So now we have at least two bugs (there may even be more as noted in another recent comment) on this tree because file access is not permitted and no user explanation is given. I find the comment that no one is interested to be a bit humorous, considering how long the comment list is on this issue and how long it has been around. What is so difficult to understand here? Until files on corporate file servers can be easily accessed by the novice user Firefox of any version will not be a supported broser in the corporate community--where I work is a typical example. If the access is intentionally blocked as it is now, then stand up and notify the user--be up front about it so they will stop blameing their own corporate support people!
This may be a silly question, but I don't see it mentioned anywhere here. It's not that Firefox doesn't allow file:/// locations, it just won't link to them. If I copy and paste the link to the location bar, Firefox will then display it as I wanted. So Firefox is not actually more secure by disallowing these links, it's just frustrating the user. Can Firefox really not tell the difference a user pressing a file:/// link and a potentially malicious server trying to access the local file system? While I'm at it, I've noticed that by adding file:/// to the *Always-in-IE sites* list of the IE View extension, this problem is less annoying. However does this completely circumvent the Firefox security? Will servers be able to exploit the IE security weaknesses or does it require me to press on the link?
I doubt that it opens any security holes from Firefox's point of view, as I would be astonished if JavaScript code running on a Firefox-rendered page could go talk to content loaded in an IE-rendered page. (Though I guess it's possible. I don't really know.) Of course you've still got the security hole of using the IE engine in the first place :) But remember: this bug is about getting an error dialog. There are other bugs filed about whether or not it should even be blocking this sort of thing. It's hard enough just getting a freakin' dialog added. :(
Comment #30 is the best idea in my opinion. We should have a dialog and a CHOICE to open local files via 'file:' links. <rant> I am really tired of this issue. I have been trying to push Firefox in my company for over a year now and this one issue is preventing it from being adopted. Please help me out here. I understand the security implications, but PLEASE give the users a choice! I have Firefox 1.5 and tried the user_pref options described at http://kb.mozillazine.org/Links_to_local_pages_don't_work and could NOT get it to work. I tried both editing prefs.js and using a user.js file as explained here: http://kb.mozillazine.org/User.js_file As far as I can tell, there is no work-around for this in Firefox 1.5. </rant>
Mmm, there _is_ a work-around: the LocalLink extension: http://locallink.mozdev.org/ , which adds a popup menu for opening such links. But it is a bit tedious to use, compared to just clicking on known-to-be-safe links.
Not to stray too far off topic, but I can't get Locallink to install in Firefox 1.5.0.1. Only revs up to 1.0 are supported?
(In reply to comment #316) The author has stopped supporting locallink. Try the Launchy add-on for Thunderbird. I tried it with Thunderbird 1.0.7 and it works great: http://mozdev.elliptic.fr/launchy/launchy-420.xpi
(In reply to comment #317) > (In reply to comment #316) > The author has stopped supporting locallink. Try the Launchy add-on for > Thunderbird. I tried it with Thunderbird 1.0.7 and it works great: > http://mozdev.elliptic.fr/launchy/launchy-420.xpi > I'd like to once again be able to load file URLs from *firefox*, not from a different program (Thunderbird). Am I correct in understanding that in Firefox 1.5.0.1 there is *no way* to load a file URL?
(In reply to comment #318) > (In reply to comment #317) > > (In reply to comment #316) > > The author has stopped supporting locallink. Try the Launchy add-on for > > Thunderbird. I tried it with Thunderbird 1.0.7 and it works great: > > http://mozdev.elliptic.fr/launchy/launchy-420.xpi > > > > I'd like to once again be able to load file URLs from *firefox*, > not from a different program (Thunderbird). Am I correct in understanding > that in Firefox 1.5.0.1 there is *no way* to load a file URL? > Please excuse: I notice I omitted something in my reply #318. I meant to ask: Is there no way in Firefox 1.5.0.1 to load a file URL *by clicking a link* in a web page. (Of course one can load a file URL form the File Menu -> Open File option of the browser.)
(In reply to comment #319) > I meant to ask: Is there no way in Firefox 1.5.0.1 to > load a file URL *by clicking a link* in a web page. (Of course one can > load a file URL form the File Menu -> Open File option of > the browser.) I've got it working OK on Windows. I had to create a user.js file in my profile directory and put the following in it: user_pref("capability.policy.policynames", "localfilelinks"); user_pref("capability.policy.localfilelinks.sites", "http://www.example1.com http://www.example2.com"); user_pref("capability.policy.localfilelinks.checkloaduri.enabled", "allAccess"); I got that information from the pages linked to in comment #314, dunno why it didn't work for the author of that comment.....
It also works in seamonkey 1.0 Linux. You can also add 'mailbox://' to the list of allowed sites to enable local links from your mails in mailnews. This solution is far more secure than what we had before. If there just would be that little popup that tells you why you don't get a link (btw, that is this bug) and how to change that , it would be even nicer for an unexperienced user....
It also not works for me. I created a webpage that has one hyper link as: <a href = "file://///thamhnguyen/temp/BuildError.txt">Test</a> Open my page in FireFox (ver 1.5.0.6) and click on this hyperlink, the javscript console show a Security Error. But if i open this page and run in IE, it can open my file. Would you please give me an idea? OS: WinXP-sp2
As we are getting more and more online services to organise our life, it would be useful to have either a pop-up telling us it is broken, or have some kind of solution built in to allow this functionality to work. For me, I have started using the Backpack service from 37Signals. Now, as I am using it more, I am starting to put links in there to local files on the works LAN so that I can get to them easily. It is a real bind to not simply click the link and away we go. For now I have implemented the solution as suggested in Comment 320, re: editing your user.js to allow a site to function. But it is a case of remembering this fix when you upgrade to a newere version, and potentially overwrite any existing user.js settings. Using Firefox 1.5.0.6 provided from PortableApps.com and running from a USB key.
(In reply to comment #41) > I agree completly. In the example "file://ftp.cs.da/edu/htmlasst" if ftp.cs.da > is not the localhost by which protocol should this file be accessed? > > ftp? only a guess because of the filename. > smb? because of what information? What do the current IETF RFCs say about the "file:" scheme?
(In reply to comment #324) ... > What do the current IETF RFCs say about the "file:" scheme? Oops--posted to wrong bug.
(In reply to comment #324) ... > What do the current IETF RFCs say about the "file:" scheme? Oops--posted to wrong bug report.
Coming up on ... wait for it, *six years* now... I say to you now - does anyone object if I take this godforsaken bug and add in a dialog which says something like, "You have clicked on a link to a file on your local filesystem. This is disallowed by your security settings. To change this setting, go do XYZ." As long as that dialog is there, I'm not sure I really care if it requires that they go twiddle about:config - as long as the information presented in the dialog is CORRECT. (See also the Dilbert cartoon about the user interface punishing the users...) Would that really, truly be so horrible?
OMG, can you actually do that? I know this whole thing is open-source and all, but you are a GOD if you can actually make that patch and get this *&$%ing thing "fixed". 6 years? That's brilliant...
A dialog? yes, horrible and would get vetoed by the UI czar. An infobar would probably fly.
Or maybe an error page.
If an infobar is the yellow strip that appears at the top of the page, like when a popup is blocked, then that would be great.
(In reply to comment #327) > Coming up on ... wait for it, *six years* now... > > I say to you now - does anyone object if I take this godforsaken bug and > add in a dialog Yes, some firefox guys will kill you for that. They will do *anything* to prevent a fix for this bug to be included in FF. To hell with them. Let's continue the discussion for a *solution* on bug 318775 because this one here takes way too long to load and too many people are in the CC list.
Why has this bug not been fixed? I don't understand. It's clearly undesirable for any piece of software to have such an anomaly in it. Clicking on a link in a browser and having precisely *nothing* happen means that the browser is broken. No ifs, no buts - it's broken. There should _always_ be some kind of feedback when you click on a link, even if it's to pop up a dialog box or an infobar telling you that you can't follow that link.
(In reply to comment #332) > Yes, some firefox guys will kill you for that. They will do *anything* to > prevent a fix for this bug to be included in FF. Can I get a FF developer to sound off on this? Here's why I ask. I realize that the need for this is "stupid", etc., etc., etc. Reality is what it is; particularly, not every single system that every single corporate web developer needs to reference files on is running a webserver (what? they're not all running Linux/Apache?!? ohmigod!) so they end up referencing Samba shares. Such is life: Software developers who attempt to redefine reality to fit their view, instead of writing what their users genuinely *need*... well... you figure it out. I've inadvertently made that mistake myself. So it's like this. I will happily spend time trying to fix this RIGHT. I will not waste time trying to come up with a **** workaround that will work for some people, some of the time, until something else gets changed that breaks it. And yes, I'm referring to the actual bug described here - I'm not even talking about GETTING TO THE LINKED FILE, just making sure that a user knows that they don't just have a case of "gee, Firefox is busted, guess it sucks". This bug still trips *me* up - you think that a casual user is gonna do better? So if we can come up with a happy way to fix this, I'll learn enough of the codebase to figure out how to do it. Infobar, dialog, little green animated man... I don't really care. FEEDBACK, that's the important part... not the electronic blank stare. If the answer basically is "we like obscurely punishing people for doing things we think they shouldn't have done in the first place", then wow, I guess I'll have to start finding another direction to go other than Firefox. Not because I desperately need this feature - at my new job I don't do web development anymore, at least not now - but because it signals to me that there's something fundamentally broken about the design and implementation process for this software that is not able to be overcome, at least not on a level that I can influence... and that spells bad things for the future. Most people - even many geeky types - don't learn if the software is acting broken. If the software tells them "dude, don't do that and here's why", maybe they'll have reason not to. Otherwise (and prepare your flamethrowers gentlemen), they'll have learned the *correct* lesson when their co-worker says "But it works for me in IEeeeee!" which is that Firefox is broken: again, not because it won't let them click on the link, but because it ACTED broken. It didn't tell them that it even noticed the click. It didn't do any of the things that it does when the user does any of the other varieties of security breaches. Why is this one case special? Okay, enough ranting. With any luck my diatribe will have gotten someone's attention who can give me the yea or nay.
You either send an observer notification like blocked installs http://lxr.mozilla.org/mozilla/search?string=xpinstall-install-blocked or you fire an event like blocked popups http://lxr.mozilla.org/mozilla/search?string=DOMpopupblocked ...either way you catch it in the browser and twiddle the notification box with an appropriate message. Events have the advantage of targeting only the offending browser window, observerService has the advantage of being a core XPCOM service (although I guess CAPS is already pretty intimate with the DOM). You send either message in nsScriptSecurityManager::ReportError, but only for CheckLoadURI errors so check the messageTag.
In reply to comment #335 and comment #336: I think it's a bad concept to trigger an event when nothing happened: An event is the proper reaction if something happened. Wouldn't it be the easiest thing (as suggested in my report (Bug 368974)) to change the mouse cursor when hovering over an URI that won't open to something like a "no entry icon"? At the moment the user visible feedback before clicking is just identical to that of a valid UTI, and that's an absolute NO NO. Just imaging you computer's power light stays on if you turned off the computer: You would try to power it off again and again... just as users will try to click on such URIs again and again.
There are two separate use cases in play here. The first one is where a regular Internet page tries to use file:// URLs in IMG tags, IFRAMEs, JavaScript, or anywhere else, without user interaction. This should bring up a security bar at the top saying something like "some content on this page was blocked because it would violate security rules" and have a button that would show you specifically what the page tried to do. Basically treat it similar to blocking a popup. The second one is where a user attempts to navigate to such an URL by actively clicking on it. This one is more debatable. If it can be absolutely determined (and not spoofed by JavaScript doing a link.click() or similar) then I'd personally prefer a messagebox. If it is spoofable, though, or people are opposed to messageboxes, then bring up one of those bars -- again, it's similar to someone clicking on a javascript:window.open() link when popups are being blocked. Although another interesting UI comparison might be what it does if you try to go to a site (or load content from a site) using HTTPS when the certificate has been specifically revoked or forbidden. (I'm not actually sure what this does, as I've never encountered it.) That might be a closer equivalent, although they're approaching from different angles (one is blocking a site from loading itself because it can't be trusted, the other is blocking sites from loading local content because they can't be trusted).
Interesting points, Gavin. I'm inclined to agree that an error page makes more sense than an information bar for the "clicking a link" case, especially since that's the UI we're planning to use for broken HTTPS in bug 327181. I think the fix for bug 230606 will let us to get rid of the prohibition against links to file: URLs in Firefox 3. The UI for Firefox 2 is unlikely to change. So maybe we shouldn't worry too much about the UI yet :)
#338: And don't forget the links from mailnews, where it is most used (e.g.,links to local resources in mails to group members) and should give some kind of response, too.
(In reply to comment #337) > Wouldn't it be the easiest thing (as suggested in my report > (Bug 368974)) to change the mouse cursor when hovering over an URI that won't > open to something like a "no entry icon"? At the moment the user visible > feedback before clicking is just identical to that of a valid UTI, and that's > an absolute NO NO. I have no issue with that, as long as there's some way for the user to figure out *why* they're not being allowed to click on the link. Otherwise, again - "I can click on this in other browsers!"
I don't know how to properly update Bugzilla, but this bug probably doesn't make much sense since support for security.checkloaduri was removed in Firefox 1.5: https://bugzilla.mozilla.org/show_bug.cgi?id=307382 A nice knowledge base article is here: http://kb.mozillazine.org/Links_to_local_pages_don't_work Hopefully anyone else following my footsteps can save some time by reading this comment.
(In reply to comment #342) > I don't know how to properly update Bugzilla, but this bug probably doesn't > make much sense since support for security.checkloaduri was removed in Firefox > 1.5: https://bugzilla.mozilla.org/show_bug.cgi?id=307382 A nice knowledge base > article is here: http://kb.mozillazine.org/Links_to_local_pages_don't_work That pref has nothing to do with this bug. This bug is about the CheckLoadURI _function_, which is used for security checks throughout the Mozilla codebase. That pref was a switch that allowed people to effectively prevent the function from returning failure under some circumstances, which is why it was dangerous.
For example, CheckLoadURI() can fail on other types of links that cannot be enabled through a pref (e.g. chrome:) or fail in certain contexts (e.g. javascript: links are allowed in some places but not others). This bug is about the lack of user feedback when these checks fail, file: links are simply a common cause for this complaint.
(In reply to comment #15) > I've got internal pages which are compilations of links to local content. > If some feel this is a security problem, pop up a confirmation dialog to > make sure the user understands. Totally ruling this out is anoying.
Flags: in-testsuite?
Flags: blocking-seamonkey1.0.10?
This is not blocking any release, just as comment #267 and comment #276 already explained (apart from the fact that there will be no official 1.0.10 release).
Flags: blocking-seamonkey1.0.10? → blocking-seamonkey1.0.10-
Unbelievable ;) - There are no good user frontends possible without a preview! - Its a severe security hole that the user cant judge what he uploads before actually sending it to the server, - I cant see how this can cause security problems if you add a user-dialogue in front of any action (if you dont like the global security-switch make it more specific, like the popup-stuff f.ex) - How can anybody spoof anything if this got to be user-enabled first?? (BTW its more secure if the user sees that a site would start to do nuts!) - Never thought that the mozilla folk is that squareheaded!! (just look at the list of bugs with that issue and the period of it) YES, this is really a serious BUG and NOT a security feature!! - No i dont want to install a CGI workaround because this is NUTS because users tend to make errors and uploading something unwanted because its impossible to see what gets uploaded... but im going to repeat myself, sorry.... OK folks, keep up the good work and dont forget about the important details!! best regards, bjoern.
bjoern, your web app can use the API added in bug 371432 to show previews for files that have been selected in a file upload control. Please read the comments in this bug to understand why allowing access to all file: URLs causes security problems. Adding warning dialogs is almost never a good solution.
Hi Jesse, thanks for answering! ...but maybe i misunderstood but thats not what want. I want a webpage f.ex. with an image on it, a file-input-button and that the webpage should show the user locally selected image instead of the old image THEN the user can decide if he presses the upload button somewhere else in the form or not. (cant see that beeing a security prob ;) anyhow if - you folks did some weird programming ;)) Anyhow, i tried the 371432 but couldnt make it work somehow within the above scenario. Maybe i even need a more dummy-like explanation or better examples... BTW, even if that approach would help somehow i doubt that that would work with Opera nor IE, to make it clear I WANT THE SAME AND CONSISTENT BEHAVIOR within all browsers since i dont want to play the MS game to make the users use only 'my' browser because of weird features. Thats not the spirit of free SW! ;) Dont take the following too personal but i cant leave it uncommented - "Adding warning dialogs is almost never a good solution" were the last words of an unknown software engineer in tshernobyl... ;)) Yes, and sure - all user actions do cause risks, and sometimes even security problems ;)) REGARDS! (and please dont be sooooo squareheaded anymore!!)
Hi again, i've read within so many bugs now, i FEEL buggy ;) Ok, since i've received few answers and probably got somehow misunderstood i'll try my luck again with other words: The input-file in a form should not be set somehow by some webpage, server or whatever (actually seems to be the normal behaviour anyways) If this is the case i can not see why this will cause security problems, because if the browser prevents presetted somethings there the page cannot spoof anything via that object. If this input field gets a (browse) click, it probably was the user (if not, maybe thats the security hole ;) but then the realm is clear, its a local request from the local user and the user should be able to start local tasks, otherwise the browse is useless. (And yes, we dont need a warning then - sorry MY fault ;) This leaves still the question, if we have a local event within a local realm WHY cant i preview that file? (What i really want is to have a dummy-image or old-version within an upload form which shows the new image before uploading but after got user-selected within the file-input (BTW, up to now none of my users ever tried to type in the path manually - seems to be a geek option anyways ;). To get an idea of the content-size would make it even better to know the x/y-size perfect. ;) This already worked for a while pretty well (about 10 years? ok, i began my first 'webapps' with hyperG if anybody remembers ;) with rewriting a part of the form/webpage and asking the then its size etc.pp. BUT you actually stole that feature and a lot of (my) customers now complain that the software got broken. Background, most errors within frontends i found out were unsupported file-types (tiff, psd etc) wrong sizes (like hundred MB-pics) or the wrong x/y-proportions ( thats main reason why i really need the user to look at before, so fileList etc. doesnt help that much). OK, i can make the server resize and resample and even convert all this but i think this to be very ineffective (load, cpu-time, unproportional or suboptimal pics, etc.pp) I do understand that an unconditional link to a file://-location causes risks, but why is it that complicated to check if this special file:// was caused by a local user action?? (f.ex a little temporal list -per form?- which file://whatever within this document was user-selected and is ok to give somehow an answer or be linked to?? The little list-structure can even be deleted with the form-submit, the onChange of the file-input or any other ending-criteria you folks like - no mem-problem nor global securit-model question nor other issues i could see so far :) - and i really dont want to program a local file-manager within js, i would java then anyways..) So let me explain the square, globally seen the file-protocol is insecure and in most cases you are totally right. But not in this special case (and there are probably some more) where the security-context is clear and so easy to solve. (thats the creativity-part i was complaining about) and i cant believe how many discussions it got without an easy solution by getting into detail whats really needed and when. For further use of similar scenarios, like user enters a pdf and a (dependeant) popup-win shows up (yes, before uploading the form:) with the pdf (or any other object on could think of) i'm not quite sure if i will insist in 'thats no secprob' because of the various possibilities of the DOM but its a definitive 'would like to have' too. Please let me know if i'm on the complete wrong track with this point of view, what error i made with my thoughts or why its impossible to produce that dynamic and very temporal little list within that realm, i actually most fear that kind of quiesence here - i would have produced a massive flame war with this within the last millennium ;)) Best regards ;) bjoern.
I agree 100% with the original poster: > When a user clicks on such a link, the user must be told why the > action failed, otherwise the user is confused. I wasted a lot of time trying to figure out why a file:// link wouldn't work in Firefox. It would have been so much nicer if a msg was displayed on the status bar, the error console automatically opened, a pop-up msg was displayed ... anything would have been better than that silent failure. Without getting into any of the security issues raised in this thread, it seems to me that giving the user feedback for why an action was blocked would be a Good Thing. I like the suggestions in comment 338, but any kind of feedback would be better than the current situation.
We are using a wiki as our intranet where all of our processes and forms are kept. Given this, we have links to the files that are attached and it fails due to Security Error. This has made Firefox null and void for us to use as a company even though I was trying to roll it out across all users. They have to go to IE for wiki work. I wish that there was a way to allow a user editable list of acceptable file locations (in our case it is a share drive that must be mapped as "W:" to find the files. This way we can use Firefox with our wiki. Any ideas on how to do that? Thanks for your time! Angela
1) Read the whiteboard: This is not the bug for lifting, but for notifying the user about that restriction. 2) All what you need is already implemented, you only have to activate it (after considering the security holes you open): This actually works on our Solaris 10 x64 platform and Linux x86 (don't break the lines as they appear here due to the limited comment width) # # Firefox: allow access to local files from www.domain.com and localhost # cat>>/usr/lib/firefox/defaults/pref/firefox.js<<EOT // allow access from http/mail to local files from local host and website pref("capability.policy.policynames", "localfilelinks"); pref("capability.policy.localfilelinks.sites", "http://www.domain.com http://localhost"); pref("capability.policy.localfilelinks.checkloaduri.enabled", "allAccess"); EOT # # Thunderbird: allow link to local files from mailbox and imap4(ssl) server # cat>>/usr/lib/thunderbird/defaults/pref/mailnews.js<<EOT // allow access from http/mail to local files from local host and website pref("capability.policy.policynames", "localfilelinks"); pref("capability.policy.localfilelinks.sites", "mailbox:// imap://imap4.domain.com:993"); pref("capability.policy.localfilelinks.checkloaduri.enabled", "allAccess"); EOT
thanks for the reply, but I got an email from another user with an easy workaround- Firefox ADDON - IE in another tab, then you can link to local files all you want and not leave Firefox. The other wonderful thing is that you no longer have to exit Firefox and go into IE when you need to do Windows updates (as they won't let you do it outside of IE). BRILLIANT!
Filter "spam" on "guifeatures-nobody-20080610".
Assignee: guifeatures → nobody
QA Contact: pawyskoczka → guifeatures
Component: XP Apps: GUI Features → UI Design
More than seven years now - this is one of the original Firebird^H^H^H^Hfox bugs, guys! I've already volunteered to step up and attack this issue. Are y'all GENUINELY trying to tell me that it's not a bug, that it's a feature? Give me a f***ing break.
Gordon, I think part of the problem is that no developer I can think of is still reading this bug: too much noise, not enough signal. It doesn't help that people have turned it into a get-help location and a general discussion area for the concept of security checks instead of keeping it focused on the original issue, which is most definitely a bug and should be fixed. If you're willing to work on this, that's wonderful, and I suggest starting a thread in the mozilla.dev.apps.firefox newsgroup (which is also the same thing as the dev-apps-firefox@lists.mozilla.org mailing list if that would be easier) about what the right user-facing behavior here should be. Dialogs are not so great, but it seems like we could either use the notification bar here or show an error page when a user clicks on a link to a file:// URI, and have a way the user can proceed to the actual file that's linked to, or add a permanent exception for the site in question. I would say the additional question of what should happen for things that are not link clicks should be out of scope for this initial discussion. It might also be worth filing a new, clean bug just for that issue (again, dammit) so that work on fixing what is a real problem can proceed free of the noise and baggage that we have here. But I'd start with the UX discussion and see what conclusions that comes to.
I would seriously commit to a token paypal donation to whoever fixes this. This is such a total PITA for those of us who use firefox in a corporate environment with wiki's, intranets, file links, etc. The silent fail is the worst. An error bar, similar to passwords, that prompts for a cancel, one time exception, or permanent override would be the best. Please get this fixed! This is yet another reason why IE is still preferred by some and it would make the IT department's life simpler.
Count me in on the PayPal thing. It's not much, but I'll give $10 to the fixer. If everyone who's commented on, voted for, or CC'ed on this bug did likewise, that might add up to a few $$. Come on, folks, put your money where your mouth is. Kick in $10 each, and we might see a fix for this finally!
Created a project at Bounty Source... https://unc4firefox.bountysource.com/
That URL doesn't work for me. Any one else have a download link, or information about that project/patch/extension?
It works again but you can't add money to the bounty :(
It seems logical to handle this in the same way as unsigned plugins and popups are currently handled; i.e. display a message "Firefox prevented..." in the notification bar with either an "Allow" or an "Options" button.
It is year 2010, by the way. Happy anniversary. If the page loaded over HTTP contains a link like a href="figdle:///whaever.txt", it is also an issue that the site developer can fix*, yet in this case a dialog pops up telling the user some information, why the link did not work. I don't see a reason HTTP-to-FILE: link failures should be treated any different. About the security argument: If I try to read a file that I have no permission for, the OS gives a clear message "can't read: permission denied". In the UI, not some log file. * - see comment 2 (I had the pleasure of encountering this issue on Firefox 3.5.8 , Windows XP)
Does the mozilla team accept sponsorship to fix bugs? Looking at the size of the CC list I expect we could raise a reasonably good bounty to get something done about this. I'd love to see this fixed as per comment 365 (maybe with an 'Always Allow' option?).
(In reply to comment #367) > Does the mozilla team accept sponsorship to fix bugs? Looking at the size of > the CC list I expect we could raise a reasonably good bounty to get something > done about this. Bounty, nothing... please note comments #335 and #357. I've *volunteered* to fix it, twice. Honestly, at this point, I'm hoping that Chromium fixes up their rendering issues. I've been waiting for a reasonable alternative to FF and IE now for a while, having reluctantly concluded that Mozilla/FF is too embroiled in political infighting, evangelism, or... something... for contributions to happen from the community at large (that is, as opposed to "established contributers").
Gordon, there was lots of positive information given after your comment #335. The next step would have been to assign the bug to yourself and then start to generate a patch for review. For some reason this did not happen...
(In reply to comment #369) > For some reason this did not happen... Well, in fairness to everyone else, partly because my life went berserk right when things got "interesting" there (job changes, home changes, etc.) - but I was actually aware of the commentary. The other reason is that I see four different potential UI solutions that have been proposed, with two different internal implementations of one of those solutions (error dialog, error page, cursor change, infobar via "observer notification", and infobar via event). There was still quite a bit of discussion going on between people who clearly know the code (after all, you can't really just depend on an @mozilla.com e-mail address). All that said... to revisit comment #336 and #337 - does that imply that the "observer notification" route is the right way to go?
Gordon, I think the observer notification route has enough support that you should press on and create a patch. IMO it's the best solution (and it's infinitely better than nothing!). I don't think a universal consensus is going to emerge here. Thanks in advance for your efforts - can't wait to see the result! *getting excited*
Did I read correctly comment 358? Because they are unable to solve a bug they don't take care of this report anymore. WOW! OK! It is then probably the last time I will ever fire Firefox. How can I rely on such a team! 9 years!
2011 chiming in. Still no fix? This is amazing.
If I understand right,in order to catch NS_ERROR_DOM_BAD_URI with errorpages (bug 28586), we need a new function instead of nsIWebNavigation::loadURI(...) something like void loadURI(in wstring aURI, in unsigned long aLoadFlags, in nsIURI aReferrer, in nsIInputStream aPostData, in nsIInputStream aHeaders, in nsIPrincipal aRefPrincipal); or void loadURI(in wstring aURI, in unsigned long aLoadFlags, in nsIDocument aReferrerDocument, in nsIInputStream aPostData, in nsIInputStream aHeaders); etc. Or, can we make a valid nsIPrincipal object only from the referrer URI, just like nsDocshell::InternalLoad does? Probably docshell is not designed to detect the difference between "'file:///' request from links on HTTP" and "'file:///' request from the location bar" (except for the referrer URI, of course). Thus docshell is not a proper place to call CheckLoadURI(Str)WithPrincipal(...), because it needs the nsIPrincipal object. On the other hand, in order to load an errorpage (or to prompt an error dialog), someone has to return the error code, in this case, NS_ERROR_DOM_BAD_URI, to docshell. Among other things, this point is critical. Another problem would be that probably we'll be able to reload the error page. At least I think most of guys here is hoping so. But it's likely to corrupt the session history... For the time being, I think error prompt is the better choice than error page. I'm not too sure about infobar. What is expected to dispatch the notification? urlSecurityCheck(...) in contentAreaUtil.js can be a candidate, for the purpose of this bug is not to pick up all errors but to pick up only when user clicks a link, right? http://hg.mozilla.org/mozilla-central/annotate/fbe7830f27c0/toolkit/content/contentAreaUtils.js#l62
There are several "proposed patches" for this bug. Can someone who does this sort of thing, "un-bit-rot" these, so at least the patch is more current? This would be a good first step towards resolution. Thank you.
Myk, why did you reassign to Mozilla (Seamonkey)? This also affects Firefox. Please reassign to Core. Please upgrade this to major and retitle to either: CheckLoadURI fails quietly (eg, for links to file: urls) or No feedback when loading a link fails (eg, for links to file: URLs)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: