The race to produce more flexible and functional Web applications requires some degree of client-side code, so many Web sites include code that's executed in the browser. Examples of such code include the following:
Client-side code serves two main purposes: The first is to offload work from the server. If work is performed at the client rather than at the server, the cost of a round-trip to the Web server is avoided. The second is to boost functionality. There are many things HTML simply cannot do; after all, HTML is a text layout language and nothing more.
Running client code carries risks, however. You might not be
able to tell whether the code is malevolent or
As a Web site developer, you should determine what capabilities are required by your applications and then choose the technology that most closely maps to those capabilities. In a way, it's a twist on the least privilege rule: use the technology with the fewest capabilities that gets the job done.
The threats based on security
If your business needs require you to use technologies like Java and ActiveX, make sure you digitally sign the component. More information on signing code can be found at http://msdn.microsoft.com/workshop/security/authcode/signfaq.asp . Also note that you can selectively disable ActiveX components from running by setting the "kill bit" on the component. Refer to Knowledge Base article Q240797, "How to Stop an ActiveX Control from Running in Internet Explorer," at http://support.microsoft.com/support/kb/articles/Q240/7/97.asp for more detail.
Security zones, introduced in Internet Explorer 4, are an easy way to administer security because they allow you to gather security settings into easy-to-manage groups. The security settings are enforced when you browse Web sites. The main tenet behind security zones is that some Web pages need to be handled with specific security restrictions depending on their host Web site, thereby matching security restrictions with Web page origin. In essence, zones are a form of security policy that is enforced when you browse certain classes of Web sites.
Another goal of zones is to reduce the number of times a user is prompted to make a security decision. If a user is asked to make
The security settings that can be assigned to the various zones are as
The zones and their default security settings included in Internet Explorer 5 are described in Table 4-1. For most users, the default security settings should be safe enough without sacrificing functionality.
Table 4-1. Internet Explorer zones and their default security level settings.
Any computer on a corporate intranet is in the Local Intranet zone. A corporate intranet computer is defined as any site that does not require access via a proxy site or that has no period in its URL (for example, http://merlin ) or in its Universal Naming Convention (UNC) pathname ( \\merlin\data ).
The default security level for Local Intranet is Medium-Low.
This zone includes sites explicitly trusted by the user—in other words, sites you believe to be
For example, if you trust your own corporate Web site, you might add it to the Trusted Sites zone.
For extra safety, you can also require that all Web sites in this zone have an SSL/TLS connection.
By default, no Web sites are included in this zone and the security level is Low.
This zone is the
By default, the zone has no sites and its security level is High.
This zone includes all sites that are not on your intranet and not listed in any other zone, and it does not include your local computer.
The default security level for this zone is Medium.
The IEAK is an administration tool for Internet Explorer that allows administrators to determine how Internet Explorer is configured. Some of the security features that can be enabled with the IEAK include the following:
You can find out more about the IEAK at http://www.microsoft.com/ie/ieak .
Zones and the Dotless-IP Address Dilemma
If your knowledge of TCP/IP addressing is
excellent, you might be aware that an IP address can appear either as dottednotation, such as 126.96.36.199, or as a number with no dots. For example, the IP address 188.8.131.52 would be represented by the number 2652335887. Because no period appears in the address in this form, you might think that Internet Explorer would consider the site an intranet site.
If this were the case, it would create an interesting security vulnerability: a Web site could trick your browser into visiting a part of the site with malicious content by using an address format (such as http://2652335887 ) associated with
intranets. Then the browser would run the content with fewer security measures. However, this is not the case in Internet Explorer 5. When browsing to a Web site with an address composedcompletely of numbers, the browser considers the Web site to be in the Internet security zone, even if the site is an intranet site.
You can calculate a dotless-IP address by taking a dotted-IP address—that is, an address in the form a.b.c.d—and using this formula:
Dotless-IP = (a x 16777216) + (b x 65536) + (c x 256) + d
So that you are not vulnerable to this kind of attack, make sure you update your browser if you are running Internet Explorer 4.0 or 4.01—the benefits of Internet Explorer 5.0 greatly outweigh the time it takes to perform the upgrade. Also, refer to Knowledge Base article Q168617, "Update Available for Dotless IP Address Security Issue," for more information on this matter.
Other Internet tools can use zones because support for zones is built into the
You can now set the zone, as shown in Figure 4-3, in which e-mail will be opened; it's highly recommended that you choose the Restricted Sites zone. When you open an e-mail with dynamic content embedded in HTML-formatted text, the HTML will execute as though it came from a distrusted Web site.
More information about security zones can be found in Knowledge Base article Q174360, "How to Use Security Zones in Internet Explorer," at http://support.microsoft.com/support/kb/articles/Q174/3/60.ASP .
Securing E-Mail Containing HTML
It's very easy to send e-mail from a
bogussource because many SMTP servers do not authenticate the sender first. For example, an attacker could send a fake e-mail to you from your manager. It's a common prank! A knowledgeable user will know to look at the SMTP headers to see that the user was not authenticated, but most e-mail readers hide the headers from you by default.
This can be an issue for e-mail readers that use HTML-formatted text. You might decide to trust e-mail from a specific location (because of your zones configuration), but an attacker could spoof a trusted address and send you a malicious HTML-based e-mail message that is a security threat to your system.
A way around this is to use digitally signed e-mail using technologies such as S/MIME (Secure/Multipurpose Internet Mail Extensions), which Microsoft Outlook 2000 supports. When you digitally sign an e-mail message, users can verify that the message was not tampered with and thus that the message came from you and not an imposter.
Figure 4-3. Setting zones in Outlook 2000.