Open Bug 318775 Opened 19 years ago Updated 2 years ago

Accessing local files from Intranet pages

Categories

(Firefox :: Security, enhancement)

Product:
Firefox
Component:
Security
Type:
enhancement

Tracking

()

People

(Reporter: digulla, Unassigned)

References

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

There is an old bug (#84128) which talks about a missing reaction by Firefox if a user clicks on a file: URL on an Intranet page.

This bug here is to collect votes to get a proposed solution fixed:

When a user clicks on a file: URL (ideally anywhere but for starters, it would be sufficient if it would from from HTML pages), a message will be display: "For security reasons, access to [file:] has been blocked. This is to protect you from malicious websites which try to access your data."

The user must now be presented with these options: "Deny access" and "Allow access for [http:...]".

The allow-rule must support patterns (to allow to add a whole range of sites like the different company servers with "http://*.company.com") and it must support to restrict the access for certain pages (like when you have a site which contains safe parts and public forums).

Ideally, the first version should present a text field with the current URL of the page and a couple of examples how to change it and what the change would mean. Example:

The page which tried to open the file was "http://www.firefox.com/forum/thread.php?id=15467"

Now the UI should show these options:

1. "Never allow access to local files from this site [www.firefox.com]"

2. "Allow the access just this once."

3. "Allow the access just for the current page and remember this decision."

4. "Allow all pages on the server www.firefox.com to access local files. Note: If there are pages on this server which anyone can change, you're creating a large security threat!"

5. Allow all pages on any server in the domain firefox.com to access local files. Note: Just like #3, this can be a huge security threat. Imagine someone adds a new site to the network which contains a public forum."

6. Add the following pattern to the list of sites which can access local files:
[text field with the URL here]. Note: Expert option! Use with care!

Buttons: "Deny access", "OK".

Pressing OK should save the selection and then process with the choice (ie. if the user allowed the access, it should open the file).

In the security prefs, there must be a page to edit these settings.

Reproducible: Always

Steps to Reproduce:
See all those other bug reports.
This bug is a clear dupe of bug 84128, there is no reason to create a new bug.
There will no UI added to allow local file access (AFAIK) but feel free to write an extension for the already existing Backend.


*** This bug has been marked as a duplicate of 84128 ***
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
I created a new bug because the old one is cluttered with options, discussions and complaints and I wanted to have a vote for my proposed solution.

I could write an extension but I guess someone who knows how to write an extension could do it in a few hours while it would take me several days just to find out where to start, so it's not very effective from my point of view.

Also, I don't think an extension is the correct fix: The fix must come with the standard installation of FireFox because too many people are affected by it.
Actually, this bug is not a dupe of 84128.  That bug does not suggest changing the behavior - it merely states that the user should be given a visual indication that the browser recognized that they clicked a hyperlink, but is refusing to take them to it (it currently silently ignores the click).
I'd like people to still cast their vote for this bug. When it reaches 100 votes, I'll reopen it.

This proposal, frankly, falls into the "give someone enough rope and they'll hang themselves" category.  The proposed UI is complex and confusing, and easily hacked via social engineering means. ("In order to use this site, you must enable local file access by clicking X, Y, Z.")  Bugzilla is not a democracy, even if you mustered 1000 votes it would still be a poor solution, and we wouldn't accept/implement it.

In any case, if its not a duplicate, then its a WONTFIX.
There's something I don't understand then. Why smb:// links are allowed to work with the linux version of firefox ? It can leak just the same local network information as windows' version...

Re: #5

If you don't implement some kind of UI for this hidden feature of Firefox, you're just leaving the rope lying on the floor, so I can't follow your argument.

Also, this bug is not to discuss if this bug needs to be fixed but how and how important it is for the community.

But if you insist, I'll just tell the 6000 users in my company that Firefox can't be used for the intranet sites. A lot of people (especially those who get paid to sell us software) would prefer this, I guess.
I really don't understand why a well-run intranet site for a company of 6000 is pointing at local files, maybe I don't understand the use-case?  To me it seems like a bad idea, period.

I'm not really opposed to allowing sysadmins some form of control to transparently whitelist internal sites, but upfront UI as described in this bug is a non-starter.

About smb links, please file a bug, I'm pretty sure we're still in a protocol blacklisting world and that blacklist may not account for samba on Linux.
Mmm, no, linux smb links are just the _same_ as file:///// links: local links. So the security issue is _exactly_ the same.
My point was just to underlign the fact that nobody cared about accessing smb:// links from http:// pages with Linux, so why care with Windows?

My point was that smb should be limited the same on all platforms, but its very possible that it was blocked on Windows but not on Linux because it wasn't usable on Linux before samba came around.
> I really don't understand why a well-run intranet site for a company of 6000
> is pointing at local files, maybe I don't understand the use-case?  To me it
> seems like a bad idea, period.

Our use-case is an http search engine for smb shares, so as for instance to
easily find that .doc document I can't remember on which machine the typist left
it.

> I really don't understand why a well-run intranet site for a company of 6000 is
> pointing at local files

And I really don't understand why an otherwise well-designed browser will silently ignore a user clicking on a hyperlink.  Can we AT LEAST have that action cause a pop-up which explains the problem and asks the user if they wish to continue?  Think of this as being similar to accessing a site whose security certificate belongs to another site.  It could be dangerous, or it could be benign, and we ask the user if they wish to proceed.  Let's do the same for this case.
There's a growing movement to make it harder to click through on broken certs, but that's irrelevant to this bug, for the most part.  

It seems fairly clear to me that the right answer is a means to support intranets that need special access due to oddball applications, but for a home user I see little value, and significant risk, in prompting the user.
> There's a growing movement to make it harder to click through on broken certs...

If that happens, I hope they present the user with either a popup or an "about:" page explaining whey their click is being refused, instead of simply silently ignoring a click.  That should be the least that should occur.  Same thing with
file URLs on web pages.
Please, for the discussion about "ignore or not", use bug 84128. It has been discusses to death there and we don't need to raise the dead again, here.

This bug is to vote for a proposed solution.

Re #8: It's not a well-run intranet site. It would cost too much to turn it into one and people currently are used to put all big files on a network share and then point the various wiki's, CMS's and whatnot to them.

So I need a solution where I can simply add all hosts in a domain to the whitelist. And please don't argue how broken this is. It's the reality, it's what the customer wants, so please try to find a solution instead of insisting that the reality is broken.

It is, I agree, but rubbing salt into a wound has never made any friends.
I've taken the initiative to reopen this since I have been told quite plainly in bug 84128, that GUI access to the file:/// config does not belong there.  That and I feel weird voting for a closed bug.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
I really don't understand why anyone would have an objection to adding this kind of control.  Maybe you could quibble about what the exact question/phasing/granularity of control would be, but the basic idea of telling the user what's happening and giving them the option of following links to file:// URLs or not (and defaulting to not) can only be a good thing.

The user is given this kind of choice for other potentially dangerous actions, why not this one?  Why single this one out and assume that the browser knows best?

I am all for there being *some* kind of stable UI method for changing this, as opposed to having to dig through six years' worth of web page postings to try and figure out what the right bit of Magiczilla(tm) is to use for the version that I'm running - and hope that it hasn't changed in the most recent version so that nobody's figured it out yet.

See also my comment #327 in bug 84128 - it would make my job there much simpler.  I'm volunteering to try and fix this, people!  Let's put this shambling excuse for a bug to rest, it's been around for longer than the life-cycle of some open-source projects...!
Gordon: Thank you! Thank you! Thank you! Thank you!

I suggest to implement this as an extension if possible. It would make it easier to work around the nay-sayers and problem-mongers in the FF/Mozilla team.

First, just a yellow warning to show that FF won't open the URL because of security reasons. When that's done, we can work on making it user friendly by suggesting how to solve the bug (propose to add certain URLs to the config so users can safely add secure sites).
> I suggest to implement this as an extension if possible.

Mmm, precisely no: the keypoint of a lot of people here is that they just _can't_ install the extension on every client machine.

It's possible to create custom Firefox install packages which include any extension you want.

As you can see in the other thread, the Firefox/Mozilla developers will never allow to include a patch for this "feature", so an extension is the only viable way to solve it.

Also writing an extension is a much easier. If Gordon would have to compile FF again and again and we would all have to download N MB for each iteration, this will quickly become a big pain.

If the extension is successful (download rates, comments, etc), we'll have a much better basis for asking the FF developers to include it with the next version of FF. As it is, they a) don't like the feature, b) see it as the biggest security risk since the WWW was invented, c) nobody really needs this features etc. The list goes on and on and on. 330 comments in the "We're not going to fix it!" bug show their stance very clearly.

