allow security.checkloadURI exceptions via paired URL-filesystem expressions

NEW
Assigned to

Status

()

Core
Security
--
enhancement
16 years ago
9 years ago

People

(Reporter: benc, Assigned: dveditz)

Tracking

Trunk
Future
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

16 years ago
Mitchell had commented that domain based exceptions to this feature might be a
good idea, and I could not find an RFE on that feature, so I'm creating it here...

I propose the following:

A preference that accepts some kind of paired URL prefix. The first part
describes URLs allowed to make an exception to get file: URL access to the
second expression.

For example:
http://www.packetgram/push/* + file:/usr/local/push/*

(Someone can probably come up with saner syntax, but you get the idea).

The pref could be in the UI, or via the next-gen Mission Control, or hacking
prefs.js, this should be discussed.

Interestingly, this would be much more secure if you used https: in the first
pair, because it would prevent spoofing of references to the local filesystem.
Ben and I discussed this. I may do it if there's a huge demand. In the meantime,
we have the binary "security.checkloaduri" pref.
Severity: normal → enhancement
Status: NEW → ASSIGNED
Target Milestone: --- → Future
(Reporter)

Comment 2

15 years ago
This would probably be the most direct way of giving people what they want in
bug 84128. Right now, if you turn off checkloaduri, it is all-or-nothing.
Keywords: nsbeta1

Updated

15 years ago
Summary: [RFE] allow security.checkloadURI exceptions via paired URL-filesystem expressions → allow security.checkloadURI exceptions via paired URL-filesystem expressions

Comment 3

15 years ago
Finally I found it!  Yes, you need something like this to allow mozilla to be
used as a replacement for IE in intranets.  Perhaps you need three columns:

ALLOW: 
remote protocol     domain                 local protocol
http               *.math.clemson.edu      file://///*
https              *.clemson.edu           file://///*

DISALLOW:
remote protocol    domain                    local protocol:
https              *.students.clemson.edu    file:*

and I think this should default to:
ALLOW
remote protocol    domain                                    local protocol:
https              <local domain determined by IP address>   file:///*

Updated

15 years ago
QA Contact: ckritzer → bsharma

Comment 4

14 years ago
How would this work for file:// links within emails?

Comment 5

14 years ago
If so then bug 135830 should probably be marked as a dupe
(Reporter)

Comment 6

14 years ago
You could have the sending domain of mail be assumed to be the domain of the
base, but this is too easy to forge.

People should not be sending file URL's in documents they create, even though
MailNews does this all the time in "Send Page" (bug 136782).

Comment 7

14 years ago
Unless of course it's internal email within a company where everyone has access
to a shared network drive. At which point file:// links make perfect sense as it
means people aren't clogging up the email system with lots of attachments.

Comment 8

14 years ago
We in our institute are DAILY sending file URL's in mail because we don't
want to have our people have to save or to download papers to which they
have local access anyway. So the typical thing we do is to send a mail 
with a file URL where to find the document. I think this is a perfectly 
legitimate and space and network traffic saving habit.

Comment 9

14 years ago
adt: nsbeta1-
Keywords: nsbeta1 → nsbeta1-
(coming here from bug 233108 comment 21)

A configured site+directory pair would be perfect to solve my case in bug 264968
comment 11 too:
something like 'http://www.battle-arenas.net/* <->
file:///W:/Progs/@Battle-Arenas/ba_pack/*'.

Comment 11

13 years ago
This is my situation.  I have been fighting this bug/issue since Netscape 4
days, and I have seen many bugs and comments about it.

This problem is still there in FireFox 1.0.  It is reproducible at will.  If the
CheckLoadURI problem can't be fixed, can we at least have a totally insane and
unsecure option that will allow us to link to file://f:/some.file bypassing ALL
security?

Please!

I thought the CheckLoadURI setting was supposed to allow this, but it doesn't. 
It never did, as far as I can tell.

The only thing that works right now is to load IE 5.5 and make it my default
browser, or force my users to right-click and open in a new window which
launches IE as well.  Then I can email a link to a file on my server and have it
work.

Thank you.

(In reply to comment #8)
> We in our institute are DAILY sending file URL's in mail because we don't
> want to have our people have to save or to download papers to which they
> have local access anyway. So the typical thing we do is to send a mail 
> with a file URL where to find the document. I think this is a perfectly 
> legitimate and space and network traffic saving habit.
(In reply to comment #1)
> In the meantime,
> we have the binary "security.checkloaduri" pref.

This works,
and bug 233108 improved this recently :-)
Usage examples: see bug 84128 comment 194 and 199 !

(In reply to comment #10)
> A configured site+directory pair would be perfect to solve my case in bug 264968
> comment 11 too:
> something like 'http://www.battle-arenas.net/* <->
> file:///W:/Progs/@Battle-Arenas/ba_pack/*'.

What we still miss is the "file path" part: this bug !

Comment 13

13 years ago
See bug 84128 comment 264
(https://bugzilla.mozilla.org/show_bug.cgi?id=84128#c264).
(In reply to comment #13)
> See bug 84128 comment 264

For those who want to read that comment (or not):
it is about "Suggestion: Track security level of operations requesting opening
URL, modeling after the Java privileged block API.".

Comment 15

12 years ago
Is this the same as Bug 233108 ?

Comment 16

12 years ago
(In reply to comment #15)
> Is this the same as Bug 233108 ?

see comment #12

Comment 17

12 years ago
What happens in Firefox 1.5? I've set "security.checkloaduri=false" and it works untill Firefox 1.0.x . In version 1.5 this old security violation message popup in the java-console-view, but the file isn't loaded. In about:config my parameter is still set to "security.checkloaduri=false".
(In reply to comment #17)
> What happens in Firefox 1.5? I've set "security.checkloaduri=false" and it
> works untill Firefox 1.0.x . In version 1.5 this old security violation message

I guess you should try the |user_pref("capability.policy.xyz", "xxyyzz");| preferences after "Gecko/Trunk" v1.8a5.

Probably, this bug should be morphed to take this into account !!?
(Assignee)

Updated

11 years ago
Assignee: security-bugs → dveditz
Status: ASSIGNED → NEW
QA Contact: bsharma → toolkit

Comment 19

9 years ago
It's been almost 7 years since this enhancement request has been opened and 2.5 years since the last comment.  I've been tracking the related bug #84128 (which is even older than this one), and just came across this item.
 
A solution to this enhancement request would be better than just the user-visible warning bug #84128 is asking for, so... any updates?  And, no, asking users to install "IE Tab" or edit their prefs.js, etc, is not acceptable.

We have GUIs (of a sort) to allow users to allow blocked pop-ups from certain sites.  Why can't we have the same type of notification & override for "blocked" file:// URLs?  I don't see why blocked file:// URLs should be treated any differently than pop-ups from the USER'S point-of-view.  They are both things that are annoying and/or dangerous, but there are times & sites for which you NEED those things (esp. if it's something that you explicitly clicked on!).

Thanks,
   Jim
You need to log in before you can comment on or make changes to this bug.