Security with PHP Superglobals

Wouldn't it be great to have a way to isolate variables based on how the data is assigned in the first place?

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.

Forms

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.

GET

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
POST

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
______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Re: Security with PHP Superglobals

Anonymous's picture

You neglected to continue with your http://www.fluffygerbil.com/process.php example and how to use the superglobals. I'm scratching my head wondering where the rest of the article is!

Re: Security with PHP Superglobals

Anonymous's picture

"therefore you don't have to worry about having a form accepting POST data and having the values change by someone sending a hacked URL with GET data appended to the URL. This will make sense shortly, so hang on... "

Is there an addional explanation that was supposed to be written regarding the last line of this quote? I'm not sure how using $_GET['var'] will prevent users from still putting their own value in a querystring to be processed by the server. I'm sure it's just a simple explanation but it's something I'm curious about.

Re: Security with PHP Superglobals

Anonymous's picture

Wow, are you a clear writer. Thank you so much for the concise help, I'd been trying to figue out why my form changes worked on mozilla but not opera, yes in netscape no in IE.
Cheers from downunder.

Re: Security with PHP Superglobals

Anonymous's picture

thank you

Re: Security with PHP Superglobals

Anonymous's picture

Excellent article. The breakdown of parameters is very useful. Could we see something on proper session management in the future?

Re: _POST

Anonymous's picture

great heads up... i'll will look into this futher...

thankx!

Re: Security with PHP Superglobals

Anonymous's picture

Nice article. With regard to SSL and GET vs. POST. Form data sent with GET will be encrypted on the wire with SSL, even though it will be visible in your browser's Address field. POST is nice because it won't show sensitive or ugly data in the Address field. But as far as on the wire encryption with SSL goes, there is no difference.

hey dumb ass who ever coded t

Anonymous's picture

hey dumb ass who ever coded this page, you let the damn margin go wild.
stupid f***ing idiot!

Yeah what a retard.

Yeah's picture

Yeah what a retard.

ya no kidding..

Anonymous's picture

ya no kidding..

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix