JavaScript Security - Signed Script Practicalities
(Page 4 of 9 )
Signed scripts are primarily useful in an intranet environment; they’re not so useful on the Web in general. To see why this is, consider that even though you can authenticate the origin of a signed script on the Web, there’s still no reason to trust the creator. If you encounter a script signed by your company’s IT department, you can probably trust it without much risk. However, you’d have no reason to think that a party you don’t know—for example, a random company on the Web—is at all trustworthy. So they signed their JavaScript—that doesn’t mean it doesn’t try to do something malicious! And if it did, most users would have no way of knowing.
Another problem with signed scripts is that what it takes to acquire a certificate of identity can vary wildly from provider to provider. Personal certificates sometimes require only the submission of a valid e-mail address. Other types of certificates require the submission of proof of incorporation, domain name ownership, or official state and country identification cards. But the user has no easy way of knowing how the identity of the certificate holder was verified. It could be that the author just submitted his/her name, e-mail address, and $100. Would you let someone whose identity was thusly “verified” take control of your computer?
Developers should realize that for these reasons some users may be unwilling to grant privileges to signed code, no matter whose signature it bears. Defensive programming tactics should be employed to accommodate this possibility.
In general, it’s best to use signed scripts only when users have enough information about the signer to be able to make informed decisions about trustworthiness. In practical terms, this limits the usefulness of signed scripts to groups of users you know personally, such as your friends and co-workers.
Configurable Security Policies Both Internet Explorer and Mozilla-based browsers give users some finer-grained control over what capabilities to grant different types of content the browser might encounter. An awareness of these capabilities is useful if you’re doing intranet development. By setting up your users’ browsers to accommodate the needs of your applications, your scripts can do things that would otherwise cause browser warning messages or be impossible. These issues are also important to be aware of if you’re making use of scriptable ActiveX controls. They affect which controls users’ browser will run, and under what conditions. Careful configuration of security policies can also help secure your browser against common problems encountered on the Web.
Mozilla Security Policies Mozilla has perhaps the most advanced configurable security settings of any popular browser. You can create a named policy and apply that policy to a specific list of Web sites. For example, you might create a policy called “Intranet” and apply it to pages fetched from your corporate intranet at http://it.corp.mycompany.com. Another policy could be called “Trusted Sites” and include a list of Web sites to which you’re willing to grant certain extended privileges. A default policy applies to all sites that are not members of another policy group.
For each policy, you have fine-grain control over what the sites it applies to can do. These capabilities range from reading and writing specific portions of the DOM to opening windows via window.open() to setting other browser preferences like your home page. For example, you might give the sites your “Intranet” policy applies to free reign of your browser under the assumption that documents fetched from your local intranet will use these powers for increased usability instead of malice. Your “Trusted Sites” policy might permit your favorite Web sites to open new browser windows, read and write cookies, and run Java applets. You might set the default policy to forbid the rest of the sites you go to from opening new windows (because pop-ups are annoying), running Java, and manipulating window sizes and locations.
The major drawback of the Mozilla security policy configuration process at the time of this writing is that you have to create the policies and rules manually. There is no GUI interface for managing these preferences on a site or group basis. Interestingly though, you can create an overall JavaScript policy very easily, as shown in Figure 22-1.
To create and configure more specific site-level policies, you must open and edit the prefs.js file, typically found in the application-specific data area for programs in your operating system. In Windows this might be under C:\Documents and Settings\ username\ Application Data\Mozilla\Profiles\default. The best way to find the preferences file is to search for it, but be aware that this file is “hidden” by default on Windows, so you might have to enable the file finder to “Search hidden directories and files” in order to locate it. More information about configurable security policies in Mozilla, including the syntax of the prefs.js file, can be found at the following URLs:
FIGURE 22-1 Setting Mozilla’s overall JavaScript preferences
 This chapter is from JavaScript: The Complete Reference, second edition, by Thomas Powell and Fritz Schneider, McGraw-Hill/Osborne, ISBN: 0072253576). Check it out at your favorite bookstore today.
Buy this book now. |
Next: Security Zones in Internet Explorer >>
More JavaScript Articles
More By McGraw-Hill/Osborne
/ 64 
