Internet Explorer Security Options, Part 5

In Parts 2 through 4 of this series, I described the settings in Microsoft Internet Explorer (IE) 5.0. (To locate Parts 1 through 4 of this series, select one of the related articles from the Article Information box at the right.) In Part 5, I'll describe the remaining IE security settings.

Scripting
To access IE's security options for scripting, open IE, go to the Tools menu and select Internet Options, and select the Security tab. Click the zone you want to configure, and click Custom Level to display the Security Settings dialog box. Scroll to Scripting, as Figure 1 shows.

Active scripting. The first setting under Scripting is Active scripting, which you can set to Disable, Enable, or Prompt. If you set Active scripting to Disable, IE doesn't display any warnings and doesn't run any scripts. If you set Active scripting to Enable, IE will run all scripts on the Web pages you visit. For instance, on the Windows IT Security home page, you can enter an InstantDoc ID number to instantly access an article. A client-side Java script checks the format of your article number and notifies you of any errors—you don't have to wait for the Web server to check and format a Web page. If you set Active scripting to Prompt, and you subsequently browse a Web page that has client-side embedded scripts, IE asks you to confirm each script's execution on the page, as Figure 2 shows. For instance, if you set Active scripting to Prompt and you browse Windows 2000 Magazine, the dialog box prompt appears three times.

Client-side scripts are very useful, and contribute to the highly functional Web we use every day; however, you should be aware of some dangers. Although a client-side script's functionality is much more limited and safer than ActiveX, attackers can use active scripting to write viruses and other malicious code. The dangers associated with active scripts come in three forms. First, a malicious Web site operator can design a page that contains harmful code. Second, Web sites that let users post HTML content (e.g., online auction sites) inadvertently provide the opportunity for a malicious person to post innocent-looking content that contains a client-side script to attack legitimate Web-site users. Third, individuals and advertisers now can send HTML-based email messages, and most email clients, including Microsoft Outlook and Outlook Express, process any HTML-based email, including client-side active scripting. HTML-based email that includes active scripting is more dangerous than Web pages that include active scripting because an attacker targets specific users, whereas on the Web, an attacker must wait for a victim to visit the Web site.

You can decrease the risk of running active scripts in Outlook and Outlook Express by configuring your email client to process HTML-based email using the security settings you define in IE for the Restricted sites zone; I recommend that you do so. First, use the maximum security settings in IE, including disabling Active scripting, to configure the Restricted sites zone. (I don’t recommend that you enable Prompt for Active scripting because this setting annoys users. If you want maximum security, you need to disable Active scripting for the Internet zone, enable it for the Trusted sites zone, and add sites to the Trusted sites zone as your users need access.) Next, open Outlook or Outlook Express, and select Tools, Options. Select the Security tab, and select the settings that provide maximum security.

Allow paste operations via script. Similar to the File download policy we discussed in Part 3, Allow paste operations via script controls whether scripts on Web pages can access your clipboard. If you enable this paste operation setting, scripts can copy the contents of your clipboard without your knowledge. If you're like me, you have several different passwords, you have installed a secure password storage application, and you frequently copy and paste your passwords into Web pages and other applications when you need to log on. Because you don't want to wonder whether you have any confidential information on your clipboard, I recommend that you set this second scripting option to Prompt or Disable.

Scripting of Java applets. The third scripting feature, Scripting of Java applets, controls whether client-side scripts can use objects in Java applets. Because Java scripts and applets work together closely, I recommend enabling this option if you enable Active scripting.

User Authentication

The only option under User Authentication is Logon, as Figure 3 shows. Logon controls how IE responds when a Web server requests authentication. Web servers such as Microsoft Internet Information Server (IIS) support the NT LAN Manager (NTLM) Challenge Handshake Authentication Protocol (CHAP). IE uses CHAP to authenticate the user to the Web server using the username and password that the user specified when he or she logged on. You can manage access control on intranet Web servers based on the user's domain account, which is transparent to the user. But because a malicious Web site operator can trick IE into responding to a NTLM challenge, using an NTLM challenge on the Internet is dangerous. The attacker can use a tool (e.g., L0phtCrack) to obtain the password by cracking the response. For an even more sinister, targeted attack, a malicious intruder can send an email with a link back to the attacker's Web site, which sends an NTLM authentication challenge when the user clicks on the link. If the systems administrator has not configured IE securely, the onsite server encrypts that challenge with the user’s password hash as the key and sends it back as the response. The attacker then feeds the challenge and response pair into L0phtCrack to crack the user’s internal domain password.

Therefore, I recommend that for communicating with computers outside your trusted network, it's important that you don't use the Automatic logon with current username and password setting. For your Intranet zone (and perhaps Trusted sites zone, if you use that zone for business partners in an extranet scenario), I recommend that you set Logon to Automatic logon only in Intranet zone. For your Internet and Restricted sites zone, you should use Anonymous logon or Prompt for user name and password. If you select Anonymous logon, IE won’t respond to authentication requests. If you select Prompt for user name and password, IE won’t automatically respond to authentication requests with the user’s domain credentials; instead, IE displays a window asking the user for credentials.

As you can see, you have many security settings in IE to configure for each zone. In Part 6, I’ll show you how to use Group Policy to configure the options centrally for all your users.