One feature of PHP that can be used to enhance security is configuring PHP with
register_globals = off.
By turning off the ability for any user-submitted variable to be injected
into PHP code, you can reduce the amount of variable
poisoning a potential attacker may inflict. They will have
to take the additional time to forge submissions, and your
internal variables are effectively isolated from user
submitted data.
While it does slightly increase the amount of effort required
to work with PHP, it has been argued that the benefits far
outweigh the effort.
Example 4-8. Working without register_globals=off <?php
if ($username) { // can be forged by a user in get/post/cookies
$good_login = 1;
}
if ($good_login == 1) { // can be forged by a user in get/post/cookies,
fpassthru ("/highly/sensitive/data/index.html");
}
?> |
|
Example 4-9. Working with register_globals = off <?php
if($HTTP_COOKIE_VARS['username']){
// can only come from a cookie, forged or otherwise
$good_login = 1;
fpassthru ("/highly/sensitive/data/index.html");
}
?> |
|
By using this wisely, it's even possible to take preventative
measures to warn when forging is being attempted. If you know
ahead of time exactly where a variable should be coming from,
you can check to see if submitted data is coming from an
inappropriate kind of submission. While it doesn't guarantee
that data has not been forged, it does require an attacker
to guess the right kind of forging.
Example 4-10. Detecting simple variable poisoning <?php
if ($HTTP_COOKIE_VARS['username'] &&
!$HTTP_POST_VARS['username'] &&
!$HTTP_GET_VARS['username'] ) {
// Perform other checks to validate the user name...
$good_login = 1;
fpassthru ("/highly/sensitive/data/index.html");
} else {
mail("admin@example.com", "Possible breakin attempt", $HTTP_SERVER_VARS['REMOTE_ADDR']);
echo "Security violation, admin has been alerted.";
exit;
}
?> |
|
Of course, simply turning off register_globals does not mean code
is secure. For every piece of data that is submitted, it
should also be checked in other ways.