Security with PHP Superglobals

A few years ago, my wife and I decided to go on a skiing trip up north. To reserve skiing equipment, you had to give 24-hour advance notice using the ski lodge's on-line web site. The catch was my wife had asked me to make the reservations 23 hours before the deadline.

So I got to thinking and examined the on-line web site, which would not let you make any reservations within the 24-hour timeframe. However, once you selected an appropriate date, I noticed the URL was:

https://www.somewhere.com/reservations.php?date=01-23-01

It occurred to me that although they had locked down security on what dates I could choose from, the final value was placed in a GET statement at the end of the web address. I modified the web address to use “date=01-22-01” and indeed, our skies were waiting for us first thing the next morning (we paid for them, of course).

This innocent yet practical example is only one of the dangers we must be aware of when using any programming language that can be used in ways we did not intend, which leads us to our discussion of PHP Superglobals.

To understand Superglobals, it is critical that you understand how data is passed from one web page to another (e.g., forms). Specifically, you must be aware of two methods known as GET and POST. You also should be familiar with the HTML <FORM> statement (a good reference is www.w3.org/TR/html401/interact/forms.html).

You've probably seen something like this before:

<form name="form1" method="post" action="process.php">
   <p>Please enter your name:</p>
   <p><input type="text" name="yourname" /></p>
   <p><input type="button" name="Submit" value="Submit" /></p>
</form>

This is standard, nothing-fancy HTML form code that asks for some information and then submits the data to the file process.php. The critical bit here is the method declaration, which tells the form how to submit the data; for this, we need to digress for a moment or two (hold your breath):

For those who recall the early days of HTML, forms were provided by means of the <ISINDEX> HTML tag. By inserting this tag into the HEAD of your HTML documents, a text field appeared where you could supply out input. As the new HTML+ standard evolved, a <FORM> tag was designed and could be used with a METHOD attribute of GET, POST or PUT. So, this leaves us with a few different ways to send our data.

With GET, variables and their values are sent in the header of the URL request appended as part of the URL itself. The limitation is that web addresses (URLs) are limited to 8,192 characters; if the amount of data is too long, it will be truncated. Also, even with an SSL connection, the data is not encrypted because it is part of the web address.

For example, a web page might have a form statement like this:

<form name="form1" method="get" action="process.php">
   <p>Please enter your name, e-mail address, and a comment:</p>
   <p><input type="text" name="yourname" /></p>
   <p><input type="text" name="email" /></p>
   <p><input type="text" name="comment" /></p>
   <p><input type="button" name="Submit" value="Submit" /></p>
</form>

When you clicked Submit, your web browser would take the values you filled out in the form and redirect you to this web address:

http://www.fluffygerbil.com/process.php?yourname=fred+smith&email=fred@nowhere.com&comment=I+have+no+comment

Notice how the values of the form are part of the web address itself? That's the essence of GET.

For the curious, what is actually sent in the raw HTTP transmission to accomplish this transaction is:

GET /process.php?yourname=fred+smith&email=fred@nowhere.com&comment=I+have+no+comment HTTP/1.0
Accept: image/gif, image/x-xbitmap, image/jpeg, */*
Accept-Language: en-us
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Q312461)
Host: www.fluffygerbils.com
Connection: keep-alive

With POST, the variables and their values are sent in the body of the URL request, not the header. The advantages of this type of data transmission is there is no limit to the size of the data being sent; it is contained in the body of the HTTP request, not the header. Also, if you're using an SSL connection, the data will be encrypted too—what a deal. For example, consider a web page with a form statement like this:

<form name="form1" method="post" action="process.php">
   <p>Please enter your name, e-mail address, and a comment:</p>
   <p><input type="text" name="yourname" /></p>
   <p><input type="text" name="email" /></p>
   <p><input type="text" name="comment" /></p>
   <p><input type="button" name="Submit" value="Submit" /></p>
</form>

When you clicked Submit, your web browser would take the values you filled out in the form and redirect you to this web address: http://www.fluffygerbil.com/process.php

Notice how the values of the form are not part of the web address itself? That's the essence of PUT.

For the curious, what is actually sent in the raw HTTP transmission to accomplish this transaction is:

POST /process.php
HTTP/1.0Accept: image/gif, image/x-xbitmap, image/jpeg, */*
Accept-Language: en-us
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Q312461)
Host: www.fluffygerbils.com
Content-Length: 94
Pragma: no-cache
Connection: keep-alive

