In How to Keep Your Web Servers Secure , we looked at ways of preventing outsiders from disrupting your web services. This article highlights some of the specific security issues around the use of dynamic code environments, such as SSI, ASP and PHP, and what you can do to minimise the risks.

SSI
SSI (Server Side Includes) are directives that are placed in HTML pages, and evaluated on the server while the pages are being served. They let you add dynamically generated content to an existing HTML page, without having to serve the entire page via a CGI program, or other dynamic technology. If most of your page is static, then SSI saves you having to have the whole page recalculated each time it’s displayed.

From a security viewpoint, though, there are concerns. Although a user can’t read, say, a password file on the server, because they don’t have the required permission rights, they can create a web page that includes the SSI command to go and import that file into itself and display it. If they can now find a directory that isn’t write protected, and doesn’t have its rights tied down, and deposit that page on the server, all they have to do is browse to it. If the file has inherited sufficient rights it will provide the information asked for.

The other way that someone could maliciously invoke an SSI command is to enter it on a legitimate web page, in a data entry field, where that data will be reused as input to another page — for example carrying forward text for bill to and ship to addresses. This might cause the command to be actually executed, using the permission level of the web service itself. Your data validation routines must cater for this and parse the input to ensure no commands are present in order to prevent such action.

If you don’t want to use SSI, then make sure it is disabled — for example on an IIS server, you need to remove the SSIEnableCmdDirective entry in the registry for the web server. And then create an SSI file and try to run it, to make sure.

Dynamic code
If your Web pages are likely to have to change structure based on user input, or contain a lot of constantly changing information, chances are you’ll have to use something more flexible than SSI. Dynamic Code environments, such as Microsoft’s Active Server Pages (ASP), JSP from Sun, or Personal Home Page (www.php.com) let you create templates to build the whole page on the fly before sending it to the browser.

Some of the things to watch for are generic across all platforms, and are of a similar nature to SSI. For instance, like SSI, commands can be inserted into input fields rather than the expected values, so again, data validation must be tested against any possible deviation from the expected input. And since typically one template interpreter handles all calls to that template as a single multithreaded process, anything that halts that in effect creates a denial of service attack on your site.

In older versions of code, it is possible to get the web server to send the template to the browser, not the final output. Since this is in effect source code, make sure that the templates you create do not contain any sensitive information. And one thing to watch out for is the automatic installation of demo code and templates that might have been loaded as part of the installation of your software. This is unlikely to be secure, and should be removed from a production environment.