Lessons in Web Security: PHP and register_globals

After taking a gander at some of the threads at Sitepoint Forums, I decided to take a look at a topic that is as deep as it is wide. Over the next few days and weeks, we’ll look at some of the problems in the way of web security and what you can do to ensure your website does not get defaced, brought down or otherwise exploited. It will probably not be an exhaustive list but it should be enough. In some cases, I may be accused of being vague, so let me say for the record that that is my intention. I don’t intend to give away the house or industry secrets, but I do want to make the issue transparent enough that the dangers can be noted and understood.

So starting right off, let’s look at one of the weaknesses of a common scripting language, PHP. This exploit is actually old and has been closed by default in every PHP release for the past few years. This issue is a setting called register_globals.

Register_globals is a setting within the php.ini file that says, ‘okay, we have global variables that we want to make local variables’. What does this mean? Global variables are session and cookie variables as well as any data submitted via a form (POST) or by URL (GET).

When a URL is formed as such:

http://www.example.com/index.php?id=123&category=general

The GET global variables are id and category.

When an HTML form has fields with names such as username and password, the POST variables are username and password:

<form action="processform.php" method="post"> <input type="text" name="username" /> <input type="password" name="password" /> <input type="submit" name="submit" value="Submit"> </form>

In the old days, and still on some servers that have register_globals turned on, the ease of using PHP was partly due to the fact that using these global variables was as simple as calling them by name. If a programmer wanted to display the fields submitted by the URL in the first example, it was as simple as writing:

<?php echo $id; echo $categroty; ?>

This was easy but insecure. With register_globals enabled, PHP will trust any variable that it has been passed via a web form or a URL (or cookie if an attacker has local access to the machine the cookie is set on). By disabling register globals, it forces PHP to look at any information being passed to it and allows the developer to explicitly set data that is expected to be passed and ignore any information that is not intended.

For instance, take this example where an appropriate username/password combo is admin and mypass. The form is submitted to a script that is intended to authorize a user and grant them access, should the authentication be completed.

With Register Globals on:
<?php if($username == 'admin' && $password == 'mypass') { $authorized=1; } if($authorized == 1) { // Display content } ?>
This script essentially looks at the global variables submitted by the form and recognizes that the correct credentials are displayed, sets a variables ($authorized) equal to 1 and continues on. The next check determines if $authorized is equivalent to 1 and if so, authenticates.

Well, what if I am Joe Hacker, and I realize that this webserver has register_globals on (a simple test would determine this)? A variable created in a form with one name would be handled the same way as a variable in a URL with the same name. So If I browsed to http://www.example.com/processform.php?authorized=1, I can gain the same access.

But I never submitted a username and password, correct? This is correct, but the fact that I fail a username and password test doesn’t mean a thing, when the determining factor for whether to display protected content is based on whether a variable, $authorized, equals 1.

Solution: Chances are, if you are running a version of PHP within the past three years, register_globals has been turned off. If however, it is turned on or you are unsure about whther it is of, you can include the following bit at the top of your script:

ini_set("register_globals",0);

In addition, now global variables are referred to using their global array names. Variables passed in a URL are now referred to using $_GET['variable1'], $_GET['variable2'], etc. Variables submitted via forms, or the POST method, are ferred to using $_POST. $_COOKIE and $_SESSION touch on another area of security, but can also be referred to using their global variable array names.

So, next time, we’ll talk about PHP and the remote file execution capability.

• 
• Stumble it!

About the Author: Aaron Brazell is the lead editor of Technosailor.com and a social media expert. His passion is to see companies and individuals use the internet and web technologies wisely and effectively to promote their brands and companies. He served as Director of Technology at b5media from 2005-2008 and is currently an independent consultant.