858 - [Feature] JavaScript auto-disable per-domain RFE

Status: VERIFIED FIXED

(Core :: Security: CAPS, enhancement, P2)

Description

[Brendan Eich [:brendan]]

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 ([e-mail], 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

[Daniel Veditz [:dveditz]]

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.

Comment 2

[mlm]

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?

Comment 3

[brendan-obsolete]

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

[Daniel Veditz [:dveditz]]

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

[brendan-obsolete]

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

Comment 6

[mlm]

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

[brendan-obsolete]

> 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

[shaver-do-not-use-this-account]

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?

Comment 9

[leger]

Setting all current Open/Normal to M4.

Comment 10

[brendan-obsolete]

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

Comment 11

[Paul MacQuiddy]

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

[gerardok]

QA contact re-assigned according to the product areas we're currently working
on.

Comment 13

[joki (gone)]

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

[brendan-obsolete]

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

Comment 15

[Norris Boyd]

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

[tenthumbs]

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.

Comment 17

[Matthew Tuck [:CodeMachine]]

Bug #7380 is a superset of this functionality.

Comment 18

[shaver-do-not-use-this-account]

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

[Matthew Tuck [:CodeMachine]]

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

[shaver-do-not-use-this-account]

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?

Comment 21

[Norris Boyd]

Depends on 7254, which is M10.

Comment 22

[Norris Boyd]

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.

Comment 23

[Norris Boyd]

*** Bug 11931 has been marked as a duplicate of this bug. ***

Comment 24

[Norris Boyd]

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

Comment 25

[Matthew Tuck [:CodeMachine]]

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.

Comment 26

[Norris Boyd]

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.

Comment 27

[Norris Boyd]

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.

Comment 28

[Norris Boyd]

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");

Comment 29

[Brendan Eich [:brendan]]

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

Comment 30

[Norris Boyd]

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.

Comment 31

[Prashant Desale]

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

[leger]

Moving all CAPS bugs to Security: CAPS component.  CAPS component will be 
deleted.

Comment 33

[Asa Dotzler [:asa]]

*** Bug 40005 has been marked as a duplicate of this bug. ***

Comment 34

[Joseph Elwell]

Is there a prefs UI tracking bug for this?

Comment 35

[Matthew T (active 1999-2002)]

There's bug 7380, but no UI-specific bug. If you file one, please CC me on it.

Comment 36

[Mitchell Stoltz (not reading bugmail)]

*** Bug 69144 has been marked as a duplicate of this bug. ***

Comment 37

[Zack Weinberg]

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

[Daniel Veditz [:dveditz]]

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

[Zack Weinberg]

(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

[Ross Lombardi]

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

[Hugo Kortschak]

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

[Giorgio Maone [:ma1]]

An extension which is an easy to use UI for this feature: http://www.noscript.net