Closed
Bug 858
Opened 26 years ago
Closed 25 years ago
[Feature] JavaScript auto-disable per-domain RFE
Categories
(Core :: Security: CAPS, enhancement, P2)
Tracking
()
VERIFIED
FIXED
M15
People
(Reporter: brendan, Assigned: norrisboyd)
References
Details
This is a request for enhancement. It's overdue in mozilla, in the competition,
and demanded by champions and users.
When I or Chuck Simmons (chrlsim@futureone.com, netscape champion) or many
others surf the wilds of the Internet, we turn JS off. Why? Paranoia, good
sense, whatever -- it doesn't matter. Mozilla has not had its last security
hole closed. This goes for JS, Java, HTML layout (remember the Danish
form-type-change attack), netlib, etc. Then there are denial of service attacks
to consider.
OK, what can be done? This bug (really, RFE) asks that mozilla at least
automate the disabling of executable content when surfing away from URLs that
begin with host parts from a known-trustworthy set of fully-qualified domain
names.
That requires preference UI support, I suppose. Although with just the pref
checking code in libmocha and the Java glue, and with a signed script that
called navigator.preference, we (or anyone trusted) could construct a "set your
shields-up preferences" page on mozilla.org, home.netscape.com, that acted as a
web-server-based pref UI.
So Mike, can you bug me about implementation, do the libmocha hacks (or find
someone else to do them), then reassign this bug to raman for Java? We should
figure out the pref syntax and value types first, make them common and
extensible. After you and raman are done, we can give it to german for UI
consideration -- but the web-based pref UI approach seems better to me.
/be
Comment 1•26 years ago
|
||
Don't forget mail. I'd imagine any general solution will fix mail, but the most
annoying problems for *me* are when porno spammers send me mail that keeps
opening windows that they won't let me close. Surfing mainly to reputable web
sites I haven't had anywhere near the troubles I've had with mail. [There is
already a pref to turn javascript off in mail, but then you lose it
completely.]
Steve Morse's cookie manager does something like this for cookies. I wonder if
it could be extended or generalized this purpose as well? Jar and Raman had
discussed zone-based security for Java in the past, they may have thought
through some of the issues already.
Brendan was noting that we could actually use prefs to do this - something
like
javascript.deny.domain
where domain is the domain you want to keep from using JS. Or you could
do
javascript.allow.domain
with the default set to not letting anyone use it so that you could allow
home.netscape.com to use JS but not anyone else.
About mail and news, isn't there a pref now like javascript.allow.mailnews
or something like that?
Reporter | ||
Updated•26 years ago
|
Summary: JavaScript and Java (and plugins? All executable content?) auto-disable per-domain RFE → JavaScript auto-disable per-domain RFE
Comment 3•26 years ago
|
||
I simplified the Summary to deal with JS only (plugins are caveat-downloader,
Java should get a separate bug).
We already have a javascript.allow.* pref namespace, that's where
javascript.allow.mailnews lives. I was proposing by phone to mlm (and therefore
dots got lost) this idea:
Add a new pref object node, javascript.allow.domain. Under it, users could
create names like
javascript.allow.domain.mypal.sgi.com
javascript.allow.domain.netscape.com
javascript.allow.domain.mozilla.org
Add another new pref node, javascript.deny.domain, so that users can arrange for
JS to be disabled elsewhere:
javascript.deny.domain.com // restrictive!
javascript.deny.domain.sgi.com
and perhaps even
javascript.deny.domain["*"]
for all. Then modify LM_CanDoJS
(http://cvs-mirror.mozilla.org/webtools/lxr/ident?i=LM_CanDoJS) after making
sure it is used universally to decide whether JS is enabled to have this logic:
if (there is a pref of the form javascript.deny.domain.x where x is a
domain-name-suffix of the current URL's host part, or the same as the
current URL's host part) {
if (there is not a pref of the form javascript.allow.domain.y where y
is a longer domain-name-suffix of the current URL's host part) {
return JS_FALSE;
}
}
... rest of LM_CanDoJS logic here
This is almost too easy. There'll probably be hassles with LM_CanDoJS not being
universally quantified. There won't be any threading hassles cuz this function
is used only in the mozilla thread. There could be some sharing of domain
suffix checking or extraction with the lm_doc.c DOC_DOMAIN property's code, but
it's short enough to rip off.
After this is done, the UI could be done entirely by a signed script, say on
Netscape's home page (signed by Netscape's SSL cert so it's already trusted, for
better or worse).
/be
Comment 4•26 years ago
|
||
How would this proposal deal with JavaScript in mail? Yes, we can turn off
JS for mail (all or nothing), but we can currently do the same for JS as a
whole and that's what this RFE is trying to change. Please don't
leave JS-in-mail out when designing the solution to this problem.
If HR sends me a form, I'd like JS to work in it. If some unknown sends me spam
that tries to open unclosable windows I *don't* want to run JS.
As to javascript.allow.* and javascript.deny.*, perhaps you need a third pref
that toggles between "allow unless specifically denied" and "deny unless
specifically allowed". If I had a per-domain feature most of the time I'd
probably want JavaScript off except for specific trusted sites. But if I ran
across a new site that required JavaScript I'd probably want to be able to
easily turn it on and give that site a whirl without having to say I trust that
site.
Comment 5•26 years ago
|
||
This feature won't work well in mail without authentication.
We could invent a magic domain for all JS-in-mail that defaults to deny, but
which you could selectively enable (see next).
> perhaps you need a third pref that toggles between "allow unless specifically
> denied" and "deny unless specifically allowed".
Right -- the way to do this, it seems to me, is not to make those prefs I
sketched boolean, but string-valued:
javascript.allow.domain.com = "ask"
or similar for deny (which would change the default sense of the confirming
dialog's OK or Yes button from the allow... = "ask" case).
Mike, are you keen to do this in mozilla?
/be
Certainly; it'll probably just be a few weeks before I can start pushing
full speed on it. (I have 4.x merges to take care of first.)
Comment 7•26 years ago
|
||
> We could invent a magic domain for all JS-in-mail that defaults to deny, but
> which you could selectively enable (see next).
s/JS-in-mail/JS-in-unauthenticated-mail/
For SMIME etc., we can use the host part of the From address as the domain to
allow or deny.
/be
Comment 8•26 years ago
|
||
Design nits: Overloading `.' as pref-hierarchy-separator and
domain-part-separator grates a bit. Mail/news does this already with
imap.server.tintin.mcom.com and it makes it hard to build a general preferences
UI. I'd prefer javascript.domain["sgi.com"] = "ask"/"on"/"off"/"whatever".
Maybe "signed" for signed JS only? "http,mail" to allow both HTTP and read-mail
stuff, but "http" to not allow mail?
Updated•26 years ago
|
Component: LibMocha → JavaScript
Product: MozillaClassic → Browser
Reporter | ||
Updated•26 years ago
|
Assignee: mlm → joki
Status: ASSIGNED → NEW
Component: JavaScript → DOM Level 0
Comment 10•26 years ago
|
||
This is not a core JavaScript bug (RFE) -- it's really somewhere near the DOM,
so I'm giving it to DOM level 0 and joki, who is security policy fallguy for JS
stuff in the client.
/be
Updated•26 years ago
|
QA Contact: 4015
Comment 11•26 years ago
|
||
per leger, assigning QA contacts to all open bugs without QA contacts according
to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser
Comment 12•26 years ago
|
||
QA contact re-assigned according to the product areas we're currently working
on.
Updated•26 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M4 → M6
Comment 13•26 years ago
|
||
The code from Lucent will accomplish some of these. We can look adding this
particular feature to it as well. But this isn't for M4. Moving to M6
Comment 14•26 years ago
|
||
People have been requesting feature-wise disabling, e.g., window.open -- if
that's done, it should be per-domain and/or all-but-this-domain too.
/be
Assignee | ||
Updated•26 years ago
|
Assignee: joki → norris
Status: ASSIGNED → NEW
Assignee | ||
Updated•26 years ago
|
Target Milestone: M6 → M9
Assignee | ||
Comment 15•26 years ago
|
||
I'll take this on my plate. No promises on implementation for 5.x, but I see why
this feature would be desirable.
Comment 16•26 years ago
|
||
Any restrictions should also apply to window.status and toolbar changes in the
current window as well as any new windows. Perhaps also restrict access to java
as well.
Assignee | ||
Updated•26 years ago
|
Status: NEW → ASSIGNED
Comment 17•26 years ago
|
||
Bug #7380 is a superset of this functionality.
Comment 18•26 years ago
|
||
Is the Lucent code anywhere we can get to? There's a lot of interest in this
particular feature, and we might be able to get someone else to do the hevy
integration lifting for us.
Comment 19•26 years ago
|
||
There already seems to be some cookie people doing a site by site feature, if
you're gonna do this, you might want to touch base with them over a set of
common APIs. See my comments in bug #7380.
Comment 20•26 years ago
|
||
norris? joki? bueller?
What's the deal with the Lucent code? People are itching to see this stuff, and
I'm sure some of them would help us out, but we're all waiting to see what
Lucent's stuff gives us first. We're a long way from the original M6 estimate;
is M9 a ``real'' plan?
Assignee | ||
Comment 21•26 years ago
|
||
Depends on 7254, which is M10.
Assignee | ||
Comment 22•26 years ago
|
||
I'm working to enable the core security code in caps, some of which we're
migrating from dom. This includes joki's work to port the code from Vinod Anupam
and Alain Mayer, the Bell Labs researchers (see
http://www.mozilla.org/projects/security/ for a couple of their papers).
Right now the code is butt-ugly, a consequence of being ported too many times by
different people. I'll be bringing up the functionality and cleaning up the
code.
Assignee | ||
Comment 23•26 years ago
|
||
*** Bug 11931 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 24•25 years ago
|
||
I've posted a quick, rough web page on the configurable security
policies that are a new feature that many people would like to see in
mozilla.
http://www.mozilla.org/projects/security/configPolicy.html
Discussion in
netscape.public.mozilla.security
Assignee | ||
Updated•25 years ago
|
Whiteboard: Lucent folks have offered help with security policies
Assignee | ||
Updated•25 years ago
|
Whiteboard: Lucent folks have offered help with security policies → Help wanted: Lucent folks have offered help with security policies
Assignee | ||
Updated•25 years ago
|
Comment 25•25 years ago
|
||
Why do you feel that my bug #7380 proposals are not worth implementing? Are
they too complex? Is there not enough time? If the latter is the case, I'm
worried that any decision now may lock in interface declarations that will be
inflexible later.
Have you discussed your model and possible shared architecture and UI with
smorse, who knows about the current implementation of the exact same thing for
cookie acceptance? This is a lot broader than the security issues, or at least
it should be. I believe the whole point of writing Gecko, Necko, etc was to get
past the old architecture which wasn't designed as well as it could be ...
I apologise for my tone which could be interpreted as haughty, but I've been
railing on about this issue for a while now and no-one has given me any
feedback. I only want to avoid problems in future.
Assignee | ||
Comment 26•25 years ago
|
||
Time's a factor, but I didn't look through your 7380 proposals to incorporate
them into my document. Even if we don't implement full functionality for 5.0, I
don't want to prevent future development.
I'll try to look over 7380 and take it into account.
Updated•25 years ago
|
Severity: normal → enhancement
Assignee | ||
Updated•25 years ago
|
Whiteboard: Help wanted: Lucent folks have offered help with security policies
Assignee | ||
Comment 27•25 years ago
|
||
I've implemented some of the per-domain policy ideas proposed by the researchers
at Lucent. With my checkin yesterday it is possible to edit the preferences file
to indicate that certain domains have a named policy. That policy can then be
specified to grant or restrict access to DOM properties one-by-one.
I haven't yet made it possible to disable the execution of JavaScript
controllable by domain, but I'll do that before I close this bug.
Assignee | ||
Updated•25 years ago
|
Component: DOM Level 0 → CAPS
Summary: JavaScript auto-disable per-domain RFE → [Feature] JavaScript auto-disable per-domain RFE
Assignee | ||
Updated•25 years ago
|
Target Milestone: M14 → M15
Assignee | ||
Comment 28•25 years ago
|
||
I've got changes in my tree that allow a user to disable JavaScript for certain
selected sites using lines in the all.js preferences file like:
pref("security.policy.strict.sites", "http://warp.mcom.com");
pref("security.policy.strict.javascript.enabled", "noAccess");
Reporter | ||
Comment 29•25 years ago
|
||
Can the "sites" pref's value be a comma-separated list? Is the "http://"
really necessary? And (final question!) how hard would it be to do the
"...sites['warp.mcom.com']" thing, i.e., a pref for each site, whose value told
how that site was handled? Then no CSV parsing, just constant-time pref hash
table lookup.
/be
Assignee | ||
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 30•25 years ago
|
||
I just checked in the changes that enable this.
To answer brendan's questions:
>Can the "sites" pref's value be a comma-separated list?
Space separated. See http://www.mozilla.org/projects/security/configPolicy.html
>Is the "http://" really necessary?
It's required now. I guess we could have a rule that if there is no colon, then
the scheme defaults to http.
> And (final question!) how hard would it be to do the
> ...sites['warp.mcom.com']" thing, i.e., a pref for each site, whose value told
> how that site was handled? Then no CSV parsing, just constant-time pref hash
> table lookup.
I maintain a hash table that maps from a domain to the name of the policy. My
thought was that people will want to deal with groups of sites when setting
policies like the Lucent proposal or with IE's zones.
I'll mark this bug fixed; requests for additional changes can be logged either
by reopening this or by filing additional bugs.
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Comment 31•25 years ago
|
||
After reading norris's comments, I feel that this one should be verified, and
requests for additional changes could be made by filing new bugs.
Marking Verified.
Comment 32•25 years ago
|
||
Moving all CAPS bugs to Security: CAPS component. CAPS component will be
deleted.
Comment 33•25 years ago
|
||
*** Bug 40005 has been marked as a duplicate of this bug. ***
Comment 34•25 years ago
|
||
Is there a prefs UI tracking bug for this?
Comment 35•25 years ago
|
||
There's bug 7380, but no UI-specific bug. If you file one, please CC me on it.
Comment 36•24 years ago
|
||
*** Bug 69144 has been marked as a duplicate of this bug. ***
Comment 37•24 years ago
|
||
How does one use this to implement a whitelist? I tried
user_pref("capability.policy.default.javascript.enabled", "noAccess");
user_pref("capability.policy.relaxed.javascript.enabled", "sameOrigin");
user_pref("capability.policy.relaxed.sites", "http://www.goodsite.com/");
but this does not permit goodsite to run javascript. What's the proper
incantation?
Comment 38•24 years ago
|
||
I believe there is a bug that restricts setting capability prefs to the default
prefs in the installation directory; they don't work from a profile. Use pref()
not user_pref().
Comment 39•24 years ago
|
||
(suggestion to try pref() instead of user_pref()):
That still doesn't work. In prefs.js:
pref("capability.policy.jsallowed.sites",
"http://www.mozilla.org http://bugzilla.mozilla.org");
pref("capability.policy.jsallowed.javascript.enabled", "sameOrigin");
pref("capability.policy.default.javascript.enabled", "noAccess");
Then load up http://www.mozilla.org/quality/help/bug-form.html and check out
the blank page.
Comment 40•24 years ago
|
||
How about furthering IE's ability to set all security on a site-per-site basis
and fully allowing the user to make their own named "zone" and ability to put
sites in it? Huge addition to prefs file, but a one-up to IE.
Comment 41•22 years ago
|
||
Is it possible to declare the sites preference with wildcards like:
pref("capability.policy.UBS_trustable.sites", "http://*.ubs.com");
or:
pref("capability.policy.UBS_trustable.sites", "ubs.com");
The idea behind this is to enable privileges for an entire intranet. Big
companies cannot configure all their webservers by name in the
preference-string. This is not maintainable.
Thanks for any info.
Hugo Kortschak
Comment 42•20 years ago
|
||
An extension which is an easy to use UI for this feature: http://www.noscript.net
You need to log in
before you can comment on or make changes to this bug.
Description
•