Five Simple Things You Can Do To
Protect Your Web Site

By Gordon McComb

You've spent months perfecting your Web site, fine-tuning each page and making it an enjoyable place for visitors. Then one morning you log on to the Internet, only to find crackers -- high-tech computer vandals -- have broken into your Web page and ruined all your hard work.

Such a scenario is not common, but it's not impossible, either. As the recent hacker break-in of Yahoo! proves, no one is immune to the problems of Web security. You don't even need to have your Web site defaced to suffer damages or loss; rogues of the Internet are known to look for secret "back doors" to Web site content, accessing files they shouldn't, or stealing content by linking to your site.

Here are five simple things you can do to protect your Web site. Of course, the following handful of tips won't guarantee maximum security. But these few steps will help you to many of the more common Web security problems.
 

1. Use an "index page" in every directory of your site.
Index (also called default) pages are HTML documents that are automatically served when someone provides only the directory name for the URL. With most Web servers, entering http://www.mysite.com/mydir/ will display all the files if there is no index page. Sometimes this is desirable, but often it is not, especially for directories that contain support files such as images, Java applets (.class files) and data documents. Without an index page, the entire content of the directory can be readily seen. By providing an index page, the server automatically sends that page when someone requests to see http://www.mysite.com/mydir/. This prevents people from "raiding" your directories, and perhaps getting access to files you didn't intend to make public.

The name of the index page differs depending on the Web server you use. Most Unix-based Web servers (Apache, NCSA) will look for either index.html and/or index.htm as the standard for index pages. Conversely, default.htm is the standard index page name for Web sites that operate under Microsoft FrontPage. Ask your Web server administrator, or consult your Web server software documentation, if you're not sure how to name your index pages.
 

2. Rename highly desirable files on a regular basis.
Renaming your best files helps prevent other sites from using your content -- from your server -- in their pages. When another site uses your content (a URL to something on your site in their pages), you pay for the bandwidth, either in a slower server, an increased monthly fee, or both.

You can help reduce or eliminate this sort of Web site banditry by regularly renaming or moving your most valuable content. For example, suppose your site contains a number of award-winning photographs. Color photos, especially large and sharp ones, tend to be large files, easily passing the 75-100K mark. Another site may find the photos on your site, and include an in-line <IMG> tag for them on their pages. Anyone visiting the other site sees your photos, but not your pages.

If you regularly rename your photos, however, pirate pages with links to them will display the broken image icon, rather than the actual photos themselves. Do this often enough, and most rogue sites will eventually stop abusing your content.

You may not want to rename all the content files in your Web site. Instead, you might consider just changing the name of the directory they are located in. You'll still need to update your pages to reflect the change, but the effort is usually minimal. For example, instead of placing your image files in a directory called /images, change the name to /image. Then in your own pages replace all instances of /images with /image.

Or, if your site is on a Unix-based Web server, you can change the capitalization of the directory containing the valuable files. Unix is case-sensitive, so /Images is treated as uniquely different from /images.
 

3. If you have CGI privileges, have your scripts reviewed for possible security holes.
CGI programs are one of the most common ways outsiders may invade your site. If you are not familiar with CGI programming -- and the varied security issues involves -- find someone who will review your programs and suggest ways to make them more secure. You may be able to find someone who will do this for you for free, but odds are you'll need to locate a consultant and pay an hourly or set fee ($50 to $100 an hour is not uncommon).

Don't be lulled into thinking that all CGI programs available on the Web, either free or for charge, are secure. Many scripts still in common use contain "holes" that a computer cracker can exploit. If you find a CGI program you'd like to use, first make sure you have the latest version. Often, the author of the program will provide an update if the script is found to be faulty. You may wish to have these CGI programs reviewed by a Web programming expert as well.
 

4. Use server-side password protection if you sell on-line content (software, plans, etc.).
A server-side password system is considered extremely difficult to "crack," and is the most secure way to prevent unauthorized access to your restricted Web pages. In order to implement server-side password protection, however, your server must provide it for you, usually as a built-in feature. See http://gmccomb.com/commerce/access.html for additional information on how server-side protection is offered on most Unix systems proper.

If server-side password protection is not available, you may wish to use either blind URLs or some client-side password technique using JavaScript. With a blind URL you provide your visitors with the URL of the protected content; this URL is not published anywhere else on your site. You should change this URL from time to time to guard against unauthorized access. If you follow Step 1, above, and always use an index page for every directory, visitors to your site will not be able to see the files in your directories.

The JavaScript method of access protection -- also described in http://gmccomb.com/commerce/access.html -- offers a means to automatically restrict access based on some arbitrary element, such as the current date. For example, you can use JavaScript to scramble a password with the current month of the year. This produces an encrypted version of the password that is good only for that month. You can use the encrypted version of the password as the name of restricted content you are providing.
 

5. Don't leave FTP log files in your directories.
Several of the latest FTP software use log files to help you maintain your Web site.   These logs files, such as FS_FTP.LOG, record the time and date files are uploaded to your site. When you update your site, the FTP program checks this log file to determine which files (usually from a group or directory of your hard disk drive) have been modified, and therefore need to be re-uploaded. In this way you don't need to individually select the files that need to be refreshed, nor do you need to needlessly upload unmodified copies of files.

As with "open" server directories -- where bandits can see all your files and get to some you may not want them to access -- the FS_FTP.LOG file provides a list of all the files you've uploaded.  A bandit can merely type a URL and add FS_FTP.LOG (or other common log file name), and download your list of files.

There are several ways you can prevent unauthorized viewing of your FTP log files.   One is to rename the log file after uploading.  Pick a name that is not easily guessed.  When you're ready to re-upload files, change the name back so that the FTP program can reference the log file.  Or, you may wish to move your FTP log files to another directory, copying them back before using the FTP program again.

Copyright (c) 1997, Gordon McComb. All Rights Reserved. You are free to copy, distribute, or mirror this document as long as this copyright notice remains intact.
RETURN