So I'm afraid an extension is the only solution with a tiny chance of success. But of course, I'll leave the final decision to Gordon. It greatly depends if he can access all necessary parts from an extension. He'll have to catch the hidden error message in the Java console and react to it. If you can't do this with an extension, there is no point in arguing for or against it :-)
Severity: major → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
Well, see, I'm commenting in the other bug (https://bugzilla.mozilla.org/show_bug.cgi?id=84128#c335) precisely *because* it's got so darned many people reading it.

The short version is this: if I get a go-ahead to fix it properly, fine.  If I get a "no %&@#ing way", that tells me that there's a fundamental problem somewhere within the Mozilla/FF team with respect to software design, and sure, someone could hack around this problem - but it tells me that there's conceptually something that can't be fixed, at least not at my level, and that FF is no longer worth my time.  Damn if I know what I'd be replacing it with off-hand, though; Konqueror's JavaScript support is just not good enough.
Added bug 84128 comment 336 on where to trigger a notification bar. You could add an "edit" or "allow" button to the notification bar, which is what this bug wants I guess.

You can't do that--at least not by default in the version Mozilla ships--until we fix the security issues that would arise (e.g. bug 230606 and bug 209234).

You also need to be careful to pick the right domain to empower. The similar XPInstall blocking bypass button regressed in 2.0 (fixed in 2.0.0.1) and for xpinstalls launched from an iframe the notification bar offered to add the site showing in the URL bar instead of the possibly different site in the frame that actually needed the empowerment.
Depends on: 209234, 230606
A Wikimedia site has been started for use within our company. It is absurd that users need to use IE to get the file:/// links to open. I also do not understand, how is it that I open a file link on some external site xyz without a security risk, while, it is a security risk when opening a file from a locally maintained web server, which is well protected from the outside world. I would agree that this bug is a duplicate of 84128, and a very old 40538. I'd prefer, that FF would have an option to allow or disallow such links for the user to choose, like many other security options.
Depends on: 165531
There was a workaround
http://www.petersblog.org/node/810
but actually this one doesn't work anymore either.

It is just ridiculous that just NOTHING happens, Firefox becomes useless for intranets using local file links by that. Trash!
try http://www.petersblog.org/node/1049 -- the capabilities prefs still work.

Normally if this were a common enough problem there would be an addon that solves it, and if it were popular enough it might get incorporated into the product.
I'm sorry, but that doesn't work either here.

I'm sure that many people have this problem in their intranet too, but don't have time to search for the problem and therefore just don't support Firefox. If there would be at least a message! But that way the only thought is «okay, Firefox is too stupid to open a simple text file on the intranet, so away with it».
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.