Client-Side Risks

Just as servers are, clients too are at risk in Web applications, especially those on the Internet. It is possible for Web browsers to unknowingly download content and programs that could open the client system to crackers and automated agents all over the Net. Malicious programs could collect and send sensitive and private information from the client machine to Net programs and servers that collect such information.

As a general rule, pure HTML 3.2, without client-side scripting, is rather secure. There is little that a Web page designer can do to extract or to breach a client's security. Client-side risk usually involves the following technologies:

Cookies

Except for cookies, each of these technologies is used by Web site and application designers to make the client itself more dynamic: animation, fly-over help, sophisticated input controls. Cookies represent a direct risk only when Web application designers use them to hold sensitive information, such as private IDs and passwords.

As discussed in Chapter 3, cookies are little pieces of information that a server can request a client to hold on to, thereafter passed back to the server on all subsequent HTTP requests. Cookies can be either transient, ending with the browser session, or retained on a near permanent basis. Typically, cookies are used by Web application environments to help the server keep track of a single client browser's session as it navigates the Web application's pages. Permanent cookies can be used as virtual admission tickets. When visiting a site for the first time, a user enters certain information to allow access; all subsequent accesses to the system request the cookie and, if valid, immediately give the client access.

Cookies can become a serious risk when one application gets access to another's cookies. An unscrupulous Web site might trick a browser into thinking that it was a another site and request the cookie for that site. If the cookies contained personal identification informationadmission ticketsthis would allow the Web site owners to impersonate a validated user of that system.

In addition to data security, another type of security issue may be important: privacy. The proliferation of banner ads centrally controlled by a few companies means that these companies can begin to track a given browser's visited Web sites. Advertisers are interested in this because it enables them to target more suitable ads to Web site visitors. Privacy advocates are concerned because this type of tracking typically is unknown by the user and, when combined by some of the other threats, can lead to a serious security breach of personal information.

JavaScript

JavaScript, not to be confused with Java, which is a completely different technology, can be a serious threat to the integrity of personal information on the client. Since its introduction, JavaScript bugs and security holes have appeared at a consistent rate. Most of the security breaches have been the ability for scripts to gain access to files on the client machine, or to obtain sensitive information from the browserlike navigation histories or information in other frames.

One of the many early bugs and security holes detected in first-generation JavaScript-enabled browsers was the file upload hole. In this bug, it was possible for a script to trick the browser into uploading any file on the local system by a submitting a form to a server. Password files and other sensitive files could be unknowingly sent to servers.

Although not as obvious a threat to security, client scripts can collect information on the navigation histories of the user by monitoring a user's session. Some variants of this hole capture all the URLs that a user visits, including any information used to fill out forms. Even though data or software located on the user's machine cannot be modified, the detailed knowledge that can be gained is a violation of a user's privacy.

Java

The use of Java on the client is typically in the form of applets.[4] Security issues relating to applets usually center on

[4] A good source of current security information related to applets and Java in general can be found on the JavaSoft Web site: http://www.javasoft.com/sfaq.

In the original JDK, the security model was fairly restrictive and described by the sandbox model. Remote Java code was allowed access to only a restricted set of functions on the client. Essentially, Java was allowed to play in the confines of a small sandbox.

In general, applets loaded over the Net are considered "untrusted" and prevented from reading and writing files on the client file system and from making network connections except to the originating host. In addition, applets loaded over the Net are prevented from starting other programs on the client. Applets loaded over the Net are not allowed to load libraries or to define native method calls. If an applet could define native method calls, it would have direct access to the underlying computer. Figure 5-3 shows the security model for the JDK 1.0 release.

Figure 5-3. The JDK 1.0 security model

For some applications, this model was too restrictive. Under pressure to provide more functionality, the JDK 1.1 security model was expanded to allow digitally signed applets to be treated as if they were local code (Figure 5-4). As discussed later in the chapter, a digital signature encrypts a software module such that it is possible to determine, with reasonable certainty, that the code originated from the specified author without modification by a third party. A certificate authority (CA) is a third-party organization that can be trusted by both the server organization and the individual client.

Figure 5-4. The JDK 1.1 security model

Signed applets, together with their signatures, are delivered to the client in JAR (Java Archive) files. JAR files combine multiple Java files into a single file, which can then be signed and delivered to the client (Figure 5-5). In JDK 1.1, unsigned applets still run in the more restrictive sandbox.

