Well, in this particular case it really makes no difference as PHP_AUTH_* is data that comes from the user anyway. Whether it is sent in the GET-method data or in the Authenticate header is completely irrelevant and turning register_globals off does not make any difference whatsoever.
The reason in this particular case that PHP_SELF could not be overwritten was that the internal value overwrote the injected one. For PHP_AUTH_* you probably didn't provide an Authenticate header so the GET-method version of the data was taken. Had you provided the Authenticate header in the request then that version would have overridden the GET-method version. However since both sets come from the user, they are equally hackable and you'd need to send the correct PHP_AUTH_USER and PHP_AUTH_PWD values in the GET-method data anyway. If you know the username and password, you might as well just log in normally. But yes, in recent versions of PHP you are not able to overwrite these values with GET-method data precisely because people overreact to situations like this without really thinking about it logically. There are some built-in variables that, if overwritten, would actually be able to cause security problems. Old versions of PHP had an issue related to this with the file upload vars. So not all of this is unfounded paranoia. And in this particular case for built-in variables like this, variables_order does not really affect anything since there is no entry for built-in vars in that order. Of course, if you removed "G" from the variables_order then you couldn't overwrite anything with GET-method data, but you could of course inject the same data via any of the other methods. -Rasmus On 21 Feb 2002, Lars Torben Wilson wrote: > On Thu, 2002-02-21 at 22:31, K.Tomono wrote: > > Hi there. > > > > This must be a curious question, but I want to know... > > Globals, and register_globals = on, are insecure for exactly this > reason. This is why new versions of PHP will default to register_globals > = off, and why it's a good idea to use register_globals = off in any > case. > > For more discussion of this issue, please read the following: > > http://www.php.net/release_4_1_0.php > > > Cheers, > > Torben > > > Recently I've checked several globals, how it is overwritten. > > > > the globals are $PHP_SELF and $PHP_AUTH_USER. > > > > the first time, $PHP_AUTH_USER. > > This is overwritten by the http GET values when such a following uri. (and > > Post will be so.) > > http://foo.bar.com/test.php3?PHP_AUTH_USER=CRACK > > > > This case is tested under PHP Version 3.0.18-i18n-ja-2. > > > > but is not overwritten under PHP Version 4.0.3pl1 > > > > > > the second, $PHP_SELF. > > This is not overwritten by the http GET values when such a following uri. > > http://foo.bar.com/test.php3?PHP_SELF=CRACK.php > > > > This is true both under PHP Version 4.0.3pl1 and PHP Version > > 3.0.18-i18n-ja-2 > > > > > > the difference is probably that PHP_AUTH_USER is value from http request > > originally > > (="Authorization" header), but PHP_SELF is server side, I think. > > > > though, such above behavior with each global is the intended spec of PHP? > > Or Simply by the order of the evaluation in internal for these values? > > > > > > I tested with my test servers. > > my test server configuration, php.ini is defined with each > > > > PHP3: register_globals (none. not defined.) > > PHP4: register_globals = on > > > > I've cheked with phpinfo() also. > > > > > > Any opinion will be appreciated. > > Thanks. > > > > ----------------------- > > K.Tomono > > > > > > -- > > PHP General Mailing List (http://www.php.net/) > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > -- > Torben Wilson <[EMAIL PROTECTED]> > http://www.thebuttlesschaps.com > http://www.hybrid17.com > http://www.inflatableeye.com > +1.604.709.0506 > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
