Professional LAMP

Professional LAMP: Linux®, Apache, MySQL®, and PHP5 Web Development

7.1

7.1. Controlling Access

7.1.1. Apache-Controlled Authentication

Using a combination of .htaccess and password files, you can quickly restrict access to any given website folder. This approach has many advantages.

Primarily, it is extremely easy to implement. Coming standard with the default installation of Apache, simple per-directory Basic Authentication can easily be set up using either .htaccess or entries.

What is the downside to using the built-in Apache authentication? It can be a hassle to maintain a complex hierarchy of restricted folders and users. If you have a large number of users or groups, and a fair number of protected directories, it can quickly become a nightmare to ensure the proper users are in the proper groups, with access to the proper resources, with current passwords, and so on.

As an alternative to simple file-based authentication with Apache, you can also use the mod_auth_mysql Apache module. Using mod_auth_mysql centralizes your username/password storage, and also gives you the ability to do complex permission-matching abilities—not a simple username-match as with the standard Apache Basic Authentication.

Like simple authentication with Apache, mod_auth_mysql relies on access rights specified in .htaccess files or a entry in httpd.conf. If you do not have access to change the Apache configuration, and .htaccess files aren't permitted by your host, you'll need to find another method. Enter PHP-based authentication.

7.1.2. PHP-Controlled Authentication

If Apache-controlled authentication is out of the question, you can actually use the power of PHP to emulate standard Basic Authentication. By sending the proper response headers, and checking for the right server variables, you can build your own basic authentication system from scratch, and it'll have just as much power as mod_auth_mysql, if not more.

To show how you can use PHP for basic authentication, you're going to set up a simple database to use as your repository for user credentials. PHP will then check the usernames and passwords against that database; all the end-user will see is the standard Basic Authentication prompt.

7.1.2.1. Creating the Authentication Database

Start by creating a database in MySQL called WebAuth:

Next, create a MySQL login for the authentication system, and give it read-only access to the database you just created:

Now, set up the table to hold the usernames and passwords. In this example, the table will store just the username and hashes of the password, but if you wanted, you could easily add extra fields for any other access criteria you want.

Notice that instead of simply creating a field to store the user's password as raw text, you're creating fields to store one-way hashes of the user's password. Doing this ensures the password can still be compared to the value entered at the password prompt, but makes it extremely difficult for those who would try to crack the passwords if the database was compromised.

To combat any sort of collision attacks as seen with MD5, you create the Users table to hold both MD5 and SHA1 hashes for the password. Doing this effectively makes any collision attack attempts futile—even if an intruder manages to find an input string that matches the MD5 hash, unless it's the real password, it will not match the SHA1 hash.

To make the database useful to the authentication script, you need to add at least one user:

7.1.2.4. Other Access Restrictions

In addition to restricting access by username and password, you can also use PHP to check other user parameters. One common variable to check is the source IP of the user. By referencing the server variable $_SERVER['REMOTE_ADDR'], you can make sure that only certain ranges of IPs are allowed to view a resource, or conversely, you can block specific IPs. If you're creating a website for a corporate intranet, you can restrict access to internal IPs (assuming your network uses them). For example, you could decide that only members of the 10.0.1.x network can view a special area of your website. Another example would be BBS sites or web forums.

Another server variable worth checking is the $_SERVER['HTTP_REFERER'] variable. This variable holds the name of the previous page viewed, and can help you eliminate a certain class of web attacks. Suppose you create a simple form that saves data to a database, emails people, or anything that relies on valid user input. You might have even gone to great lengths to perform client-side input validation and specified maximum lengths on your forms. Unfortunately, anything you might expect as input from a web client can easily be corrupted using an external form. Any site attacker can easily copy your form's HTML markup, and then modify it to suit their needs—whether it be for information-gathering, cross-site scripting, SQL injection, or anything really.

All they need to do is make a copy of the form that can submit improper data to your site, host it on their own machine, but have it post to your form, using an absolute URL as the method. This kind of attack can be especially harmful when hidden form variables are used, and when register_globals is enabled in php.ini.

By checking the HTTP_REFERER value, you can eliminate a majority of spoofed form attacks, as long as you ensure the input is coming from a page actually on your website.

This code simply checks the referring page first, to make sure it came from localhost or the expected domain (assuming you've changed it to match your own domain), and then checks the user's IP address to make sure it comes from an internal/private IP range.