CGI and Perl

Security on the Web

  • General Server Security
  • Data Security
  • CGI Security
  • Transaction Security
  • Other Considerations
  • Further Reading

Any type of server you run at your site may introduce the potential for inappropriate access to your site, and a Web server is no exception. This chapter will attempt to acquaint you with some of the most common security issues that confront the Webmaster or Web team and how to design policies and implement procedures to deal with them.

The first thing to consider when choosing server software to run at your site is its origin. Some Web servers are freely available in source form. Having the source code that comprises the server available for inspection may lend to your assurance that it is trustworthy or reliable. At the very least, you're able to inspect the source code and possibly make modifications to it, to make it conform to your own policies. On the other hand, access to the source code also gives the unsavory few the means to study the code for the purpose of cracking your system. Other servers are proprietary, and their source code is not freely available. Precompiled servers that run on platforms other than UNIX are the most common, but there are also precompiled proprietary servers available for various UNIX platforms. Since neither the admin nor anyone else can study their code, they introduce the notion known as "Security by Obscurity," both for their inner workings and for their delivery and encryption mechanisms. The origin of security by obscurity is to be found within the world of cryptography, and it actually refers to certain cryptographic algorithms that rely on the secrecy of certain components to be reliable and safe. Cryptographic techniques used in Web service will be discussed later in this chapter. Within the realm of programs you might decide to run on your computer, however, the notion of security by obscurity is not necessarily a good thing for a number of reasons.

  • Placing your trust in the proprietary inner workings and encryption techniques that are components of these servers may also lead to unforeseen security holes.
  • Many UNIX sysadmins just will not run any program on their machines unless they've compiled its code themselves or, in the hardcore case, unless the program came on the OS distribution tape/CD as an official supported component of the OS.
  • Some servers provide more comprehensive (thus restrictive) mechanisms for enabling security, and others provide only the standard means for implementing a security policy. It's often the case that the freely available servers provide the most comprehensive mechanisms for controlling and/or restricting access. On the other hand, adding complexity to a server's internal mechanisms may also increase the likelihood for security oversights in its design.

Whichever type of server you choose to run and architecture you choose to run it under, you'll need to be conscientious and methodical in all of your activities relating to the management of the server and its archive. Just because a server is purported to be safe and reliable doesn't mean that a trained monkey can manage it. The Webmaster should also make an effort to stay up-to-date and well informed regarding the latest information on security problems related to the server, the archive, and the OS the server runs under. The day-to-day activities and procedures that comprise a sound security policy are highly dynamic in nature, due to the constant struggle between those who would crack your system and those who discover these holes and dispense the information necessary to close them up.

Note:

One important thing you can do to prevent unwanted access and/or retrievals of your archive's contents is to plan your archive's layout well. Chapter 14, "Archive and Document Management," discusses this further. Good archive planning and an established policy for the various aspects of server management and archive updating lend to your ability to configure the server's security mechanisms on a discrete but not overly restrictive basis. After all, too much rigor may tend to chase away well-intentioned but perhaps slightly inexperienced browsers and/or customers.


General Server Security

The security mechanisms the server itself provides vary from server to server and from architecture to architecture. Whatever server you choose to run, you should understand security and spend the time to implement them. Especially if you're running under a multi-user architecture like UNIX, you can easily overlook an item that may cause a potential hole.

Note:

It's the general consensus that of all the platforms on which you can run a WWW server, the one that is least likely to cause you security problems is the Macintosh. The fact that the Macintosh doesn't provide the capability to log in from anywhere but the console reduces the risks involved with providing external access to its filesystem. This also makes it a bit more difficult to manage the archive's contents as a team, of course, but this issue can be worked around through the Macintosh's file-sharing mechanisms. You may wish to investigate this alternative to a UNIX server.