This chapter is from the book
This chapter is from the book
This chapter is from the book
3.4 Client Computer
Today's browsers provide many capabilities that enrich the user experience. Client-side scripting, ActiveX controls, Java applets, and plug-ins provide a level of interactivity that most users now expect to see when they connect to a Web site. In addition, the use of cookies provides a convenient way to maintain a user session by storing some pieces of information on the user's computer. All these technologies come together to enable the creation of the kind of complex user interface and Web system design that most prominent Web sites will want to incorporate.
In recent years, a number of security flaws have been uncovered with many client-side technologies. Even though client-side scripts and Java applets are supposed to offer a high degree of security, flaws in many Web browsers can be exploited by malicious scripts or applets to work around the security of the browser and to access private files on the unsuspecting user's hard disk. As these flaws are identified, Web browser vendors have generally been quick to fix the problem and to distribute a patch.
Although browser vendors must resolve most of the client-side security problems in their browser products, some technologies, such as ActiveX controls and cookies, can be inadvertently used by a site to open up potential security problems on a visiting Web user's computer. This section focuses on ensuring that computers and private data of Web users visiting a site are not made vulnerable to intrusion by attackers through the use of ActiveX controls and cookies distributed by the site.
ActiveX Controls
As one of the more powerful forms of client-side content, ActiveX controls carry significant security implications. Unlike Java applets, ActiveX controls have no safety net. With the use of ActiveX controls, any operating system API call, disk file, or network connection can be used by the control. ActiveX controls can be written in many languages, such as C++, Visual Basic, and Visual J++, and they operate just like any other application installed on the user's computer. The user trusts the content of the control to its author with regard to the potential for the control to do damage.
Microsoft has designed its Authenticode technology to be able to sign controls with the author's identity and to verify that the control has not been modified. Although this does offer some level of security, it does not prevent controls from being tricked into behaving in ways other than those originally intended. In addition, the use of ActiveX controls by a browser are not restricted to any particular site. For example, a control developed for Web site A may be used by Web site B. Web site B can stipulate that users to its site will obtain an ActiveX control from site A, together with defined parameters that are provided from site B. Therefore, when a Web site uses an ActiveX control, any other site that the user may visit can attempt to create this control on the user's machine and to interact with it. Note that depending on the security level set by the user, the browser may or may not prompt or alert the user that the site is attempting to use an ActiveX control, although it probably will display the certificate if the control is being used for the first time. Even with prompts and alerts, the user will probably not be entirely aware of what is happening.
This type of flexibility opens up the possibility that the well-intentioned Web site could provide the means for malicious operators of other sites to exploit a user's machine. Figure 3-8 shows how this could occur.
){kind=link}
A browser can use an ActiveX control in two primary ways.
OBJECT tag. This is the most common way that ActiveX controls are embedded into a Web page. This tag contains several pieces of information about the control, including the location where the browser can go to retrieve the ActiveX control. In addition, the OBJECT tag can contain one or more PARAM tags, which are used to provide the Web page with the parameter values necessary to initialize the control.
Scripts. Client-side scripts can also manipulate the control, calling functions, referred to as methods, to perform tasks and accessing properties to set and to retrieve data inside the control.
Figure 3-8 ActiveX Control Manipulation
Both of these access methods allow information to be passed to or retrieved from the control. For example, a customer service control could be initialized with the user's name and customer number through the OBJECT tag and then queried for those properties later through JScript on the Web page. The ActiveX control can do whatever it likes with this data, such as storing it in memory, placing the value within the registry, or even saving the data to a disk file. Because any site can make use of the control, any site can call methods and access properties of the control. This also opens up the possibility that another site, operated by an attacker, will manipulate the properties of the control through its inputs.
As documented in the section Content Attacks, inputs to a program can be used to take control of a target machine through the creation of a buffer overflow condition. ActiveX controls, if written in a susceptible language, can also be the target of buffer overflow attacks. In addition, when the control's inputs provide for the specification of a file name or a registry key, this information could be used by a malicious Web site operator to access files or areas of the system registry through client-side HTML and scripting. Consider the following vulnerabilities and privacy violations for any of the site's ActiveX controls.
Buffer overflows: The length of any user input data should be restricted to avoid possible buffer overflow conditions, as buffer overflows can be used to execute malicious code on the client computer. See the section Buffer Overflows for more information.
File access: Controls should not be written to accept file names as parameter values within OBJECT tags or function parameters. The file name parameter could be abused by a malicious Web site operator and changed to point to a system or other private file on the user's computer.
Storing private information: Using an ActiveX control in order to store private user information on the client's computer may seem harmless but can potentially expose user information to an intruder, especially when the control provides a means to retrieve that data. As any site can access the control and call its methods, other sites may be able to retrieve the data without the user's knowledge. In addition, if the data is stored in an unencrypted form, intruders who manage to gain access to the client's computer through other means may locate the information by browsing disk files or the registry.
Cookies
Web systems can store small pieces of data on the client computer through cookies. Cookies, supported by most mainstream browsers, are stored in one or more files on the client computer's hard disk. After a Web system forwards the cookie for placement on the user's computer, the cookie value is automatically forwarded back to the Web server in an HTTP message header each time the client computer requests a page from the particular Web site. A typical example of cookie usage is the shopping cart, whereby the item IDs and quantities are stored in a cookie on the user's machine.
Cookies are stored in plaintext files on the user's computer. This means that anyone who has access, authorized or not, to the files on the user's computer can read their contents. This is a problem when a Web server is saving data on the user's computer as a cookie and it contains sensitive information, such as the user's credit card information. An intruder who manages to gain access to a user's file system through a browser flaw, insecure ActiveX or Java control, or a Trojan horse, may be able to access cookie information without the knowledge of the user.
If it is necessary for the Web system to store sensitive information in a cookie on the user's local machine, the data placed in the cookie should be encrypted, using the techniques described in the section Data Encryption. Any Web system components that wish to store sensitive data in a cookie will encrypt it prior to issuing the set cookie command. Later, when it needs to use the cookie information, a component must first decrypt the data.