 |  |
| |
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.htm and http://www.mozilla.org/projects/security/components/.
|  | |
| 21.3. The Same-Origin Policy |  | 22. Using Java with JavaScript |
Copyright © 2003 O'Reilly & Associates. All rights reserved.