what's the risk of register_globals?

[news]

You'd think it'd be easier to find the answer to this question.
Did a search, and all I can find is people asking why something's not
working and people replying it's because register_globals is off.

I found one person said: "The change is for the better since
register_global turned to on had some grim security implications." but
no mentioning of what those are!

I'm working on a server now, with a couple hundred PHP pages someone
has written. register_globals is on. And I need to see if the risks of
having them on outweigh the extreme annoyance at best and possible
broken processes leading to lost sales at worst if I turn then off.
At the very least I'll need to go through and add $_GET and $_POST to
all the hundreds of places where the previous coder called form results
without using those.
Perhaps there are other things, like the way GD and PDFLib and whatnot
are being utilized, that would be affected.

Anyway, could someone point me to somewhere that explains the risks?
php.net I couldn't even find anything.

Thanks!
Liam

[Justin Koivisto]

ne**@celticbear.com wrote:

You'd think it'd be easier to find the answer to this question.
Did a search, and all I can find is people asking why something's not
working and people replying it's because register_globals is off.

I found one person said: "The change is for the better since
register_global turned to on had some grim security implications." but
no mentioning of what those are!

I'm working on a server now, with a couple hundred PHP pages someone
has written. register_globals is on. And I need to see if the risks of
having them on outweigh the extreme annoyance at best and possible
broken processes leading to lost sales at worst if I turn then off.
At the very least I'll need to go through and add $_GET and $_POST to
all the hundreds of places where the previous coder called form results
without using those.
Perhaps there are other things, like the way GD and PDFLib and whatnot
are being utilized, that would be affected.

Anyway, could someone point me to somewhere that explains the risks?
php.net I couldn't even find anything.

FWIK, it's all about the new super global arrays and knowing where data
is coming from. The security risks are only really risks due to scripts
that trust user input in any way. For instance, if you trust that a user
did supply a real user name, that's a risk (whether register_globals in
on or off).

If you expect a POST var called "var1" and some calls your script with
?var1=newval, $var1 == 'newval' at the top of the script with rg=on. Say
you display specific output based on if the user is an admin by checking
the value of the variable $admin. In your script, if you set it to 1 if
they are an admin, but don't set anything if they are not, calling a
script with ?admin=1 will gain access to those areas as well. That's a risk.

Even using a variable like $_POST['var'] is bad if you don't check for
data integrity. This is where sql injection comes into play. For
instance, you don't want to have:

$query="SELECT * FROM tbl1 WHERE id = {$_POST['var']}";

At least not without first checking that $_POST['var'] is exactly what
you expect (be it an integer or whatever). If someone sent the value of:

1; DELETE FROM tbl1;

You'd be victim to an sql injection attack (and probably loose a bit of
data in the process).

As long as you remember to NEVER TRUST USER INPUT you should be good.
However, I've found a few times that trying to "fix" a script someone
else has written isn't worth the effort. I usually just rewrite the
entire thing.

--
Justin Koivisto - ju****@koivi.com
http://koivi.com

[Ken Robinson]

[e-mail] wrote:

You'd think it'd be easier to find the answer to this question.
Did a search, and all I can find is people asking why something's not
working and people replying it's because register_globals is off.

I found one person said: "The change is for the better since
register_global turned to on had some grim security implications." but no mentioning of what those are!

I'm working on a server now, with a couple hundred PHP pages someone
has written. register_globals is on. And I need to see if the risks of having them on outweigh the extreme annoyance at best and possible
broken processes leading to lost sales at worst if I turn then off.
At the very least I'll need to go through and add $_GET and $_POST to
all the hundreds of places where the previous coder called form results without using those.
Perhaps there are other things, like the way GD and PDFLib and whatnot are being utilized, that would be affected.

Anyway, could someone point me to somewhere that explains the risks?
php.net I couldn't even find anything.

You didn't look very hard ... http://us4.php.net/registerglobals

Basically, with register_globals "on", it is easier for malicious types
to spoof your data. Turning register_globals "off" doesn't
automatically make your code more secure, but it does help. No matter
how the variables get set, some sanity checking should be done before
using the values.

As a first pass to fix the code, you can put the following code at the
top of each script:
if (!empty($_POST)) extract($_POST);
if (!empty($_GET)) extract($_GET);

Ken

which will do exactly what having register_globals "on" did

[Gordon Burditt]

>You'd think it'd be easier to find the answer to this question.

Did a search, and all I can find is people asking why something's not
working and people replying it's because register_globals is off.

I found one person said: "The change is for the better since
register_global turned to on had some grim security implications." but
no mentioning of what those are!
With register_globals turned on, I (a malicious user of your web
site) can initialize any variable I feel like to any value I feel
like. If you code carelessly, like setting $logged_in to 1 if a
user is logged in and leaving it uninitialized if it's not, I can
set $logged_in to 1 and bypass the login process. Or maybe I
could get administrator or edit privileges that way.
I'm working on a server now, with a couple hundred PHP pages someone
has written. register_globals is on. And I need to see if the risks of
having them on outweigh the extreme annoyance at best and possible
broken processes leading to lost sales at worst if I turn then off.
At the very least I'll need to go through and add $_GET and $_POST to
all the hundreds of places where the previous coder called form results
without using those.

