Page 354 - Open Soource Technologies 304.indd
P. 354
Web Technologies-I
Notes if ($auth == 1)
echo “some important information”;
In normal operation the above code will check the password to decide if the remote user has
successfully authenticated then later check if they are authenticated and show them the important
information. The problem is that the code incorrectly assumes that the variable $auth will be
empty unless it sets it. Remembering that an attacker can create variables in the global namespace,
a url like ‘http://server/test.php?auth=1’ will fail the password check but the script will still
believe the attacker has successfully authenticated.
Once common approach to protecting a script is to check that the variable is not in the array
HTTP_GET/POST_VARS[] (depending on the method normally used to submit the form,
GET or POST). When PHP is configured with track_vars enabled (as it is by default) variables
submitted by the user are available both from the global variables and also as elements in the
arrays mentioned above. However, it is important to note that there are four different arrays
for remote user input
• HTTP_GET_VARS for variables submitted in the URL of the get request
• HTTP_POST_VARS for variables submitted in the post section of a HTTP request
• HTTP_COOKIE_VARS for variables submitted as part of the cookie headers in the HTTP
request
• HTTP_POST_FILES array (in more recent versions of PHP).
It is completely the end users choice which method they use to submit variables, one request can
easily place variables in all four different arrays, a secure script needs to check all four (though
again, the HTTP_POST_FILESarray should not be an issue except in exceptional circumstances).
One of the most fundamental things to consider when creating a secure system is that any
information you did not generate within the system should be regarded as tainted. You should
either untaint this data before using it—that is, ensure that there’s nothing malicious in it
or limit what you do with it.
In PHP, however, it is not always easy to tell whether a variable is tainted. When register_globals
is enabled in the php.ini file, PHP automatically creates variables from form parameters and
cookies. Poorly written programs assume that their variables have values only when the variables
are explicitly assigned values in the program code. With register_globals, this assumption is false.
Consider the following code:
<?php if (check_privileges( )) { $superuser = true; } // ... ?>
This code assumes that $superuser can be set to true only if check_privileges( ) returns true.
However, with register_globals enabled, it is actually a simple matter to call the page as page.
php?superuser=1 to get superuser privileges.
There are three ways to solve this problem: initialize your variables, disable register_globals
in the php.ini file, or customize the variables_order setting to prevent GET, POST, and cookie
values from creating global variables.
A PHP script cannot trust any variable it has not explicitly set. When you
have got a rather large number of variables, this can be a much harder task
than it may sound.
348 LOVELY PROFESSIONAL UNIVERSITY