yourname=fred+smith
email=fred@nowhere.com
comment=I+have+no+comment

So, why is all this background information useful? When you install PHP 4.2.2 or later, you might happen to notice that when compiling PHP, it states:

+--------------------------------------------------------------------+
|                         *** NOTE ***                               |
|            The default for register_globals is now OFF!            |
|                                                                    |
| If your application relies on register_globals being ON, you       |
| should explicitly set it to on in your php.ini file.               |
| Note that you are strongly encouraged to read                      |
| http://www.php.net/manual/en/security.registerglobals.php          |
| about the implications of having register_globals set to on, and   |
| avoid using it if possible.                                        |
+--------------------------------------------------------------------+

This means PHP will be ultra-paranoid about the data passed to it and will require you to state from which method the data should be coming. Also, you should be aware that more ways are available to send data to your PHP pages than GET and POST:

Superglobals

This brings us to Superglobals a relatively new concept to PHP. For example, the above diagram presents a slight problem: if you're working with the variable $yourname, how do you know that during your script it hasn't been redefined by one of these six other methods of variable assignment by someone attempting to hack into your script? For example, imagine having someone who has managed to upload a PHP script to your web server that performs the following (php exploit by Daniel Phoenix):

<?phpsetcookie("test","../../../../../../etc/passwd");echo "cookie inserted";?>

Wouldn't it be great to have a way to isolate variables based on how the data gets assigned in the first place? Superglobals allow you to specify which variables received by a specific method should be used.

Superglobals are PHP's attempt at helping you determine where a particular value comes from. If you haven't heard of this new feature as of PHP 4.1.0, you'll want to start adapting to it. Most PHP training books don't touch this subject, so you will need to be aware of how to transition to this new input method. Ultimately, you should re-visit your /usr/local/lib/php.ini file and make the following change:

register_globals = Off

This will prevent the ability for any user-submitted variable to be injected into your PHP code and can reduce the amount of variable poisoning a potential attacker may inflict. They will have to take the additional time to forge submissions, and your internal variables are effectively isolated from user submitted data. If a user then tried to fill out a form, the server wouldn't assign any data to the global variables $name, $email or $comment. Instead, it would divide up the data into the following hashed arrays:

$_POST['name']$_POST['email']$_POST['comment']

The main Superglobal arrays are:

The other, less-common Superglobal arrays are:

For more details, see www.php.net/manual/en/reserved.variables.php.

So instead of $name being set to “John”, you would either have $_GET['name'] = "John" or possibly $_POST['name'] = "John" depending on how the form data was submitted. The advantage is that you will know:

Programming with PHP can be a frustrating experience as of late. Security measures prevent data from being easily assigned to variables, ISPs typically implement PHP without consideration for their audience, and newcomers to PHP tend to be taken aback by such terms as GET, POST, Superglobals and so forth. However, a little knowledge can go a long way, and hopefully this article has helped you in your quest.

This document was lovingly handcrafted on a Dell Latitude C400 laptop running Slackware Linux 8.1. This document was prepared based on PHP 4.3.0.

David Lechnyr is a network manager for the Human Resources department of the University of Oregon. He holds a Master's Degree in social work, along with his MCSE+I, CNE and CCNA certifications. He has been working with Linux for the past six years, with an emphasis on systems security, network troubleshooting and PHP/MySQL integration.