If you have a web site that handles actual money (shopping cart
with credit card interface), you should be really worried about
security issues. I have heard of mistakes made where a user could
pass in variables and set the prices to anything he wanted, in
extreme cases getting a refund for buying out the store!

Gordon L. Burditt

[Chung Leong]

I still use register_globals actually. If you use it correctly it
doesn't compromise the security of your site. It's worth remembering in
this discussion that the developers of PHP aren't stupid. They didn't
design a security vulnerability into the software. It's just that some
PHP programmers are stupid and a feature like register_globals
exasperates that fact.

Poor use of include files are probably the leading cause of
register_globals issues. A typical mistake looks something like this:

gateway.php
---------------
<?php

include "config.php"

include "$skin/header.html";

if($login) {
switch($page) {
case 'forum': include('forum.php'); break;
case 'about': include('about.php'); break;
case 'news': include('news.php'); break;
}
}
else {
include('login.php');
}

include "$skin/footer.html";

?>

forum.php
---------------------
<?php

$rows = mysql_do_something();

include "$skin/forum_view.php";

....

?>

There's a number of problems in the script above. The one that's fatal
is in forum.php. It's making use of $skin a variable defined in
config.php. If people use the site as the programmer intended, that is,
access the different pages of the site through gateway.php, $skin would
always be initialized. But if someone figures out that there's a
forum.php, then they can access it directly and define $skin to
whatever they want--if register_globals is on. As the variable is used
in a include statement, that means he could link in a file sitting on
another server and execute arbituary PHP code--i.e. taking over the
server.

While turning off register_globals would save you in this case, the
exact same vuln could arise if you're careless with includes. I have,
for instance, seen this on a live system:

require_once($_GET['do']);

Your time could be better spent reviewing the code for weak points as
opposed to blinding swapping out variables. I would go with Ken's
suggestion of using extract() to stimulate register_globals as a cheap
preventive measure.

[Philip Olson]

When in doubt, read the manual:

http://php.net/register_globals

[micha]

to make an example:

you open www.someone.com/script.php?var=value

with register_globals on your script starts with
$var = 'value' and $_GET['var'] = value

with register_globals off your script starts with only
$_GET['var'] = value

suppose you're using $var in your script. the value 'value' has been
sneaked in.
but: as long as you initialize every var you're planning to use at the
beginning of a script (i.e. emptying it or setting a default value),
register_globals set to 'on' is no problem anymore.

micha

[Micha³ Wo¼niak]

One quick glance of an experienced eye allowed to understand the blurred
and almost unreadable Chung Leong's handwriting:

I still use register_globals actually. If you use it correctly it
doesn't compromise the security of your site. It's worth remembering in
this discussion that the developers of PHP aren't stupid. They didn't
design a security vulnerability into the software. It's just that some
PHP programmers are stupid and a feature like register_globals
exasperates that fact.

Poor use of include files are probably the leading cause of
register_globals issues. A typical mistake looks something like this:

gateway.php
---------------
<?php

include "config.php"

include "$skin/header.html";

if($login) {
switch($page) {
case 'forum': include('forum.php'); break;
case 'about': include('about.php'); break;
case 'news': include('news.php'); break;
}
}
else {
include('login.php');
}

include "$skin/footer.html";

?>

forum.php
---------------------
<?php

$rows = mysql_do_something();

include "$skin/forum_view.php";

...

?>

There's a number of problems in the script above. The one that's fatal
is in forum.php. It's making use of $skin a variable defined in
config.php. If people use the site as the programmer intended, that is,
access the different pages of the site through gateway.php, $skin would
always be initialized. But if someone figures out that there's a
forum.php, then they can access it directly and define $skin to
whatever they want--if register_globals is on. As the variable is used
in a include statement, that means he could link in a file sitting on
another server and execute arbituary PHP code--i.e. taking over the
server.

While turning off register_globals would save you in this case, the
exact same vuln could arise if you're careless with includes. I have,
for instance, seen this on a live system:

require_once($_GET['do']);

Your time could be better spent reviewing the code for weak points as
opposed to blinding swapping out variables. I would go with Ken's
suggestion of using extract() to stimulate register_globals as a cheap
preventive measure.

IMHO, the problem with register_globals is not that someone could
arbitrarily set a variable - but rather that anybody can arbitrarily set
*any* variable. When you use any global vars in your script and
register_globals is on, then you haven't got a chance of proteting
yourself against it. Unless you don't use "$somevar" but always
"$_GET['somevar']" or "$_POST['somevar']" and so on - but why keeping
register_globals on in that case, anyway?

