Javascript [Electronic resources] : The Definitive Guide (4th Edition) نسخه متنی

21.4 Security Zones and Signed Scripts

A one-size-fits-all security policy is
never entirely satisfactory. If the policy is too restrictive,
trusted scripts don't have the
ability to do the interesting and useful things we would like them to
do. On the other hand, if the policy is too permissive, untrusted
scripts may cause havoc! The ideal solution is to allow the security
policy to be configured so that trusted scripts are
subject to fewer security restrictions than untrusted scripts. The
two major browser vendors, Microsoft and Netscape, have taken
different approaches to allowing configurable security; their
approaches are briefly described in this section.

Internet Explorer defines
"security zones" in which you can list web sites whose
scripts you trust and web sites whose scripts you do not trust. You
can then configure the security policies of these two zones
separately, giving more privileges to and placing fewer restrictions
on the trusted sites. (You may also separately configure the
privileges of internet and intranet sites that are not explicitly
listed in either of the other two zones.)

Unfortunately, this is not a complete or fine-grained solution for
JavaScript security, because most of the security options that IE
allows you to configure are not directly related to JavaScript. In IE
6 beta, for example, you can specify whether scripts are allowed to
control ActiveX objects and Java applets, and whether they can
perform paste (as in cut-and-paste) operations. You are not given the
option, for example, of disabling the same-origin policy for a
trusted site or of allowing scripts from trusted sites to send email
messages without a user confirmation.

Netscape 4 and Netscape 6 implement
configurable security with an approach known as "signed
scripts." Signed scripts provide complete fine-grained
configurability of security policies and do it in a way that is
cryptographically secure and theoretically very compelling.
Unfortunately, since Microsoft has no compatible technology, the
process of creating signed scripts is cumbersome for script authors,
and the use of signed scripts can be confusing for end users, the use
of this promising technology has never really caught on.

Briefly, a signed script bears an unforgeable
digital
signature that specifies the person or organization that wrote or
otherwise takes responsibility for the script. When a signed script
needs to circumvent one of the security restrictions described
earlier, it first requests a special "privilege" that
allows it to do so. When a script requests a privilege, the browser
defers to the user. The user is told who the signer of the script is
and is asked whether she wants to grant the requested privilege to a
script written by that person or organization. Once the user makes
the decision, she can have the browser remember it so that she
doesn't get asked the same question in the future. In effect,
this procedure allows a user to configure a fine-grained customized
security policy on the fly, as the need arises.

As I've already mentioned, the process of creating signed
scripts is somewhat cumbersome. Also, the details of how it is done
have change between Netscape 4 and Netscape 6. Those details are
beyond the scope of this book, but you can learn more online at

http://developer.netscape.com/docs/manuals/signedobj/trust/index

and

http://www.mozilla.org/projects/security/components/.