Server Side Includes (SSI) are placeholders (or markers) in an HTML document that the Web server will dynamically replace with data just before sending the requested document to a browser. Should viewers review the resulting HTML from their browsers, they will probably not be able to tell if the HTML was static (fixed) or had been dynamically built by the Web server as it parsed the HTML source code. This is because the SSI commands would have been replaced with the actual contents of the SSI placeholder.
HTML source code files containing SSI commands are often saved with the .shtml suffix instead of the usual .html (or .htm) suffix to ensure the Web server parses the HTML code with an SSI interpreter that looks for SSI commands and replaces these markers with the corresponding data referenced by these commands. Different Web servers support slightly different implementations of SSI. However, Table 6.5 lists six of the SSI commands that are typically available.
Table 6.5: Common SSI Commands
NAME DESCRIPTION
Config Specifies the format of data sent to the browser. Echo Retrieves the value of an environmental variable. Exec Executes a shell command or CGI application. Flastmod Retrieves the last modified date for a specified file. Fsize Retrieves the file size for a specified file.
Include Includes the contents of another file into the current file.
The Include command can be particularly useful to a developer wanting to reuse standard components in multiple Web pages; the common code is dynamically cut and pasted into the requested Web page at the point indicated by the Include statement. For example, let's say a copyright.inc file contains an organization's standard copyright notice that appears at the bottom of every page on its Web site. This enables the organization to change the wording of its copyright notice across every Web page on the site by simply updating this single file. Thus, the following HTML code
would be parsed by the Web server before it is sent to a requester and cause the following HTML to actually be sent to a requesting browser:
<HTML>
<HEAD><TITLE>Show SSI at work</TITLE></HEAD> <BODY>
<P>Lots of really Interesting stuff to read</P>
<P>Copyright 2002 wiley.com all rights reservered</P> </BODY>
</HTML>
The danger with an Include command comes when an intruder is able to manipulate a Web page into including a file that would otherwise not be available. For example, if an intruder is able to gain write access to a directory on a Unix Web server (possibly a .temp directory that didn't have any sensitive information stored in it and was therefore not locked down), the intruder could upload a .shtml Web page containing the following include statement: <!--- #exec cmd="/bin/cat /etc/passwd" --->
By subsequently requesting the uploaded .shtml file from a browser, the intruder causes the Web server to parse the file and attempt to substitute the include statement with the password file using its authority to read the requested file.
Another security risk associated with the Include command occurs when executable code is placed inside a file that will be included in another file. An attacker could download the source code for an included file by directly entering its URL in a browser and then download the file without the source code first being parsed by the SSI interpreter. For example, the include file getHITcounter.inc on the wiley.com Web site could be downloaded by entering the following URL via a browser: www.wiley.com/common/getHITcounter.inc. Being able to review this source code may allow an attacker to discover some internal secret about the application that the developer thought no one would ever see. For example, a database connection string, together with userIDs and passwords, is a common use for include files (a problem expended on later in this chapter).
The Exec command has even more issues associated with it, instead of simply being used to surreptitiously download privileged information. The Exec command can be used to invoke existing (or covertly uploaded) CGI programs or any valid shell command. For example, DOS shell commands such as Ver (which displays the version of the operating system), Dir (which lists the contents of a directory), or Ipconfig (which displays network address information) would all provide useful information to an intruder.
If the SSI Exec command capability is enabled on a Web server, then the only challenge that an intruder faces is trying to figure out a way to trick the Web server into executing a malicious command. The following are two possible ways an intruder could accomplish this:
Uploading an .shtml Web page containing the malicious Exec command to the Web server, and then requesting it via a regular browser (in the same way the Include command could be abused).
Entering the SSI command into a regular data entry field on a legitimate Web page and hoping that the input from this Web page is reused in a subsequent Web page, thereby causing the command to be executed. An example would be the mailing address field on a Ship to Web page being redisplayed on the Order Confirmation Web page.
When programs referenced by an Exec command are executed, they run with the system privileges of the Web service. A Web site could incur significant damage if an intruder were able to install a virus, or Trojan, and then invoke it via an SSI Exec command running with administrative privileges. Therefore, if the Exec command is enabled, the Web service should be checked to make sure it is running with the fewest privileges possible (as described in the sidebar "SSI Configuration Test").
Because the security risks may outweigh the programming benefits of enabling SSI (especially the Exec command), many Web sites simply choose not to enable the SSI interpreter at all. If this is the case, then each Web server should be inspected to ensure that this feature has indeed been disabled. In the case of an Apache Web server, this can be achieved by using the includesnoexec option in the server's configuration file (httpd.conf). To block this feature on an IIS Web server, the SSIEnableCmdDirective entry must not be present in the Web server's Windows registry.
SSI CONFIGURATION TEST
To check if SSI has been disabled, create an HTML/SSI file called testssi.shtml (the.shtml suffix is used to ensure that the Web server knows the HTML file needs to be parsed by the SSI interpreter) with the following lines of code:
<HTML>
<HEAD><TITLE>Test SSI Configuration</TITLE></HEAD> <BODY>
<H1>Test 1 - Is SSI Enabled?</H1> <P>This file was last modified on
<!--#flastmod file = "testssi.shtml" --></P>
<H1>Test 2a - Is SSI Exec Command Enabled on an Apache/Unix server?</H1>
<P>Today's date is <!--#exec cmd = "/bin/date" --></P>
<H1>Test 2b - Is SSI Exec Command Enabled on an IIS/Windows server?</H1>
<P>Today's date is <!--#exec cmd = "c:\testssi.bat" --></P>
<!--Note: For the IIS test to be successful, the testssi.bat file must contain a valid shell
command like "date /t" and the .bat and .cmd file extensions must be mapped to the cmd.exe for this
If SSI is enabled, the Web server will attempt to parse any text that starts with <!--# (and ends with --->). The flastmod SSI command will retrieve the date when the specified file (in this case the test file itself) that was last modified can be used to determine if SSI is enabled.
The SSI Exec command will attempt to run the specified shell command (in this case the UNIX date function or the Windows .bat file) and can be used to determine if the Web server has been configured to permit SSI Exec commands:
If SSI is disabled or is unavailable, both commands will fail.
If SSI is enabled, but the Exec command has been selectively disabled, then only the flastmod command will work.
If SSI is enabled and the Exec command has not been restricted, then both commands should work.
Table 6.6 summaries the SSI configuration checks that a testing team may wish to consider running.
Table 6.6: SSI Configuration Checklist YES NO DESCRIPTION
□ □ Is there a documented policy in place that specifies which SSI commands (if any) will be enabled on the Web server?
□ □ If SSI is not to be enabled, has each Web server been checked to ensure that it has not actually been enabled?
□ □ If any SSI feature is to be enabled, has the Web service on each server been checked to ensure that it is running with minimal privileges? (This is a prudent measure to take even if SSI is not used.)
□ □ If only the SSI Exec command is to be disabled, has each Web server been checked to ensure that this feature has been disabled?