Restrict Browser Functionality | Protect Your Windows Network: From Perimeter to Data

Restrict Browser Functionality

The ultimate application platform is Web browsers. Although you will find thousands of claims as to why one browser (not IE) is more secure than another (IE), these claims overlook one fundamental fact, namely that the entire purpose of Web browsers is to enable users to go to untrusted software publishers and download and run code from them. They are designed to enable a function that is fraught with security problems. To further exacerbate the problem, browser developers have kept adding cool functionality to entice more developers to develop for their platform, thereby making more users use their platform.

To deal with this problem, the principle is really simple. Web browsers should have three things:

A solid patch management model allowing timely and well- tested updates for security problems
A thought-out security architecture that allows granular control of functionality, ideally on a per-site basis, to control what can be done by which sites
Good central manageability tools to enable administrators to centrally control the functionality in requirement 2

To our knowledge, no Web browser today delivers on all these points. IE comes close on 3, has some of 2, but some would argue is deficient in area 1.

The types of functionality that should be restrictable include anything that gives the ability to run code other than display code on a user 's machine. This includes add-ins, scripts, plug-ins, and so on. However, it also includes things such as IFRAMESa way to allow Web pages to put seamless frames on the screen showing one page within another. IFRAMES are commonly used to fool users into believing they are on one site when in reality they are actually on another. Some of the newer Dynamic HTML (DHTML) functionality is also quite dangerous. The ability to position windows offscreen , make windows transparent, or make windows larger than the screen have all been used to fool users into thinking they are looking at something other than what is there. Then there is, of course, the most annoying feature ever invented by stupid programmers: pop-up windows! We have some good suggestions for what to do with the person who came up with the idea of being able to programmatically launch windows . Unfortunately, we cannot find anywhere where those actions would be legal.

Restricting IE functionality is possible using Group Policy. In fact, the amount of power Group Policy gives you over IE is quite significant, particularly under XP Service Pack 2 (SP2). Yes, that is correct: you can manage Group Policy under Windows XP. What we mean here is that you use an XP client to manage domain group policy on the server. The reason is that a lot of settings were added in the user interface on XP SP2, and you will not see those if you manage the policy on a server unless that server is running Windows Server 2003 Service Pack 1 or better.

To open a Group Policy object from a server, open a new MMC instance, add a new snap-in, and select Group Policy. When the dialog comes up that asks you which Group Policy object to select, click Browse and then type in the name of the server. You can also open the object from the command line with a command such as this:

[View full width]

  [View full width] 
 gpedit.msc /gpobject:"LDAP://CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies  ,CN=System,DC=PYN-DMZ,DC=LOCAL"

The first CN entry is the CLSID for the policy, which you get by just looking at the properties of the policy. The first DC enTRy is the name of the domain, and the second is the domain suffix. There may be additional ones, depending on the domain name you are using. When you open this policy object, you have the full XP SP2 UI available. Even if the policy is applied from an older DC, it will make the changes you specify here.

You can lock down IE both by user and by machine. However, certain features can only be restricted by user. To control IE through Group Policy, go to either Computer Configuration or User Configuration, and then to Administrative Templates Windows Components Internet Explorer. Figure 13-3 shows the Computer Configuration display.

Figure 13-3. Internet Explorer machine-based Group Policy configuration interface.

To configure allowed ActiveX controls, you have to go to the User Configuration display. This is shown in Figure 13-4.

Figure 13-4. Internet Explorer user-based Group Policy configuration interface.

We highly encourage you to test locking down the allowed controls in IE. Doing so will significantly limit your exposure to security issues in third-party ActiveX controls. As with all security measures, however, there is a drawback. In this case, it is that many Web sites will stop working. You may want to mitigate that problem by creating separate policies for particular types of users. Some types of users (for example, sys admins) may need significantly fewer restrictions than others (for example, managers).

HTML E-Mail Security

For years, the Internet Explorer security philosophy was based on the premise that if users just would not go to hostile Web sites they would not have any security problems. This would work really well if Google could only get that " hostile Web site identification" feature working. Then all you would have to do is not click the sites with the skull and crossbones icon and you would be safeexcept for one thing. Many years ago now, some genius came up with a way to allow hostile Web sites to come to youHTML e-mail.

HTML e-mail in its original incarnation has to have been one of the worst ideas, from a security perspective, that any programmer could have ever devised. The entire concept of allowing code to be mailed around and automatically executed without any controls or restrictions on what it can do sounds like a bad joke out of a cheap novel . Yet that was exactly what HTML e-mail was. Eventually, but not nearly soon enough, some restrictions were put in place. For instance, Microsoft Outlook and Outlook Express both added the ability to read mail in the Restricted Sites zone. Of course, even the default settings in the Restricted Sites zone are not quite restrictive enough for our tastes. Font download, for example, should never be allowed via e-mail, and it was not until XP SP2 that we got restrictions in place for binary behaviors. (Ever wonder what a "binary behavior" was? Just think of it as an ActiveX component without any security controls.) The rule of thumb is that you need to do two things:

Ensure that all mail is read in the Restricted Sites zone. In Outlook, this can be controlled only via the Office Resource Kit. You could also create a custom ADM template to control this switch. The setting is in HKCU\Software\Microsoft\Office\<version>\Outlook\Options\General\Security Zone, and it needs to be set to 0x4 to be in the Restricted Sites zone. In Outlook Express, there is no way to control this centrally. The setting is made in HKCU\Identities\<profile GUID>\Software\Microsoft\Outlook Express\5.0\Email Security Zone. Because the profile GUID is dynamic and unknown, it cannot be controlled centrallyone of the major reasons not to use Outlook Express in an enterprise. If you use any other mail client that supports HTML mail, you need to ensure that it has equivalent functionality to control what can run. Unfortunately, many ISPs recommend Outlook Express, primarily because of its cost, even though until recently it has had much worse security controls than Outlook.

Block everything in the Restricted Sites zone. Use Group Policy to configure this. The basic rule of thumb is that everything should be set to "disabled" (or whatever the most restrictive setting is) except for the pop-up blocker setting, which is a double negative, and should be set to "enabled" to turn on the pop-up blocker. After you have done that, you end up with a somewhat confusing Group Policy list, shown in Figure 13-5, where everything lists as enabled. That is because "enabled" in Group Policy "enables" you to control the setting and disable it.

Figure 13-5. Configure the Restricted Sites zone in Group Policy to ensure that it blocks everything.

As you may have been able to tell, we are not fans of HTML e-mail. It has gotten better in recent years, however, and one of the authors now uses it. The one advantage it has is the additional expressiveness it affords as well as the portability that you do not get with rich text. We do, however, use the Preview pane and Auto Preview features sparingly, and always ensure that they are turned off in the junk-mail folders.

One alternative to reading mail in HTML is to use the new features in some e-mail clients , including Microsoft Outlook, to enable you to read mail in plain text. Unfortunately, doing so has a great drawback: your users are not really likely to put up with it quietly for very long. HTML e-mail in plain text is an ugly thing. To see the effect for yourself, just turn on the feature (it is in Tools Options E-Mail Options), and then try to read your daily Dilbert mail. Reading mail in plain text would be a very useful mitigation to many HTML- borne attacks, however. We do highly recommend turning it on temporarily in the face of an outbreak. The setting is made in HKEY_CURRENT_USER\Software\Microsoft\Office\<version>\Outlook\Options\Mail in a REG_DWORD called ReadAsPlain. You can configure this with a custom ADM template, for instance. This feature is available in Outlook 10 and 11 (Office XP and 2003).