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.

Figure 22-1: Setting Mozilla’s overall JavaScript preferences

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:

Security Zones in Internet Explorer

Internet Explorer 4 and later support similarly configurable security policies for different Web sites, but permit less control than Mozilla. Sites are categorized into one of five groups (known as zones to IE):

Local Intranet Pages fetched from local servers, generally inside your company’s firewall.
Trusted Sites Sites you’re willing to grant extended capabilities to.
Internet The default zone for all pages fetched from the Web.
Restricted Sites Sites you specifically indicate as untrustworthy.
Local Machine Pages loaded from your hard disk. This zone is implicit, meaning you can’t configure it manually. Content loaded from disk always runs with extended privileges.

You can manage which sites appear in which zones by selecting Tools | Internet Options in Internet Explorer, and selecting the Security tab. Click the Sites button shown in Figure 22-2 to add or remove sites from each zone.

Figure 22-2: Categorizing sites into security zones with Internet Explorer

Each zone has an associated security policy governing what sites falling into the zone can do. Internet Explorer has default security settings for each zone but also allows users to customize the settings. The default settings are called templates, and are known (from least secure to most paranoid) as Low, Medium-Low, Medium, and High. You can see in Figure 22-3 that the default setting for the Trusted Sites zone in Internet Explorer 6 is Low.

Figure 22-3: Most security zones have a default security template.

Clicking the Custom Level button (shown in Figure 22-3) for each security zone enables you to configure specific capabilities that sites in that zone have. Figure 22-4 shows a sample of these options. Although a complete discussion of each option is outside the scope of this book, an awareness of those that apply to scriptable ActiveX controls can be useful. For a more complete introduction to IE’s security zones, see http://msdn.microsoft.com/library/default.asp?url=/workshop/security/szone/overview/overview.asp.

Figure 22-4: Customizing security zone properties

ActiveX Controls

The primary policy items affecting ActiveX controls in Internet Explorer are found in Table 22-3. An entry of “Query” indicates that the user is prompted whether to permit the action in question.

Table 22-3: Relevant Security Properties of Internet Explorer’s Security Zones
Template	Default For	Run ActiveX	Install Signed ActiveX	Install Unsigned ActiveX	Java Applets Scriptable?	Safe ActiveX Controls Scriptable?
Low	Trusted Sites	Yes	Yes	Query	Yes	Yes
Medium-Low	Local Intranet	Yes	Query	No	Yes	Yes
Medium	Internet	Yes	Query	No	Yes	Yes
High	Restricted Sites	No	No	No	No	No

Note

Some early versions of Internet Explorer do not have the Medium-Low security template. In these browsers, the Low template is applied to sites in the Local Intranet zone.

Careful inspection of Table 22-3 reveals what you must do to install and access ActiveX controls from JavaScript. First, note that only with the Low setting can unsigned ActiveX controls be installed, and only then after prompting the user for confirmation. A signed ActiveX control is similar to a signed JavaScript in the Mozilla browsers, except that the code being signed is executable, not script. This means that you need to configure your users’ browser to have your site in the Trusted Sites zone if your control is unsigned.

A better approach is to sign your controls. For details on signing controls with Microsoft Authenticode technology, see http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/topics/secapps/Authcode.asp. Similarly, if you wish to install a control without annoying the user with a confirmation dialog box, your site must be in the user’s Trusted Sites zone.

The column of Table 22-3 indicating whether “safe” ActiveX controls may be controlled with JavaScript deserves additional discussion. Developers of ActiveX controls indicate whether or not a particular ActiveX object is safe, that is, whether controlling it from JavaScript could result in malicious behavior. For example, the FileSystemObject has the ability to read and write to the local filesystem. Malicious script that could instantiate this control could use it to wreak havoc on a user’s system. For this reason, the control is not marked safe. It therefore cannot be controlled by script downloaded from the Web. On the other hand, the ActiveX control that plays Flash animations has only benign capabilities: start playback, stop, rewind, and so forth. It is therefore marked as “safe” and can be controlled by script.

If you’re having trouble controlling an ActiveX object from JavaScript, double-check that it is marked “safe.” For details on how to do this, and more information on the security implications of ActiveX controls, see the following sites: