Chapter 10: Security Issues

Password protecting your pages

There are several scenarios to think about. Suppose you need to protect one page for just one user. For example, it might be the admin panel of a script you need to access occasionally. You don't want anyone else to be able to reach this page and change your settings. So you add this PHP block at the top of the page:

<?php
if ($PHP_AUTH_USER != "Boogieman" || $PHP_AUTH_PW != "g_string"
{     header("HTTP/1.0 401 Unauthorized");
    header("WWW-Authenticate: Basic realm=\"Member Access Page\"");
    header("HTTP/1.0 401 Unauthorized");
    echo("Access Denied - invalid username or password");
    die(); }
?>

This will activate HTTP authentication for this page. The script will be sending the username and password via HTTP headers. These have to be sent before any other HTML is sent. So it's crucial that these lines of code be at the very top of the page.

This is much safer than a JavaScript password and much simpler and easier than a full-blown HTML/PHP password-protection script. The main drawback is that it only protects this one page and there can only be one user.

We can expand the idea a bit quite easily, though. What if the protected area is a folder? You can put all the pages you want to protect in that one folder and put the authentication code in the index page for that folder. What? You're not putting an index file (index.html or index.php, for example) in EVERY folder? Hmmm...bad mojo! Why?

A lot of surfers already know that if a folder contains no index file, they can do several things that will really tick you off! One, they can simply type in the path to the folder and get a directory listing of that folder's contents. Two, they can click on any page name in the folder and the page will open. Three, they can right-click and Save-As, which will copy the entire file (including the PHP code you wanted to keep hidden!) to their hard drive.

Did you notice that the username and password (Boogieman, g_string) were part of the code I used? Some great ideas will hit you like a ton of bricks after you read about creating pages from templates and using the include() function.

Change your password fairly often for better security. Use a mix of upper-case letters, lower-case letters and numbers. Don't use anything that could be easily guessed - like your birth date, for example.

Then there's the case of a private membership site or restricted areas of any other kind of site. This method won't work there because you have to accept a lot of different logins. For that, you'll need a PHP script that uses or manipulates the .htaccess file(s) on your server. Here's a link to a script that handles password protection by managing your .htaccess files

http://www.cgiscript.net/cgi-script/csNews/csNews.cgi?database=cgi.db&command=viewone&id=4

This script isn't free, but if you rummage through the sites I mentioned in Chapter 3, you might find a free one that works well. If you need more power, check out Mojo Protector. I've used this one to protect a private membership site that earns over $500,000 per year. Yeah - it's that good.

Why worry about the inputs?

When people are allowed to enter their information in a form, it's possible for them to enter things you don't want. Sometimes it's just a typo; other times it's a deliberate attempt to cause you harm. When this happens, your script may not respond correctly to the input. In severe cases, a system command or a Java applet or script may be unleashed on your server, causing untold damage. But don't panic! It's fairly easy to prevent the vast majority of this activity by taking a few simple precautions.

Caution: Unix commands can be very short. The Unix command rm * will delete all the files in the current directory. Even a little leftover space could be enough room for something destructive. For example, you don't expect a ";" to be part of a name. Reject it and whatever follows it.

Limit the maximum length of an input string to no more than it needs to be. Do this by using the "maxlength=" attribute in a text input. Make the maximum length big enough to handle the input text you expect to get and no larger.

For instance, 60 characters is usually plenty of room for an email address. You don't need more than 10 characters (9 digits plus a -) for a Zip code.

Filter out any characters that should not be in the field. The code for filtering should execute immediately after the value is assigned to the variable. You don't want to allow time for spurious characters to be processed by your other code.

Tip: Be sure to test your form thoroughly after you've put you filters in place. Make sure that any characters that could belong in the field are not rejected. This is a tricky area. You have to strike a balance between rejecting attempts to harm your system and being too restrictive to the inputs. Be especially careful with names and street addresses.

Previous Page Table of Contents Next Page