After a user has been identified and authenticated as legitimate, the Web application runs the risk that this (now-trusted) client machine will be successfully compromised by an attacker, allowing the assailant to access the application using the privileges intended to be bestowed upon a legitimate user.
Although the onus may be upon the users (or their technical support personnel) to ensure that any session that they initiate with a Web application is not hijacked via an intruder gaining access to their client machine, the precautions that users may seek to employ in order to protect their machines can have a direct impact on the functionality of a Web application. A Web application should therefore be tested to ensure that it is still usable, even when accessed by clients with reasonable client-side security measures in place. For example, an application that is completely dependent upon a user granting a Java applet (downloaded from the application's Web site) unfettered access to the client machine, may find that a significant proportion of their users refuse to grant this code such access, and are consequently unable to use the Web application.
The following sections look at some of the precautions a user could be expected to take and therefore what client-side environments the testing team may wish to consider emulating in order to ensure that the Web application functions with these fortified-minded clients.
Firewalls
Many organizations use proxy servers to manage their employees' Internet access, improve performance, and also provide their employees with a degree of anonymity. Unfortunately, this level of anonymity can prove problematic to Web applications trying to authenticate a user based on some piece of information that the proxy server is masking. An example of this would be the proxy server replacing the network address of the client machine it serves with its own. Allen (2001), Rubin (2001), and Zwicky et al. (2000) provide additional information on securing firewalls.
Another consideration is the filtering that a network or personnel firewall may perform. An organization's perimeter firewall is typically used to provide some level of protection from an attack originating outside the organization. A PC-based (or personal) firewall (often used in conjunction with an antivirus program) is often deployed to stop internal colleagues (or, in the case of home users with cable modems, their neighbors) from attempting to compromise machines via local network connections. Either way, communication between the client-side and server-side components of a Web application may be inhibited by the firewall if the Web application is designed to use unusual methods of communication (such as via a port other than port 80 or 443 or using a network protocol other than HTTP or HTTPS). Table 5.16 lists some sample personal firewalls, and Table A.3 lists some sample network firewalls and proxy servers.
Table 5.16: Sample List of Personal Firewalls
NAME ASSOCIATED WEB SITE
BlackICE www.networkice.com CyberGatekeeper www.infoexpress.com
CyberwallPLUS www.network-1.com
eSafe Desktop www.esafe.com/ealaddin.com
FireWall www.mcafee.com F-Secure Distributed Firewall www.f-secure.com
Internet Connection Firewall (ICF) www.microsoft.com
NeoWatch www.neoworx.com Netfilter/iptables www.netfilter.samba.org Norton Personal Firewall www.symantec.com
Seattle Firewall (ipchains) www.seawall.sourceforge.net
ZoneAlarm www.zonelabs.com
Browser Security Settings
A number of browser-based technologies have the potential to do harm to a client machine using a browser to access a Web application. Recognizing the concerns of their users, most browser manufactures allow users of their products to disable some or all of these potentially dangerous capabilities (although it should be noted that these options vary from browser to browser).
Having a Web application that works fine on a developer's desktop where liberal security settings have been used (thereby making it easier for the developer to get the software to work) does not guarantee that the application will function correctly for all the clients. This is due to users disabling or limiting some of their browser's capabilities for security or privacy reasons.
In the case of an intranet or extranet, users may not have any control over their choice of browser or browser security settings. This makes for a homogenous set of client machines that can be easily replicated by the testing team to ensure that the Web application being tested will work correctly in this tightly controlled environment. However, this does not take into account the issue of what happens when the organization decides to upgrade their version of browser or operating system.
Unfortunately, the same is not true for Internet-based Web applications. Although the vast majority of Internet users never change any of their browser's (typically liberal) default security settings, the larger the number of these suspect technologies that a Web application uses, the more likely it is that one or more of these technologies will be (rightly
Even if a particular technology is specified in the Web application's requirements (and any corresponding end-user agreement), a user-friendly Web application should degrade gracefully (if only to issue a warning message), rather than simply not function and thereby confuse and frustrate the user.
Whichever technology is used, the Web application should be tested using different combinations of browsers and operating systems with varying client-side security settings. Techniques such as orthogonal arrays (or all-pairs) can be used to help mitigate the possible combinatory explosion that such exhaustive compatibility testing may cause. Hedayat (1999) and Kaner et al. (2001) provides more information on orthogonal arrays. Table 5.17 lists some tools that can be used to help pair down the number of possible environmental permutations.
Table 5.17: Sample List of Orthogonal Array Manipulation Tools
NAME ASSOCIATED WEB SITE
AETGWEB www.argreenhouse.com RdExpert www.phadkeassociates.com StatLib (oa.c and owen) www.lib.stat.cmu.edu
The following are some of the most common client-side security settings that should be considered when evaluating whether or not a Web application will function correctly on a client machine due to a user's security concerns. The higher (or more restrictive) the security settings that the Web application is able to still functional correctly with, the more likely the application will actually be used by its intended audience. At a minimum, consider checking that the Web application can still provide expectable functionality with the default security settings of the most commonly used versions of browsers.
Cookies
Primarily because of privacy concerns, many Internet users choose to block cookie use partially or completely. This could be a problem if the Web application's security depends upon this feature being enabled.