register_globals in php4

register_globals in php4

am 09.05.2002 19:50:50 von Patrick Hsieh

Hello list,

php4.1 recommends to set register_globals=off in php.ini to make php
more strict. My question is, if I turn off register_globals, what will
happen if any malicious user just try to modify the variable values in
the url? Say,

http://www.domain.com/xxx.php?id=3&sex=female

Does it work if user just change the value in the URL directly and send
the url directly to web server?

How can we avoid the malicious attack by directly http GET/POST with
modified parameter values to make possible system error or compromise?


--
Patrick Hsieh
GPG public key http://pahud.net/pubkeys/pahudatpahud.gpg


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: register_globals in php4

am 09.05.2002 19:52:40 von Miguel Cruz

On Fri, 10 May 2002, Patrick Hsieh wrote:
> php4.1 recommends to set register_globals=off in php.ini to make php
> more strict. My question is, if I turn off register_globals, what will
> happen if any malicious user just try to modify the variable values in
> the url? Say,
>
> http://www.domain.com/xxx.php?id=3&sex=female
>
> Does it work if user just change the value in the URL directly and send
> the url directly to web server?
>
> How can we avoid the malicious attack by directly http GET/POST with
> modified parameter values to make possible system error or compromise?

If register_globals is off, then you'll get $_GET['id'] = 3 and
$_GET['sex'] = female. It's then up to you to make sure those are okay.
But at least $id and $sex won't get set until you explicitly set them in
your code.

miguel


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: register_globals in php4

am 09.05.2002 23:57:00 von John Holmes

----- Original Message -----
From: "Patrick Hsieh"
> Hello list,
>
> php4.1 recommends to set register_globals=off in php.ini to make php
> more strict. My question is, if I turn off register_globals, what will
> happen if any malicious user just try to modify the variable values in
> the url? Say,

The variables will get passed just like normal. You have no way of telling
if the values actually came from a form or if the user manipulated the data.
This goes for GET, POST, and COOKIE data.

> How can we avoid the malicious attack by directly http GET/POST with
> modified parameter values to make possible system error or compromise?

You can't stop it. The user can send anything to your site. It's up to you
to validate the data and make sure it's what it's supposed to be.

At least with register_globals = off, when you use $_GET["var"], you know
it's coming from the URL (or a GET form). Same thing with _POST, _SESSION,
and _COOKIE, etc. You know where the data should be coming from. You still
have to validate it. W/o register globals, you just use $var and have no
idea where it's coming from. You may think it's coming from a posted form,
but the user actually passed it in the url. Or, you use $var2, not expecting
it to come from the user at all, but the user passes it in the URL and it
overwrites $var2.

register_globals isn't always "bad". It just allows for more errors and
holes with it on if you're not careful.

---John Holmes...


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: register_globals in php4

am 10.05.2002 00:08:34 von Kevin Stone

----- Original Message -----
From: "Miguel Cruz"
To: "Patrick Hsieh"
Cc:
Sent: Thursday, May 09, 2002 11:52 AM
Subject: Re: [PHP] register_globals in php4


> On Fri, 10 May 2002, Patrick Hsieh wrote:
> > php4.1 recommends to set register_globals=off in php.ini to make php
> > more strict. My question is, if I turn off register_globals, what will
> > happen if any malicious user just try to modify the variable values in
> > the url? Say,
> >
> > http://www.domain.com/xxx.php?id=3&sex=female
> >
> > Does it work if user just change the value in the URL directly and send
> > the url directly to web server?
> >
> > How can we avoid the malicious attack by directly http GET/POST with
> > modified parameter values to make possible system error or compromise?
>
> If register_globals is off, then you'll get $_GET['id'] = 3 and
> $_GET['sex'] = female. It's then up to you to make sure those are okay.
> But at least $id and $sex won't get set until you explicitly set them in
> your code.
>
> miguel
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php


Hmm. No offense Miguel, but I don't believe turning Registered Globals off
will have any effect on security. Turning Registered Globals off just
provides a more strict environment for coding. Example..

If the url were http://www.dom.com/index.php?password=xuUaB67sf

if (isset($_GET['password'])) // Registered globals off.
{
$password = $_GET['password'];
echo $password;
}
?>
.. is no more or less secure than..
if (isset($password)) // Registered globals on.
{
echo $password;
}
?>

> > How can we avoid the malicious attack by directly http GET/POST with
> > modified parameter values to make possible system error or compromise?

Security in this regard has everything to do with ensuring that the input
you're recieving is what you expect. Some good tips would be to define
maximum string lengths, check for legal variable types, and look for invalid
characters. If something doesn't look right then you simply don't allow the
request to proceed. Example..

