what's the risk of register_globals?

[news@celticbear.com]

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_global s 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_global s 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]

Re: what's the risk of register_global s?

news@celticbear .com wrote:
[color=blue]
> 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_global s 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_global s 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.[/color]

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_global s 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 - justin@koivi.co m

http://koivi.com

[Ken Robinson]

Re: what's the risk of register_global s?


n...@celticbear .com wrote:[color=blue]
> 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_global s is off.
>
> I found one person said: "The change is for the better since
> register_global turned to on had some grim security implications."[/color]
but[color=blue]
> no mentioning of what those are!
>
> I'm working on a server now, with a couple hundred PHP pages someone
> has written. register_global s is on. And I need to see if the risks[/color]
of[color=blue]
> 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[/color]
results[color=blue]
> without using those.
> Perhaps there are other things, like the way GD and PDFLib and[/color]
whatnot[color=blue]
> 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.[/color]

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

Basically, with register_global s "on", it is easier for malicious types
to spoof your data. Turning register_global s "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_global s "on" did

[Gordon Burditt]

Re: what's the risk of register_global s?

>You'd think it'd be easier to find the answer to this question.[color=blue]
>Did a search, and all I can find is people asking why something's not
>working and people replying it's because register_global s is off.
>
>I found one person said: "The change is for the better since
>register_globa l turned to on had some grim security implications." but
>no mentioning of what those are![/color]

With register_global s 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.
[color=blue]
>I'm working on a server now, with a couple hundred PHP pages someone
>has written. register_global s 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.[/color]

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]

Re: what's the risk of register_global s?

I still use register_global s 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_global s
exasperates that fact.

Poor use of include files are probably the leading cause of
register_global s 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.p hp'); break;
}
}
else {
include('login. php');
}

include "$skin/footer.html";

?>

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

$rows = mysql_do_someth ing();

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_global s 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_global s 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_global s as a cheap
preventive measure.

[Philip Olson]

Re: what's the risk of register_global s?

When in doubt, read the manual:

http://php.net/register_globals

[micha]

Re: what's the risk of register_global s?

to make an example:

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

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

with register_global s 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_global s set to 'on' is no problem anymore.

micha

[Micha³ Wo¼niak]

Re: what's the risk of register_global s?

One quick glance of an experienced eye allowed to understand the blurred
and almost unreadable Chung Leong's handwriting:
[color=blue]
> I still use register_global s 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_global s
> exasperates that fact.
>
> Poor use of include files are probably the leading cause of
> register_global s 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.p hp'); break;
> }
> }
> else {
> include('login. php');
> }
>
> include "$skin/footer.html";
>
> ?>
>
> forum.php
> ---------------------
> <?php
>
> $rows = mysql_do_someth ing();
>
> 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_global s 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_global s 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_global s as a cheap
> preventive measure.[/color]

IMHO, the problem with register_global s 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_global s 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_global s 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]

Re: what's the risk of register_global s?

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]

Re: what's the risk of register_global s?

>Could you supply a single code snippet from your scripts that uses global[color=blue]
>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 ?[/color]

If you initialize your variables unconditionally , the value set
by register_global s 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]

Re: what's the risk of register_global s?

One quick glance of an experienced eye allowed to understand the blurred
and almost unreadable Gordon Burditt's handwriting:
[color=blue][color=green]
>>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
>>?[/color]
>
> If you initialize your variables unconditionally , the value set
> by register_global s 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;
> }
>[/color]

Well, yeah. But what's the use of register_global s then? :)
[color=blue]
> However, checking that you've always done that is not necessarily
> easy.[/color]

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]

Re: what's the risk of register_global s?

Michał Woźniak wrote:
[color=blue]
> Well, yeah. But what's the use of register_global s then? :)[/color]

So that other programmers on the same shared server can be lazy and
insecure? ;)
[color=blue]
> 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?..[/color]

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 - justin@koivi.co m

http://koivi.com

[Nicholas Sherlock]

Re: what's the risk of register_global s?

Justin Koivisto wrote:[color=blue]
> 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. :\[/color]

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_global s 0"

Cheers,
Nicholas Sherlock

[Justin Koivisto]

Re: what's the risk of register_global s?

Nicholas Sherlock wrote:
[color=blue]
> Justin Koivisto wrote:
>[color=green]
>> 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. :\[/color]
>
>
> 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_global s 0"[/color]

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

--
Justin Koivisto - justin@koivi.co m

http://koivi.com

[Chung Leong]

Re: what's the risk of register_global s?

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.