RE: [PHP] register_globals in php4
-Original Message-
From: Kevin Stone [mailto:[EMAIL PROTECTED]]
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: [EMAIL PROTECTED]
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: [PHP] register_globals in php4
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: [PHP] register_globals in php4
-Original Message- From: Zeev Suraski [mailto:[EMAIL PROTECTED]] 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: [EMAIL PROTECTED] 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: [PHP] register_globals in php4
-Original Message- From: Ford, Mike [LSS] [mailto:[EMAIL PROTECTED]] Sent: 10 May 2002 12:54 To: 'Zeev Suraski' Cc: [EMAIL PROTECTED] Subject: RE: [PHP] register_globals in php4 -Original Message- From: Zeev Suraski [mailto:[EMAIL PROTECTED]] 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: [EMAIL PROTECTED] 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: [PHP] register_globals in php4
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: [PHP] register_globals in php4
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: [PHP] register_globals in php4
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
[PHP] register_globals in php4
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=3sex=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 [EMAIL PROTECTED] 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: [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=3sex=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: [PHP] register_globals in php4
- Original Message - From: Patrick Hsieh [EMAIL PROTECTED] 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: [PHP] register_globals in php4
- Original Message -
From: Miguel Cruz [EMAIL PROTECTED]
To: Patrick Hsieh [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
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=3sex=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: [PHP] register_globals in php4
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
