It’s difficult to imagine running your business without web servers, whether they are for internal-only corporate information, or to allow your customers and partners to interact efficiently with you. But the applications that let you create usable web pages can let other people access things they shouldn’t.

This article looks at how you can ensure that outsiders can’t steal your information or destroy your server. We’ll look at some standard guidelines first, and in the next article ‘Building dynamic web pages’ we’ll look at the issues specifically relating to changing the structure of your web pages using dynamic code.

Input Data
One of the biggest security risks comes when people are allowed to import data into your web environment. If everything was read-only, it would be more (though still not completely) secure, but it is obviously impossible to sell merchandise over the Internet if customers aren’t allowed to enter any data.

There are various vulnerabilities involved in getting data into web applications, and in most cases this isn’t something that can be solved by judicious use of firewalls and access lists.
A web application may include a drop-down box that lets you choose the month of your birth, say. Maybe you’re selling insurance, or it’s part of a lifestyle survey. While most users would just select the appropriate number, someone with a bit of HTML know-how could edit that area to allow them to enter free text. Your web application must be able to handle that without either crashing the entire server, or, potentially worse, executing that string as a command.

Similarly, if it’s not a drop-down box but free text is allowed. The question of your birth month would, you would expect, result in a one or two digit number and the program might be written to expect a field of that length. If someone enters a ten-digit number, you would want them to just get an error. This relies on the level of data validation done on the input data before it is processed. Scripting tools are available, such as AutoTester ONE, WebFT and WinRunner (see links at the end of this article), to help you check for correct operation of your data validation routines.

One aspect of erroneous data input is the potential for an attacker to cause a buffer overflow by sending back so much data that the memory assigned for that part of the program is exceeded, causing the program to fail, crashing the web server and hence causing a denial of service attack. It’s also possible for the attacker to insert a command into the data input, in the hope that it will be put into an area of memory from where it might be executed, with the rights inherited from the program that is running. It’s therefore essential that you test your system for buffer overflow behaviour, creating test overflows to ensure that your validation checks work.

CGI
The Common Gateway Interface is typically the protocol used to allow the web service on your server to interact with other programs such as database or application services on the same or other servers. Because of this, if it can be hijacked, it can be used to create massive disruption, so there are some safeguards you should implement.

Don’t allow CGI programs to be uploaded over the Internet to the Web server, as an attacker could potentially install one in a directory with privilege rights, and then would just need to browse to it to execute it. A CGI program run in this manner could install files or directories on your server, modify or delete existing files and copy and email out whole directories of confidential information. Any process that calls CGI programs should have minimal privilege rights, so that if a process is used to run an illegal program, it may be limited in what it can do.

Similarly you shouldn’t allow CGI to be downloaded from the server as this just allows a potential intruder to capture it, dissect it as leisure and identify security holes that wouldn’t otherwise be obvious.

If you use compiled CGI programs, make sure the original source code has been removed from the server, If you are using scripted CGI (simpler and often quicker to write, but more resource-intensive to run), then the interpreter should be in a different directory from the code, to allow the most restrictive permissions to be set for the two different objects.

Normally, every time a CGI program is run legitimately, a copy is loaded into memory. This has obvious scalability issues in terms of both how the server will cope under normal pressure, and the potential for a denial of service attack, so it’s important to test how your server handles increasing load - will it degrade gracefully or just fall over?

You can get some pointers and HTML verification tools including a CGI test harness, from the Web Design Group .

ISAPI, Microsoft’s Internet Server Application Programming Interface is a multithreaded alternative to CGI, so only needs to be loaded once and therefore reduces the scalability concerns. Similar APIs are available for Netscape and Apache web servers.

Application code
Anything that might give an intruder a clue as to sensitive data or even just the way the server is structured is valuable to them. Always assume that someone might be able to read all source code (not just the client-side code). Yes, comments in source code are very useful - but they’re equally as helpful to an attacker, so remove them in the production version. You can keep a commented copy on another server that isn’t out in the public domain.

When you write error messages, weigh up user friendliness against security. An ‘incorrect password’ message gives a lot more useful information than an ‘incorrect login’ one, since the intruder now knows a valid user ID has been guessed. Make life as difficult as possible, and an attacker will probably go someplace else for easier pickings.