Rather than trying to develop a single instance of a Web application that will work in every perceivable client environment, some organizations choose to develop multiple variations of the same application, or a portion of an application. An example would be one version of the application being designed for presentation by a Netscape browser (using proprietary extensions only supported by Netscape) and another especially for MS-IE (perhaps using features only found in MS-IE). The Web application then uses information freely supplied by the client (typically as part of the client's HTTP header request) to identify what platform the user is using and then serves up the most appropriate variant of the application.
Taking this concept a step further, instead of basing the adaptive code on the brand and version of the browser installed on the client, the Web application could base its decision on which technologies have been enabled (or disabled) by the user. For example, the login page of a Web site may be used to send a cookie to the client. Upon receiving the corresponding reply, the Web application can check for the existence of a returned cookie. The absence of a returned cookie would imply that the user has either disabled this technology or that the browser simply does not support it. Either way, the Web application
adaptive components of the Web application are represented in the test configurations used to test the application.
JAVA FALLBACK
One approach to handling Java being disabled on the client is to place an HTML-based warning message between the <Applet> tags on a Web page. The message explains to the user why the Java applet's functionality is not available; this HTML will be ignored if Java is enabled in the browser but is executed if it is turned off.
Client Sniffing
Unwilling to trust that a client has taken reasonable security measures to protect their machine from intruders, some extremely cautious Web sites will download mobile code to reconnoiter (or sniff) a prospective client machine. For example, the mobile code may check for the existence of the latest operating system security patch or the most recent antivirus signature file (.dat file).
Once sniffed and assessed, the mobile code reports back to the Web application (and optionally the user as well) what it has found. Aside from the huge privacy issues involved with such an approach, this proactive defensive measure runs the risk that a knowledgeable attacker could either prohibit the mobile code from being executed or even modify the code to report back incorrect information.
If mobile code is used by a Web application for any security-related reconnaissance or enforcement, then the mobile code should be tested using as many of the client environments as it may be expected to be executed in. At a minimum, the mobile code should be tested with browsers that have had their mobile code execution capability disabled or highly restricted, or tested with a browser that simply does not support that particular technology.
Table 5.18 summarizes the checks that a testing team may wish to consider performing to ensure that a Web application will function acceptably and that its security will not be compromised when used by clients with widely varying security settings.
Table 5.18: Client Security Checklist YES NO DESCRIPTION
□ □ Is there a documented policy in place that describes which client-side technologies are necessary for the Web application security to function correctly? And is there a policy for how the Web application should handle a client that does not support or permit one of these required technologies?
□ □ Is the design of the Web application sufficiently robust to handle some clients accessing the Web site from behind a proxy server? □ □ Is the design of the Web application sufficiently robust to handle
some clients accessing the Web site from behind a network and/or personal firewall?
□ □ Is the design of the Web application sufficiently robust to handle some clients disabling cookies?
Table 5.18: Client Security Checklist YES NO DESCRIPTION
□ □ Is the design of the Web application sufficiently robust to handle some clients who do not have encryption capabilities or only have a browser capable of weak encryption?
□ □ Is the design of the Web application sufficiently robust to handle some clients disabling mobile code?
□ □ Is the design of the Web application sufficiently robust to handle some clients disabling tiny windows or floating frames?
□ □ Is the design of the Web application sufficiently robust to handle some clients not wanting to work across multiple domains or enable redirects?
□ □ Is the design of the Web application sufficiently robust to handle some clients not wanting to allow automatic software updates?
□ □ If client-adaptive code is used by the Web application, do the application's security capabilities still work with all client-side environments?
□ □ If client-sniffing is used by the Web application for any security precautions, can the application's security be compromised by disabling or restricting mobile code execution on the client?
□ □ If client-sniffing is used by the Web application for any security precautions, can the mobile code be easily reverse engineered or modified in such a way as to send bogus security information back to the server-side component of the application?
If the Web application is found to frequently only work in an extremely liberal security environment, then the organization may wish to reconsider deploying the application in its current state, potentially reworking the application to make it work with less demanding client-side environmental requirements.
Summary
At a simplistic level, the client-side application security tests described in this chapter can be grouped into two categories. The first consists of those that are designed to ensure that the Web application's security capabilities function correctly for the good guys, providing acceptable usability, performance, and compatibility. The second set of tests (that are often not as frequently employed) attempt to establish that the application's security implementation is robust enough to stop the bad guys from trying to gain unauthorized access to the application's resources (data, functionality, or connectivity).
What percentage of its resources the testing team should spend on positive testing (making sure it works) for the good guys, versus negative testing (making sure it can't be broken) for
Chapter 6: Server-Side Application Security
Overview
Wouldn't it be nice if a Web site's perimeter defenses completely protected it from all external intruders? And wouldn't we all rest easier if we knew that a Web application's client-side components would always ensure that users only submit nonmalicious input to the application's server-side components? The reality, of course, is not quite as idyllic. Unfortunately, a supposedly well-configured perimeter firewall may have an as-yet- undiscovered hole or be completely circumvented by an employee attacking the Web site from a machine located behind the perimeter firewall. And since few organizations have any control over the machines that Internet users will use to access the Web application, there can be no guarantee that any client-side checks have actually taken place or been done the way they were intended to be performed. For these reasons alone, a Web application designer would be well advised to include additional security precautions on the server-side as well. These precautions should be checked by the testing team to make sure that they have been implemented correctly.
Breaking through a multilayer defense that employs safeguards at each and every juncture is much tougher than breaking through a single layer (such as a Web site that solely relies upon a perimeter firewall). The previous chapter focused on testing the security of the client-side component of a Web application. This chapter will focus on what needs to be checked on the server side by looking at the different technologies that may have been used. It will then examine the vulnerabilities associated with each technology and consequently what features the testing team should check to determine if a specific implementation is vulnerable.
The sections in this chapter can be conceptually grouped into three topics. The first group focuses on the vulnerabilities associated with programming technologies that are specific to Web implementations, such as Common Gateway Interfaces (CGI), Server Side Includes (SSI), Active Server Pages (ASPs), and Java Server Pages (JSP), and then general vulnerabilities that are applicable to all server-side application code. The second grouping looks at what can be done to guard against invalid input data being received by the Web application and then subsequently what defenses can be put in place to protect legitimated data stored on the Web site. Finally, the last section in this chapter looks at the controversial topic of using client behavioral patterns to detect compromised application security.