function validate($str)
{
$max_len = 15;
$str_len = strlen($str);
if ($str_len > $max_len)
return FALSE;
elseif (gettype($str) != "string")
return FALSE;
elseif (eregi(/whatever you think might be invalid/, $str));
return FALSE;
else
return TRUE;
}

if (validate($password))
{
echo $password;
}
else
{
echo "INVALID INPUT";
exit;
}
?>

Generally speaking this will be more than adequate. But if you want to get
serious then you can record a timestamp and IP/domain for every transaction
on your website then auto-block any user spamming your system. For example,
if someone is trying out passwords over and over again, after 3 consecutive
tries your system could block the transaction and print out a warning.
After 3 batches of 3 consecutive tries the system could block the user and
email you a notice. But becuase this user information can be faked the most
sophisticated systems.. the ones that corporations install behind their
firewalls and cost $20,000 for the installation alone, actually record and
analyze patterns of behavior using neural net software.

-Kevin



--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: register_globals in php4

am 10.05.2002 00:33:55 von Miguel Cruz

On Thu, 9 May 2002, Kevin Stone wrote:
>> If register_globals is off, then you'll get $_GET['id'] = 3 and
>> $_GET['sex'] = female. It's then up to you to make sure those are okay.
>> But at least $id and $sex won't get set until you explicitly set them in
>> your code.
>
> Hmm. No offense Miguel, but I don't believe turning Registered Globals off
> will have any effect on security.

If all programmers were perfect, very few security mechanisms would be
necessary.

But they aren't, so things like this just make it a little bit easier to
create secure software.

miguel


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: register_globals in php4

am 10.05.2002 13:16:06 von M.Ford

> -----Original Message-----
> From: Kevin Stone [mailto:kevin@helpelf.com]
> Sent: 09 May 2002 23:09
>
> Hmm. No offense ..., but I don't believe turning
> Registered Globals off
> will have any effect on security. Turning Registered Globals off just
> provides a more strict environment for coding. Example..
>
> If the url were http://www.dom.com/index.php?password=xuUaB67sf
>
> > if (isset($_GET['password'])) // Registered globals off.
> {
> $password = $_GET['password'];
> echo $password;
> }
> ?>
> .. is no more or less secure than..
> > if (isset($password)) // Registered globals on.
> {
> echo $password;
> }
> ?>

No, but this:

if (isset($password)): // register_globals on
$super_user = $password==$super_password;
endif;

if ($super_user):
// sensitive admin stuff
endif;

is more secure than:

if (isset($_GET['password'])): // register_globals off
$super_user = $_GET['password']==$super_password;
endif;

if ($super_user):
// sensitive admin stuff
endif;

(OK, you or I wouldn't code like that, but a Web hoster may want the reassurance of being able to protect naive customers from this kind of mistake.)

Also, by using the $_POST, $_GET arrays, you know exactly where the input is coming from (even if register_globals is also on!). If you have register_globals set to on, and you just look to see if (say) $password has a value, which you're expecting to come from a form field, you can't actually tell whether it's been overridden by some smarty-pants typing in the URL with ?password=super_password on the end. If you check specifically for $_POST['password'], you at least have the assurance that it's come from a form field as you were expecting.

Granted, register_globals and using the $_* arrays is not the complete solution, but it does add a small extra layer of assurance.

Cheers!

Mike

------------------------------------------------------------ ---------
Mike Ford, Electronic Information Services Adviser,
Learning Support Services, Learning & Information Services,
JG125, James Graham Building, Leeds Metropolitan University,
Beckett Park, LEEDS, LS6 3QS, United Kingdom
Email: m.ford@lmu.ac.uk
Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: register_globals in php4

am 10.05.2002 13:35:45 von Zeev Suraski

At 14:16 10/05/2002, Ford, Mike [LSS] wrote:
>No, but this:
>
> if (isset($password)): // register_globals on
> $super_user = $password==$super_password;
> endif;
>
> if ($super_user):
> // sensitive admin stuff
> endif;
>
>is more secure than:
>
> if (isset($_GET['password'])): // register_globals off
> $super_user = $_GET['password']==$super_password;
> endif;
>
> if ($super_user):
> // sensitive admin stuff
> endif;

You meant it the other way around, didn't you? :)

>Also, by using the $_POST, $_GET arrays, you know exactly where the input
>is coming from (even if register_globals is also on!). If you have
>register_globals set to on, and you just look to see if (say) $password
>has a value, which you're expecting to come from a form field, you can't
>actually tell whether it's been overridden by some smarty-pants typing in
>the URL with ?password=super_password on the end. If you check
>specifically for $_POST['password'], you at least have the assurance that
>it's come from a form field as you were expecting.

There's a bit of a misperception about the security that
register_globals=off buys you. Basically, anything coming from the user
cannot be trusted, and that includes post variables in $_POST[] (I could
write my own form and send whatever variables I want to your form
handler). So, generally, anything in $_GET, $_POST and $_COOKIE (or
$_REQUEST, in general) cannot be trusted, and should be treated as
'possibly hostile'. The new $_ENV variable, however, can be trusted, as it
cannot be poisoned by the remote user, and also, most of the information in
$_SERVER can be trusted, because it's coming from the web server.

What does register_globals buy you? Two simple things:
(a) A clean global scope, which cannot be poisoned by the remote user, as
your example illustrated (only backwards).
(b) Reliable $_ENV and $_SERVER arrays, and the knowledge that they cannot
be poisoned by get/post/cookie data coming from the user.

Zeev


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: register_globals in php4

am 10.05.2002 13:53:50 von M.Ford

> -----Original Message-----
> From: Zeev Suraski [mailto:zeev@zend.com]
> Sent: 10 May 2002 12:36
>
> You meant it the other way around, didn't you? :)

Er, yes! ;)

