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