Re: Security Issues

- My mind is pretty firm about implementing shortcuts for $HTTP_*_VARS. People are going to rebel big time if we remove their global variables by default, and make them use these exceptionally long alternatives instead. Most people I talked to (virtually all of them except for you :) agreed with that - E_SECURITY is a good idea, but like the other ideas raised in this discussion, it doesn't have all that much to do with the specific issue at hand. We have no magical way of detecting usage of variables which is a potential security risk, as opposed to one which is not. Unfortunately, both are very common. At 05:45 28/07/2001, Hartmut Holzgraefe wrote:

Zeev Suraski wrote: Anyway, to be more constructive - Andi had an idea when we were catching a cab earlier today (yesterday). His idea (which I'm just pitching, we haven't thought this through at all yet) is that instead of having register_globals on, or off, we would have it as unset, by default. When unset (i.e., on new installations) - PHP will not run, but instead display information about register_globals, its security implications, examples, and a general recommendation to turn it off if at all possible. We can easily point the user to the location of the php.ini file that he has to edit in order to modify register_globals to be either on or off. i was thinking about having an additional error_level E_SECURITY besides E_NOTICE and having both of them activated by default in future php.ini distributions although i like your idea too, i'm afraid it won't reach all users as often they are not the ones who do the installation but just use it so chances are that the system administrator responsible for installing php just turns register_global off again after installation while the warnings produced will never reach the developers E_SECURITY, on the other hand, would have effect at runtime, not on installation, and the message would reach the developers (if they care at all, i have seen enough code having @s in all places or beginning with error_reporting(0) :( ) besides that E_SECURITY could be used in other places as well ... the only drawback on my solution right now is that E_SECURITY together with display_errors would breack every script generating HTTP headers, as globals registration is done way before the script is started so i thought of an additional mechanism that would not register GPCs generally as globals but on demand, producing warnings whenever the feature is really used instead of when it is generaly turned on like <?php echo $a[hello]; ?> produces Warning: Use of undefined constant hello - assumed 'hello' ... or <?php echo $hello; ?> leads to Warning: Undefined variable: hello we could register globals on demand while issueing Warning: Undefined variable: hello - assumed $HTTP_GET_VARS['hello'] ok, this might lead to a slight performance hit with register_globals on, but i wouldn't as it is identified as bad practice anyway as long as it doesn't break existing code but just slows it down [...] it'd encourage (force) application developers to write portable applications (which is a good thing - apps based on register_globals=on are not portable, [...] hm, maybe having E_PROTABILITY as an additional error_reporting level would be worth a thought ... ? PS: i definetly like the idea of having track_vars generate a FORM array

    of some sort containint both GET and POST vars, being able to change
    from methods without having to double-check the form processing code
    could  be worth it

    regarding the convenience of having _GET[] besides HTTP_GET_VARS[]
    and such i'm not sure yet (and i hope i got it right that both
    variants will be just references to the same array internally ?)

    maybe having another ini-parameter like short_track_vars or
    convenience_track_vars? as i said, i'm not at all sure about it yet

... -- Hartmut Holzgraefe hartmut@six.de http://www.six.de +49-711-99091-77 -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: php-dev-unsubscribe@lists.php.net For additional commands, e-mail: php-dev-help@lists.php.net To contact the list administrators, e-mail: php-list-admin@lists.php.net

-- Zeev Suraski <zeev@zend.com> CTO & co-founder, Zend Technologies Ltd. http://www.zend.com/