11.5 Server-side includes

Server-side includes (SSIs) are directives that are written into HTML files, and that are executed by the Web server when the corresponding HTML files are delivered. For performance reasons, a Web server must be told whether it has to look for SSIs or not. This is usually done in the configuration settings of the Web server.

In general, an SSI may look as follows (the operator and arguments are summarized in Table 11.4):

< !-#operator arg1="x" arg2="y"... - >

Table 11.4: Operators and Arguments for SSIs
Operator	Arguments (meaning)
echo	$DOCUMENT_ NAME (echoes current filename) $DOCUMENT_ PATH (echoes path to the current filename) $DATE_ LOCAL (echoes current date and time on local host) $DATE_ GMT (echoes current date and time in Greenwich time) $LAST_ MODIFIED (echoes lastmod data on current filename) plus all the variables that are available to CGI scripts
include	virtual /x/y (includes file /x/y relative to document root) file /x/y (includes file /x/y relative to current directory)
fsize	x (echoes bytesize of file x)
flastmod	x (echoes last mod date of file x)
cong	errmsg (configures generic error message for SSI failure) sizefmt (configures fsize format) timefmt (configures time format)
exec	cgi (string treated as path to a CGI script) cmd (string passed to /bin/sh and executed directly)

For example, the SSI < !-#fsize arg1="/etc/passwd"- > would return the bytesize of the password file.

From a security point of view, most SSI operators look innocent and are not dangerous to use. For example, the echo operator can only be used to provide information about the current date and time, or about the current file. Similarly, the fsize operator returns specific information (i.e., the bytesize) of a file. There is, however, one dangerous operator: exec . Note that this operator can take a string argument and pass it to the operating system for execution. Consequently, it can be (mis)used in many ways. For example, an insider can use the exec operator to invoke any operating system command. Also, there may be situations in which an outsider can provide input that is passed to the exec operator. In fact, one can easily imagine a situation in which an outsider is asked to enter a user name and this user name is passed as an environment variable to an operating system command for execution. For example, the following SSI uses the finger command on a UNIX system to display some information about the user specified in the $QUERY_STRING environment variable [6]:

< !-#exec cmd="finger $QUERY_STRING"- >

In this example, an arbitrary command can be encoded by an outsider entering a user name by adding a semicolon and the command after the user name. If, for example, the outsider entered oppliger; ls -al in the HTML form requesting the user name, the SSI would execute finger oppliger and ls -al. Obviously, there are many similar examples one may think of. There are, at least, two recommendations to make:

Once again, it is very important to validate user-supplied input data.
If possible, access to the exec operator should be denied .

An Apache Web server is usually configured to enable SSI by putting in the server options the directive Options Includes . By replacing Options Includes with Options IncludesNOEXEC , one can enable SSIs but deny access to the exec operator.

Due to the fact that SSIs are still rarely used today, there are only a few studies and investigations about the security implications of SSIs (e.g., [7]). This is unfortunate and will likely change, if SSIs are more widely deployed.