Register globals - Revision history

Dirk: Added category; cosmetics

2008-03-07T13:11:50Z

Added category; cosmetics

THEMike at 08:40, 11 March 2006

2006-03-11T08:40:23Z

THEMike at 08:39, 11 March 2006

2006-03-11T08:39:22Z

Dirk: register_globals will be gone from PHP 6

2006-03-10T09:54:50Z

register_globals will be gone from PHP 6

Dirk: About register_globals and how to deal with it

2006-03-10T09:22:32Z

About register_globals and how to deal with it

New page

Starting with version 1.4.0, Geeklog no longer requires to have PHP's register_globals option set to "on".

Despite the common conception that register_globals is "evil", it is not a security issue ''per se'', as long as you follow a few simple rules (see below). In all the years that Geeklog required register_globals to be "on", there was only '''one''' security issue that was a result of that setting.

== Initialising variables ==

The main rule to avoid problems with the register_globals setting is pretty simple:

:''Initialise your variables!''

The [http://www.php.net/release_4_1_0.php PHP 4.1.0 release notes] had the following example to illustrate what's bad about register_globals=on:

<pre><?php
if (authenticate_user()) {
$authenticated = true;
}
...
?></pre>

With register_globals=on, it's simple to override the authentication check by adding "authenticated=true" to the URL of this script, e.g.

:http://www.example.com/authenticate.php?authenticated=true

However, that problem is easily fixed:

<pre><?php
$authenticated = false;
if (authenticate_user()) {
$authenticated = true;
}
...
?></pre>

There. You can pass whatever you want in the URL now - initialising the $authenticated variable fixed the problem.

This is actually a better programming style anyway, not only from a security point of view. You should adapt this style in your own interest.

=== Switch on error reporting ===

On your ''development system'' ('''never''' do that on a production site), it's recommended that you switch on error reporting to be made aware of issues with uninitialised variables.

In your php.ini file, set

<pre>error_reporting = E_ALL
display_errors = On
display_startup_errors = On</pre>

... and don't forget to restart your webserver after you've made those changes.

Then, in Geeklog's lib-common.php, find the line

<pre>error_reporting( E_ERROR | E_WARNING | E_PARSE | E_COMPILE_ERROR );</pre>

and comment it out or remove it.

'''Note:''' Removing the error_reporting line from lib-common.php will throw up quite a few notices about uninitialised variables in the language files. Those are historic issues that can't be fixed easily but are not a security hazard. Just make sure not to repeat these design issues in your own code ...

The notices caused by the language files will prevent you from logging in to your site, so you may want to comment out the error_reporting line only during the debugging phase of your development cycle.

== Use $_GET, $_POST, and $_REQUEST ==

The above explained how to avoid security issues when register_globals is set to "on". Of course, initialising your variables won't make your code work with register_globals=off.

Values passed from user interaction, i.e. when the user clicks on a URL or submits a form, are always passed in the global $_GET and $_POST arrays. The variables you're looking for exist as named array elements in those arrays, e.g.

* $_GET['page'] from a URL like /index.php?page=2
* $_POST['title'] from a form that contains a comment with a "title" field

Note that a form usually has a method="POST" attribute which means that the form is sent as a HTTP POST request. Consequentially, the $_GET array will be empty in such a case and all the form's values will only exist in the $_POST array.

The $_REQUEST array contains both the contents of the $_GET and the $_POST array. This comes in handy sometimes when a certain portion of your code will have to handle something that could come in via either a GET or a POST request.

However, the $_REQUEST should be used sparingly and with caution, as it may make it easier for an attacker to submit manipulated requests. For example, when your form handling code only looks at the $_REQUEST array, it's also possible to submit all the form's parameter through one GET request which, in some situations, is easier to send than a POST request.

The security implications of the $_REQUEST array are only mild, though. It's recommended, however, that you write your code such that you always know whether the incoming data is in the $_GET or $_POST array, which automatically helps to improve the clarity of your code.

=== Switching off register_globals ===

On your development system, you should switch off register_globals in your php.ini file:

<pre>register_globals = Off</pre>

== register_long_arrays ==

A somewhat related setting has been introduced with PHP 5: register_long_arrays, when set to "on", re-introduces the long names of the $_GET and $_POST arrays, i.e. $HTTP_GET_VARS and $HTTP_POST_VARS. These long-named arrays are disabled by default as of PHP 5 and any code relying on them will therefore fail.

The replacement for those, as mentioned above, are the $_GET and $_POST arrays and only those should be used. They were introduced in PHP 4.1.0, which has also been the minimum requirement for Geeklog for a while now.

@@ Line 84: / Line 84: @@
 With the above code, a url such as:
-somepage.php?sids[]=1&sids[]=2
+<pre>somepage.php?sids[]=1&sids[]=2</pre>
+will inject additional values into the arrays.
@@ Line 120: / Line 119: @@
 The replacement for those, as mentioned above, are the $_GET and $_POST arrays and only those should be used. They were introduced in PHP 4.1.0, which has also been the minimum requirement for Geeklog for a while now.

← Older revision		Revision as of 08:40, 11 March 2006
Line 38:		Line 38:

	This is actually a better programming style anyway, not only from a security point of view. You should adapt this style in your own interest.		This is actually a better programming style anyway, not only from a security point of view. You should adapt this style in your own interest.
		+
		+	=== Switch on error reporting ===
		+
		+	On your ''development system'' ('''never''' do that on a production site), it's recommended that you switch on error reporting to be made aware of issues with uninitialised variables.
		+
		+	In your php.ini file, set
		+
		+	<pre>error_reporting = E_ALL
		+	display_errors = On
		+	display_startup_errors = On</pre>
		+
		+	... and don't forget to restart your webserver after you've made those changes.
		+
		+	Then, in Geeklog's lib-common.php, find the line
		+
		+	<pre>error_reporting( E_ERROR \| E_WARNING \| E_PARSE \| E_COMPILE_ERROR );</pre>
		+
		+	and comment it out or remove it.
		+
		+	'''Note:''' Removing the error_reporting line from lib-common.php will throw up quite a few notices about uninitialised variables in the language files. Those are historic issues that can't be fixed easily but are not a security hazard. Just make sure not to repeat these design issues in your own code ...
		+
		+	The notices caused by the language files will prevent you from logging in to your site, so you may want to comment out the error_reporting line only during the debugging phase of your development cycle.


Line 66:		Line 88:
	Will inject additional values into the arrays.		Will inject additional values into the arrays.

−
−	~~=== Switch on error reporting ===~~
−
−	~~On your ''development system'' ('''never''' do that on a production site), it's recommended that you switch on error reporting to be made aware of issues with uninitialised variables.~~
−
−	~~In your php.ini file, set~~
−
−	~~<pre>error_reporting = E_ALL~~
−	~~display_errors = On~~
−	~~display_startup_errors = On</pre>~~
−
−	~~... and don't forget to restart your webserver after you've made those changes.~~
−
−	~~Then, in Geeklog's lib-common.php, find the line~~
−
−	~~<pre>error_reporting( E_ERROR \| E_WARNING \| E_PARSE \| E_COMPILE_ERROR );</pre>~~
−
−	~~and comment it out or remove it.~~
−
−	'''Note:''' Removing the error_reporting line from lib-common.php will throw up quite a few notices about uninitialised variables in the language files. Those are historic issues that can't be fixed easily but are not a security hazard. Just make sure not to repeat these design issues in your own code ...
−
−	The notices caused by the language files will prevent you from logging in to your site, so you may want to comment out the error_reporting line only during the debugging phase of your development cycle.

← Older revision		Revision as of 08:39, 11 March 2006
Line 38:		Line 38:

	This is actually a better programming style anyway, not only from a security point of view. You should adapt this style in your own interest.		This is actually a better programming style anyway, not only from a security point of view. You should adapt this style in your own interest.
		+
		+
		+	== Use typesafe comparison operations ==
		+	The content of the superglobal arrays ($_GET, $_POST, $_REQUEST etc) are all strings, as are any variables created by register_globals. As this is the case, you can secure your code further by using typesafe comparisons:
		+
		+	<pre>
		+	if ($authorized === TRUE)
		+	{
		+	// Only matches if $authorized contains an actual boolean true value.
		+	}
		+	</pre>
		+
		+	== Hidden problems with register_globals ==
		+	Register globals allows you to inject values into arrays in a non-detectable fashion:
		+
		+	<pre>
		+	$sids[] = "123";
		+	foreach ($sids as $sid)
		+	{
		+	// Delete article by sid
		+	}
		+	</pre>
		+
		+	With the above code, a url such as:
		+	somepage.php?sids[]=1&sids[]=2
		+
		+	Will inject additional values into the arrays.

← Older revision		Revision as of 09:54, 10 March 2006
Line 2:		Line 2:

	Despite the common conception that register_globals is "evil", it is not a security issue ''per se'', as long as you follow a few simple rules (see below). In all the years that Geeklog required register_globals to be "on", there was only '''one''' security issue that was a result of that setting.		Despite the common conception that register_globals is "evil", it is not a security issue ''per se'', as long as you follow a few simple rules (see below). In all the years that Geeklog required register_globals to be "on", there was only '''one''' security issue that was a result of that setting.
		+
		+	On a side note, the register_globals setting will be removed from PHP 6, i.e. it will always be "off" and there will be no way to switch it back "on". So now would be a good time to review your code for dependency on the register_globals setting ...