Having it enabled is neither secure nor insecure. When register_globals is enabled, it simply makes it
easier to write insecure code.
Consider a script like the following, it is a php page where the user passes his/her name in to the script via a $name variable and the script prints a welcome:
PHP Code:
<?php
// See if it's morning or afternoon
if (date('G') < 12) {
// Ok it's morning
$is_morning = true;
}
// Print the welcome
if ($is_morning) {
echo '<h2>Good morning '.$name.'</h2>';
} else {
echo '<h2>Good afternoon/evening '.$name.'</h2>';
}
?>
The above code is vulnerable to attack when register_globals is on because the variable $is_morning is not initialized before use.
If you type in the URL 'script.php?name=Jackie' you will get Good morning Jackie or Good afternoon/evening Jackie depending on the time of day. With register_globals enabled, you can manipulate the script and make it print 'Good morning' even in the afternoon by typing in 'script.php?name=Jackie&is_morning=1'.
If register_globals is off, you have to access all variables that come in as parameters in the URL thru the $GLOBALS array or the $_GET (or $_POST etc) arrays: ie: $_GET['name'] instead of $name. Since the script uses the $is_morning variable, you can't manipulate the value of that variable via the URL when register_globals is enabled.
So, it's easier to write insecure code when register_globals is on.
To take advantage of these vulnerabilities, you have to either guess or know the variables being used in the script you want to hack, but with all the open source scripts out there, it's not that hard to know what variables they're using.
The above script can be perfectly safe even with register_globals on, if you initialize the value of $is_morning at the beginning of the script. Of course you'd need to validate the contents of the $name variable before using it as well, but that doesn't have anything to do with register_globals.