Global Variables - Vulnerabilities in PHP
Variables in PHP don’t have to be declared, they’re automatically created the first time they are used. Nor are they specifically typed, they’re typed automatically based on the context in which they are used. This is an extremely convenient way to do things from a programmer’s perspective (and is obviously a useful feature in a rapid application development language)
Obviously the main function of a PHP based web application is usually to take in some client input (form variables, uploaded files, cookies etc), process the input and return output based on that input. In order to make it as simple as possible for the PHP script to access this input, it’s actually provided in the form of PHP global variables. Take the following example
HTML snippet:
<FORM METHOD=”GET” ACTION=”test.php”>
<INPUT TYPE=”TEXT” NAME=”hello”>
<INPUT TYPE=”SUBMIT”>
</FORM>
Obviously this will display a text box and a submit button. When the user presses the submit button the PHP script test.php will be run to process the input. When it runs the variable $hello will contain the text the user entered into the text box. It’s important to note the implications of this,
this means that a remote attacker can create any variable they wish and have it declared in the global namespace. If instead of using the form above to call test.php, an attacker calls it directly with a url like “http://server/test.php?hello=hi&setup=no”, not only will $hello = “hi” when the script is run but $setup will be “no” also.
An example of how this can be a real problem might be a script that was designed to authenticate a user before displaying some important information. For example:
<?php
if ($pass == “hello”)
$auth = 1;
…
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.
To summarize the above, a PHP script _cannot trust ANY variable it has not EXPLICITLY set_. When you’ve got a rather large number of variables, this can be a much harder task than it may sound.
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’s 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 and to a limited degree the 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_FILES array shouldn’t be an issue except in exceptional circumstances).
“No man burdens his mind with small matters unless he has some very good reason for doing so.” - John Watson
