|
For those who aren't familiar with register_globals,
it allows user input to be inserted directly into a
variable of the same name. For instance, a page
requested with the query string of page.php?id=test
would have a variable named $id with the value of 'test'.
If you haven't started already, you'll want to use the
"super global" variables - in other words: $_GET['foo']
for get variables, and $_POST['bar'] for post. You can
read more about these here:
http://www.php.net/variables.predefined
Working this way will prevent an attacker from
injecting a value into other variables that you're
using in your code. In an incredibly simple example:
<?php
if ( isset( $favorite_color ) { $chosen = 1; }
if ( $chosen == 1 ) { Do_Other_Stuff( ); }
?>
In this case, if $favorite_color was not sent, someone
could still send a value for $chosen, and the attacker
would be able to get around supplying a favorite color.
On the other hand, if register_globals were turned off,
and the attacker posted a variable called 'chosen',
then it would be referred to as: $_POST['chosen']
instead of $chosen, which is clearly a different
variable.
In this scenario, only the variables you're expecting
to pull from the super-globals can be over-written, and
if these are doing sensitive tasks, such as dealing
with authentication, executing a shell program,
interacting with a database, etc., then you should be
validating those variables anyways. This and other vulnerabilities are
discussed in many places including this essay:
PHP
and the OWASP Top Ten Security Vulnerabilities.
This has been an issue with php development for some
time, and they have provided a clear migration path for
those who relied upon the old style of coding. The
super-global variables were first available in php4.0
beta 4 (released 2/2000), and were upgraded in 4.1
(12/2001), for further information please see
PHP's ChangeLog.
|