Could you supply a single code snippet from your scripts that uses global
vars, refers to them as $somevar (not $GLOBALS['somevar'] nor similar)
and you are *sure* there is no way of setting those vars arbitrarily
with http://your.address/path/to/file.php?somevar=my_value ?

Cheers
Mike

[Chung Leong]

Duh, just initialize the globals. Here's the snippnet:

$somevar = array();

function access_somevar() {
global $somevar;
}

People usually do that already. The problem is a lot of them use stupid
front controller setups, where you can start a script somewhere in the
middle, bypassing the initialization code.

[Gordon Burditt]

>Could you supply a single code snippet from your scripts that uses global

vars, refers to them as $somevar (not $GLOBALS['somevar'] nor similar)
and you are *sure* there is no way of setting those vars arbitrarily
with http://your.address/path/to/file.php?somevar=my_value ?

If you initialize your variables unconditionally, the value set
by register_globals won't matter:

$is_logged_in = 0; /* this is NOT optional! */

if (isset($_GET['user']) && isset($_GET['password']) &&
validate_login($_GET['user'], $_GET['password']) ) {
$is_logged_in = 1;
}

However, checking that you've always done that is not necessarily
easy.

Gordon L. Burditt

[Micha³ Wo¼niak]

One quick glance of an experienced eye allowed to understand the blurred
and almost unreadable Gordon Burditt's handwriting:

Could you supply a single code snippet from your scripts that uses
global vars, refers to them as $somevar (not $GLOBALS['somevar'] nor
similar) and you are *sure* there is no way of setting those vars
arbitrarily with http://your.address/path/to/file.php?somevar=my_value
?
If you initialize your variables unconditionally, the value set
by register_globals won't matter:

$is_logged_in = 0; /* this is NOT optional! */

if (isset($_GET['user']) && isset($_GET['password']) &&
validate_login($_GET['user'], $_GET['password']) ) {
$is_logged_in = 1;
}

Well, yeah. But what's the use of register_globals then? :)
However, checking that you've always done that is not necessarily
easy.

Precisely.

I just cannot see any reason for this to be on. Using $_GET[], $_POST[]
and $GLOBALS[] isn't very troublesome, while making your code a *lot*
clearer (you don't have the problem of "was it global, get or post?.."),
and saves your time on such tests an initializations of variables. AND,
most of the time when you just miss or overlook something, it will not
become a security hole. So - what's the point?..

Cheers
Mike

[Justin Koivisto]

Michał Woźniak wrote:

Well, yeah. But what's the use of register_globals then? :)
So that other programmers on the same shared server can be lazy and
insecure? ;)
I just cannot see any reason for this to be on. Using $_GET[], $_POST[]
and $GLOBALS[] isn't very troublesome, while making your code a *lot*
clearer (you don't have the problem of "was it global, get or post?.."),
and saves your time on such tests an initializations of variables. AND,
most of the time when you just miss or overlook something, it will not
become a security hole. So - what's the point?..

I don't like using rg either, but the main problem is that some of the
servers that I use (for clients' web sites) has it set on because too
many people complained at upgrade time when their blog, forum or
shopping cart scripts stopped working over night. :\

--
Justin Koivisto - ju****@koivi.com
http://koivi.com

[Nicholas Sherlock]

Justin Koivisto wrote:

I don't like using rg either, but the main problem is that some of the
servers that I use (for clients' web sites) has it set on because too
many people complained at upgrade time when their blog, forum or
shopping cart scripts stopped working over night. :\

From the PHP site:

"If you're under an Apache environment that has this option enabled, but
you're on shared hosting so have no access to php.ini, you can unset
this value for your own site by placing the following in an .htaccess
file in the root:

php_flag register_globals 0"

Cheers,
Nicholas Sherlock

[Justin Koivisto]

Nicholas Sherlock wrote:

Justin Koivisto wrote:

I don't like using rg either, but the main problem is that some of the
servers that I use (for clients' web sites) has it set on because too
many people complained at upgrade time when their blog, forum or
shopping cart scripts stopped working over night. :\

From the PHP site:

"If you're under an Apache environment that has this option enabled, but
you're on shared hosting so have no access to php.ini, you can unset
this value for your own site by placing the following in an .htaccess
file in the root:

php_flag register_globals 0"

Thanks, but I'm well aware of that - I've been using it for about 3
years now. ;)

--
Justin Koivisto - ju****@koivi.com
http://koivi.com

[Chung Leong]

Like I said, the feature isn't inherently bad. You just need to use it
correctly. Most of my processing code is inside functions, so I don't
find it confusing at all. The code operates on variables in the current
context, which for a function consists of arguments from the caller and
locally defined variables. For the script it's information from the
outside world. Perfectly straight forward.

Scoping is the correct way to protect variables. Using a variable with
a special name is just a hack.

[Philip Olson]

One reason to not use register_globals is that this feature is
deprecated. In otherwords, one day register_globals will not exist in
PHP. Sure that day won't be anytime soon, but...