Instead of using an SSI statement to include a small section of code into a static Web page, dynamic code can be used to build an entire Web page on the fly (dynamically). Dynamic code can be crudely thought of as programming code used to dynamically construct other program code (such as using some VBScript on a server to create the HTML that will be sent to a browser for rendering).
Dynamic code is particularly useful for Web pages whose structure will change based upon user interactions or frequently changing content. For example, a shipping confirmation Web page may contain a line entry for each item the viewer has purchased. Using traditional static Web pages, a developer may have to code a separate Web page to handle a visitor purchasing one item, two items, three items, and so on, or have a single, fixed-length Web page long enough to handle the largest of orders. With dynamic code, the developer can simply write a template that loops around, building the shipping confirmation Web page by repeatedly inserting the HTML code for a single line item until the order is complete.
When a Web server receives a request for a resource that is marked as a dynamic code template (such as a file with a .jsp suffix), the Web server automatically knows to use the resource as a template for building the Web page that will ultimately be sent to the requestor (rather than actually sending the template itself). The Web server parses the template with the appropriate dynamic code interpreter, executing any dynamic code it finds, before sending the template's output to the requestor.
Although dynamic code makes developing Web sites with nonstatic content much more feasible, it does have some security issues. These issues are typically environment specific. For example, an ASP security issue is unlikely to be a problem in a PHP environment. Table 6.7 lists some common dynamic code environments.
Table 6.7: Sample Dynamic Code Environments
NAME ASSOCIATED WEB SITE
Active Server Pages (ASP) and ASP.NET (ASP+) www.microsoft.com
ColdFusion www.macromedia.com ContentSuite www.vignette.com
Instant ASP www.halcyonsoft.com
Sun Chili!soft ASP www.chilisoft.com/sun.com
Java Server Page (JSP) www.sun.com
Personal Home Page (PHP) www.php.net
The details of the most recent security issues that apply to a specific dynamic code environment can be identified by visiting the incident-tracking Web sites listed in Table 4.2. However, a large portion of these incidents can be considered to belong to one of the following general categories of vulnerability.
Viewing the Template
Some of the dynamic code environments have been found to contain defects that, unless patched, allow an intruder to trick the Web server into not processing the template with the associated interpreter. This causes the template's source code to be downloaded, rather than the code that should have been generated by executing the template. For instance, early versions of IIS could be persuaded to cough up ASP source code by merely adding a period to the end of a URL (for example, wiley.com/resource.asp.). The danger with allowing intruders to view the source code is that they may be able to find sensitive information (such as in the following example ASP code) or a weakness in the template's design that they could then exploit:
<%
& ";Password=" & data_password & ";" %>
Templates should therefore be checked to ensure that sensitive information that could be useful to an attacker is not being hard-coded into the templates (such as userIDs, passwords, directory and file structures, and database schemas) and could be potentially viewable to an intruder via an unpatched security hole.
Single Point of Failure
Unlike CGI programs that often run as separate processes, a dynamic code environment may have the template interpreter running as a single process. If the entire Web site is being processed by this single (multithreaded) process, then it may be possible for an attacker to bring down the Web site by submitting input data that, when processed by the interpreter, causes the interpreter to crash, effectively creating a denial-of-service attack on the entire Web site. An example of this would be a sufficiently large input string that causes a buffer overflow error. Hence, the need exists to test any dynamic code to ensure that it is robust enough to handle any erroneous input that could possibly cause it to fail in a catastrophic manner (a topic discussed in detail in the Input Data section of this chapter).
System Commands
In the same way that an intruder could trick an SSI interpreter into executing SSI commands, so can dynamic code interpreters be tricked into executing the system commands that are passed to the Web site via a data input field on a legitimate Web page. Therefore, any input data received from the client should always be parsed to ensure that it does not contain any covert system commands that might be inadvertently executed by a dynamic code interpreter (a topic covered in more detail later in this chapter).
Demonstration Scripts
Vendors of dynamic code environments will often include example dynamic code in their default installations. Unfortunately, as mentioned previously in regard to CGI programs, some of these scripts may not have been exhaustively tested and may therefore contain features that an intruder could exploit. For this reason, many Web sites remove any nonessential demo, training, and utility dynamic code that may have been installed during installation.
Helpful Error Messages
Environments should be checked to ensure that if the dynamic code interpreter encounters an error, they don't give up too much detailed information about the internal workings of the system. For example, IIS/ASP can be configured by the Webmaster to provide different levels of error messages when it encounters an error, the most detailed of which is useful during development, but has a higher security exposure in a production environment. Table 6.8 summaries the dynamic code security checks that a testing team should consider conducting. Traxler (2001) provides additional information on testing some of the more common dynamic code environments.
Table 6.8: Dynamic Code Checklist YES NO DESCRIPTION
Table 6.8: Dynamic Code Checklist YES NO DESCRIPTION
code interpreters (if any) are to be installed on the Web server?
□ □ Have all the known security issues been researched and documented for the specific dynamic code environment that will be installed?
□ □ Have any security patches and workarounds necessitated by a known security issue been implemented on every Web server?
□ □ Have all templates been reviewed for the presence of hard-coded sensitive information?
□ □ Have all unneeded dynamic code scripts been removed from the production environment?
□ □ Has the dynamic code environment been checked to ensure that it does not provide too detailed information about the application, in the event that an application error occurs?