Figure 5-5. Delivery of digitally signed applets as JAR files

The user has the option of accepting signed applets and examining the signature to determine whether the source can be trusted. If the applet is accepted, the Java code will run as if it were local code and will have all the privileges of any other application running on the client computer.

With the latest Java release, Java 2 (JDK 1.2), the security model has evolved to allow more control over which privileges any given component has access to. Even Java applications originating on the local machine are subject to implementation of custom security policies. The class loader is responsible for locating and fetching the class file, consulting the security policy, and defining the class object with the appropriate permissions (Figure 5-6).

Figure 5-6. The Java 2 security model

Despite all this attention to security by the designers of Java, the problem remains of bugs and poor implementation of the Java Virtual Machine, which can make even the most restricted applets dangerous. Because the most serious security bugs are in the implementation of the virtual machine, the security issues resulting from bugs are usually related to a particular operating system and version. One of the most glaring of these is the bug in the Windows NT 4.0 SP3 version of the virtual machine, which results in the infamous Blue Screen of Death (BSOD). It seems that when even a trusted applet attempts to draw outside the bounds of a Java canvas, the entire operating system crashes.

ActiveX

The issues related to security for ActiveX content are similar to those for Java applets. The risks to the client are generally damage to the system or theft of private information. An ActiveX control embedded in an HTML page is essentially a compiled module, with free access to all the resources on the client. The potential for serious damage to the client operating system is slightly more than with applets because ActiveX controls execute only on Windows platforms,[5] and consequently, knowledge about the client operating system is more detailed.

[5] Emulators may be available to execute COM objects on non-Windows platforms, but the general rule remains: ActiveX content is for Windows-based clients.

ActiveX controls are COM objects; thus, they are binary modules that execute directly on the operating system (Figure 5-7). There is no virtual machine to insulate operations and to provide a security buffer. The principal security mechanism for downloaded ActiveX controls is code signing. There are no restrictions to what the ActiveX control can do once it is loaded and executed on the client. All implementation of security measures happens at the point the component is being requested to load on the client. Some security precautions are implemented by the browser. Internet Explorer can be configured to automatically reject all requests to load ActiveX or Java components. These settings can be configured to prompt the user each time a control is loaded or to trust everything.

Figure 5-7. ActiveX security model

Internet Explorer also has the concept of security zones. In a security zone, a subset of the network domain, the user can identify all the hosts in it as trusted or not. For example, hosts on a company intranet can often be considered secure and therefore ActiveX content on these hosts implicitly trusted. Hosts on the public Internet, however, are by default considered untrusted. The user has the ability to identify regions of the Internet, using the domain name server (DNS), as secure. For example, I might trust Microsoft and set up my browser to implicitly trust all sites in the microsoft.com domain.

ActiveX controls are packaged in Cabinet (.cab) files and digitally signed by the author. The signature, like those for JAR files, is verified by a trusted third party, such as VeriSign or Thawte Consulting, using public key encryption technology. It is very important to understand that code signing verifies only the identity of the author and that the module has not been tampered with. It does not impose restrictions on its execution or imply that the component is safe for use on the machine.

Plug-ins and MIME Types

A plug-in is an external program or module that is manually installed by the user to augment the functionality of the browser. Plug-ins were the original way to extend the browser's feature set with Netscape's Navigator. Plug-ins are operating system dependent; separate versions of a plug-in are required for each operating system.

The most common use of a plug-in is to act as a viewer of special MIME types (Figure 5-8). MIME (Multipurpose Internet Mail Extensions) is a freely available set of specifications that enable e-mail and Web sites to work with media types other than text: images, sound, video, and so on. Originally defined for e-mail, MIME has been used widely on the Web. The list of public MIME types is continually increasing. For each MIME type, the client must either natively be able to render the information, as with GIF and JPG files, or have an external viewer installed and configured to render the information.

Figure 5-8. Plug-ins are often used as MIME type viewers

Plug-ins have the same security issues as ActiveX controls, because they too are implemented as native executables. The principal security mechanisms for plug-ins are built in to the plug-in itself. The browser can do little to restrict a plug-in once it has been loaded and executed.

Depending on the plug-in, additional security issues might arise about the content it renders. For example, a PostScript viewer may be tricked into changing the password of a printer that has not been assigned one yet. All further requests to print will then be denied until the password can be reset manually. Other MIME types and viewers may have similar security concerns.

Related

Категории