(I cut-and-pasted one example to create the other, and then changed the wrong "on" to "off"!!)

Cheers!

Mike

------------------------------------------------------------ ---------
Mike Ford, Electronic Information Services Adviser,
Learning Support Services, Learning & Information Services,
JG125, James Graham Building, Leeds Metropolitan University,
Beckett Park, LEEDS, LS6 3QS, United Kingdom
Email: m.ford@lmu.ac.uk
Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: register_globals in php4

am 10.05.2002 14:13:12 von M.Ford

> -----Original Message-----
> From: Ford, Mike [LSS] [mailto:M.Ford@lmu.ac.uk]
> Sent: 10 May 2002 12:54
> To: 'Zeev Suraski'
> Cc: php-general@lists.php.net
> Subject: RE: [PHP] register_globals in php4
>
> > -----Original Message-----
> > From: Zeev Suraski [mailto:zeev@zend.com]
> > Sent: 10 May 2002 12:36
> >
> > You meant it the other way around, didn't you? :)
>
> Er, yes! ;)
>
> (I cut-and-pasted one example to create the other, and then
> changed the wrong "on" to "off"!!)

Oh, no! That's not what you meant! (It must be Friday afternoon!! :)

I should have said "less secure" rather than "more secure".

Am I right this time?

Damn. (It must be Friday afternoon!! :)

Cheers!

Mike

------------------------------------------------------------ ---------
Mike Ford, Electronic Information Services Adviser,
Learning Support Services, Learning & Information Services,
JG125, James Graham Building, Leeds Metropolitan University,
Beckett Park, LEEDS, LS6 3QS, United Kingdom
Email: m.ford@lmu.ac.uk
Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: register_globals in php4

am 10.05.2002 15:28:12 von Zeev Suraski

At 15:13 10/05/2002, Ford, Mike [LSS] wrote:
>I should have said "less secure" rather than "more secure".
>
>Am I right this time?

Yep :)

Zeev


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: register_globals in php4

am 10.05.2002 20:20:38 von Miguel Cruz

On Fri, 10 May 2002, Ford, Mike [LSS] wrote:
> Also, by using the $_POST, $_GET arrays, you know exactly where the
> input is coming from (even if register_globals is also on!). If you
> have register_globals set to on, and you just look to see if (say)
> $password has a value, which you're expecting to come from a form field,
> you can't actually tell whether it's been overridden by some
> smarty-pants typing in the URL with ?password=super_password on the end.
> If you check specifically for $_POST['password'], you at least have the
> assurance that it's come from a form field as you were expecting.

This is a very false sense of security. Anyone with cURL (or even telnet)
can trivially fake any POST or cookie inputs they want to.

miguel


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: register_globals in php4

am 11.05.2002 01:57:45 von Luc Saint-Elie

Mike,

Both of your bit of code are not equal.

On my ISP in 4.0.6 isset returned false if the variable was not existing OR
empty

in 4.2 isset returns true if the variable exists but is empty, so you may
want to check with empty instead of isset

Luc

At 12:16 10/05/2002 +0100, Ford, Mike [LSS] wrote:
> > -----Original Message-----
> if (isset($password)): // register_globals on
> $super_user = $password==$super_password;
> endif;
>
> if ($super_user):
> // sensitive admin stuff
> endif;
>
>is more secure than:
>
> if (isset($_GET['password'])): // register_globals off
> $super_user = $_GET['password']==$super_password;
> endif;
>
> if ($super_user):
> // sensitive admin stuff
> endif;


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php