Re: [PHP-DEV] Security Issues (isset stuff)
On Sunday 29 July 2001 19:13, [EMAIL PROTECTED] wrote: ...stuff pointing out how you'd get no warning messages when the evil guy sets the variables from outside. You missed my point, which is the good guy would get the warning messages when he tested the code himself without sending in the 'bad' variables. There's no point showing the warning messages to the bad guy! -- Phil Driscoll -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
FW: [PHP-DEV] Security Issues
Just passing this along form Ramsi... who sent it to me instead of the list. (unless he wants to unsubscribe from my point of view :P )-Original Message-From: Ramsi Sras [mailto:[EMAIL PROTECTED]]UNSUBSCRIBE ME PLEASE!! Brian Tanner schrieb: Brian Foddy actually brings up a really important issue, which would go along way to making (at least me) much happier with the proposed change. *If* there will be: $_Get[] $_Post[] $_Cookie[] -- can we also have something else to the tune of: $_External or $_User or $_Something That gets populated based on the ordering set for GPC right now in the .ini file? I think it would go really far towards helping a newbie (and to helping people fix their existing code), if there was one place that they could look, to find the old value that they are now missing. People can still go to _Get, _Post, and _Cookie if they require that level of granularity, but I think most will be happy with a general container for what Register_Globals *would* have done. -Brian T -Original Message- If I can just interject once, I was a bit skeptical of this thread at first but I'm starting to come around to Zeev's point of view. Security aside (which I know it shouldn't be) I found in my own coding I always started naming post or get variables like $form_user_name or $post_user_name so I could easily tell just by looking at individual sections of the code that this variable was web input, vs my own internal variable. But even still, it can be confusing to newbes trying to understand "just how did this variable get its value?". Having the $_GET[ "post_user_name"] is much more straight forward. But is there a $_POST call also? Making a important distinction between data posted or getted input? If so, that may be a small inconvienence. Good debate tho, and well timed for other issues I'm dealing with. Brian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
UNSUBSCRIBE ME PLEASE!! Zeev Suraski schrieb: - 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 [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 > >-- >PHP Development Mailing List http://www.php.net/> >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] >To contact the list administrators, e-mail: [EMAIL PROTECTED] -- Zeev Suraski [EMAIL PROTECTED]> CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
UNSUBSCRIBE ME PLEASE!! Andi Gutmans schrieb: Hey, I thought of an idea yesterday which could make everyone happy. In the default php.ini we set the register_globals to a new value "unset". If PHP runs with this INI value it will display a page telling you that you need to define the register_globals option in your php.ini and explains the pros/cons security concerns involved (IMO we should recommend register_globals=off). This way we won't break existing sites which already have php.ini and we have an easy way to feed new users w/ the required information. Of course, I still think we should think of a nicer way to access form variables such as $_FORM[] in order to make it easier for the developer. Andi -- PHP Development Mailing List http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
UNSUBSCRIBE ME PLEASE!! Ron Chmara schrieb: On Saturday, July 28, 2001, at 12:52 PM, Zeev Suraski wrote: > At 06:01 28/07/2001, Phil Driscoll wrote: >> I and no doubt thousands of others will turn >> register_globals on because it gives much more readable code, >> much less >> typing and does not IMHO add one jot to the security of my >> applications. > I have no doubt that thousands would turn it back on. I can't > do anything about it, and as I said numerous times in numerous > metaphors, I'm quite alright with that. I have roughly 2,000 files to fix before I can use it with my biggest client :-) > I also can't imagine people avoiding PHP because variables > are accessed using $_FORM['foo'], instead of $foo. People are > not *THAT* dumb or lazy. Discussing this issue in the OSCon, > Rasmus claimed that right now he can teach PHP to a monkey in 3 > hours, and he wouldn't want to be limited only to smart > Gorillas in the future. I firmly believe that if a monkey can > figure out $foo, $_FORM['foo'] is not going to be the > showstopper. Well, there's two *new* learning curves for the never-programmed-before user (monkey?). 1. Understanding arrays. The newest of the newbies are still trying to grok strings, and concepts like "get" or "post". 2. They have almost no examples, whatsoever, to use, for learning how to work with variables in this manner. Both of these issues, combined, increase the "monkey" factor. Most online and printed tutorials available do not use HTTP_*_VARS (or any future TBI vars shorthand). The example code, all over php.net and zend.com, does not use it. Even if we encourage them to consider it "the right thing" to do, they don't really know how to go about doing it. I went to google.com, and typed in "PHP tutorials",and started looking around... http://hotwired.lycos.com/webmonkey/99/21/index2a.html - Explains HTTP_POST_VARS, but doesn't use it. http://www.devshed.com/Server_Side/PHP/ - Many tutorials, looked at a few, none used it. http://www.linuxguruz.org/z.php - Many tutorials, looked at a few, none used it. http://www.phpdeveloper.org/ - Many tutorials, looked at a few, none used it. I think, perhaps, that this is one of the reasons that so much of the PHP codebase isn't usable with register_globals = off. The learning curve is steep, because it's basically undocumented, in terms of tutorials, examples, downloadable snippets/functions, etc. So we have a chicken/egg problem, where the new monkey has to make a big jump, and use a relatively hidden method of acccessing variables, because almost every tutorial on PHP is "wrong". Even the smart gorillas, (the ones writing the tutorials), aren't using it, probably because they never learned how/why to use it.. If we can fix #2, #1 may not require as much effort. As it currently stands, if would be akin to releasing a version of PHP where we suddenly required them (by default, disable if needed) to change every variable they used from $foo to %[foo]. So, beyond my normal ramble: If we were to do this, we might want to start by putting examples in place, if only to show users _how_ to do it. Even if we don't, we still need to start populating examples, if only to show users how they _can_ work with register globals= off. -Ronabop --2D426F70|759328624|00101101011001100111 [EMAIL PROTECTED], 520-326-6109, http://www.opus1.com/ron/ The opinions expressed in this email are not necessarily those of myself, my employers, or any of the other little voices in my head. -- PHP Development Mailing List http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
UNSUBSCRIBE ME PLEASE!! Zeev Suraski schrieb: At 16:28 28/07/2001, Ron Chmara wrote: >On Saturday, July 28, 2001, at 12:52 PM, Zeev Suraski wrote: >>At 06:01 28/07/2001, Phil Driscoll wrote: >>> I and no doubt thousands of others will turn >>>register_globals on because it gives much more readable code, much less >>>typing and does not IMHO add one jot to the security of my applications. >>I have no doubt that thousands would turn it back on. I can't do >>anything about it, and as I said numerous times in numerous metaphors, >>I'm quite alright with that. > >I have roughly 2,000 files to fix before I can use it with my biggest >client :-) I understand that. This change, if implemented on existing code, requires changes to the vast majority of existing scripts. My guess is that chances are that at least several of these 2,000 files include issues that will be resolved once you move to register_globals=off compatibility. Some of them might be potentially exploited, even though perhaps none of them is. >> I also can't imagine people avoiding PHP because variables are >> accessed using $_FORM['foo'], instead of $foo. People are not *THAT* >> dumb or lazy. Discussing this issue in the OSCon, Rasmus claimed that >> right now he can teach PHP to a monkey in 3 hours, and he wouldn't want >> to be limited only to smart Gorillas in the future. I firmly believe >> that if a monkey can figure out $foo, $_FORM['foo'] is not going to be >> the showstopper. > >Well, there's two *new* learning curves for the never-programmed-before >user (monkey?). >1. Understanding arrays. The newest of the newbies are still trying to >grok strings, and concepts like "get" or "post". Understanding variables is not intuitive to many people either. Telling people "use $foo" or "use $_FORM['foo']" is equally complex in my opinion, since you can copy it, as is, without having to actually understand what variables, or arrays, are. >2. They have almost no examples, whatsoever, to use, for learning how to >work with variables in this manner. This is why I said it should be gradual. Implement the new $_GET/$_POST/$_FORM etc. in 4.0.7, and make the default change in 4.1.0, which would come a month or two later. We can probably get the authors of some of the high profile PHP apps to fix them to be register_globals=off compliant. >Both of these issues, combined, increase the "monkey" factor. Most online >and printed tutorials available do not use HTTP_*_VARS (or any future TBI >vars shorthand). The example code, all over php.net and zend.com, does not >use it. Even if we encourage them to consider it "the right thing" to do, >they don't really know how to go about doing it. I went to google.com, and >typed in "PHP tutorials",and started looking around... >http://hotwired.lycos.com/webmonkey/99/21/index2a.html - Explains >HTTP_POST_VARS, but doesn't use it. >http://www.devshed.com/Server_Side/PHP/ - Many tutorials, looked at a >few, none used it. >http://www.linuxguruz.org/z.php - Many tutorials, looked at a few, none >used it. >http://www.phpdeveloper.org/ - Many tutorials, looked at a few, none used it. > >I think, perhaps, that this is one of the reasons that so much of the PHP >codebase isn't usable with register_globals = off. The learning curve is >steep, because it's basically undocumented, in terms of tutorials, >examples, downloadable snippets/functions, etc. So we have a chicken/egg >problem, where the new monkey has to make a big jump, and use a relatively >hidden method of acccessing variables, because almost every tutorial on >PHP is "wrong". Even the smart gorillas, (the ones writing the tutorials), >aren't using it, probably because they never learned how/why to use it.. >If we can fix #2, #1 may not require as much effort. As it currently >stands, if would be akin to releasing a version of PHP where we suddenly >required them (by default, disable if needed) to change every variable >they used from $foo to %[foo]. > >So, beyond my normal ramble: >If we were to do this, we might want to start by putting examples in >place, if only to show users _how_ to do it. Even if we don't, we still >need to start populating examples, if only to show users I don't disagree with you here. I think it's important we set a goal to get into a situation where register_globals is set to off by default. It doesn't have to be tomorrow - after all, we did live with it for many years. The situation is a bit more pressing now that its exploitability is public knowledge, but we can still wait, and do this gradually while trying to educate the userbase about this issue. Zeev -- PHP Development Mailing List http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
UNSUBSCRIBE ME PLEASE!! Phil Driscoll schrieb: On Saturday 28 July 2001 20:52, Zeev Suraski wrote: a rebuf to each of my arguments :) Rather than prolong the agony, my point is that in all the cases where a malicious user has the chance to inject a dodgy variable, the code must normally have a logic path which allows the code to pass through an undefined usage of that variable. In testing the code with E_NOTICE on, a warning message will be displayed. The warning message could be beefed up to scare the user a bit more, but for me it is this that hits the nail on the head. I can assure you that the monkeys will screw things up whowever you change the code :) That said, It's easy to live with the proposal, especially with the import_globals() functions. Cheers -- Phil Driscoll -- PHP Development Mailing List http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
UNSUBSCRIBE ME PLEASE!! Zeev Suraski schrieb: At 01:04 29/07/2001, Phil Driscoll wrote: >On Saturday 28 July 2001 20:52, Zeev Suraski wrote: > >a rebuf to each of my arguments :) > >Rather than prolong the agony, my point is that in all the cases where a >malicious user has the chance to inject a dodgy variable, the code must >normally have a logic path which allows the code to pass through an undefined >usage of that variable. In testing the code with E_NOTICE on, a warning >message will be displayed. The warning message could be beefed up to scare >the user a bit more, but for me it is this that hits the nail on the head. *sigh* :) As I said numerous times, PHP gives you standard clean ways to test your variables without generating E_NOTICE's, namely, isset() (very popular) and empty() (less popular, but available all the same). There's a good, fairly darned good chance that exploitable code will generate no warnings whatsoever, and that code that was written with cleanliness in mind will actually be more difficult to debug than sucky E_NOTICE-generating code would. >I can assure you that the monkeys will screw things up whowever you change >the code :) > >That said, It's easy to live with the proposal, especially with the >import_globals() functions. I think the import_globals() is a good idea, provided we do it the right way, and publish it for what it is. I don't think it's going to make a remarkable difference in neither those who would have to migrate (if they want to take the benefit from register_globals=off, they'd still have to go over all of their code) or the newbies (I still believe it's not easier to use $foo than it is to use $_FORM['foo'], definitely if you have to learn about functions (import_globals()) and the notion of the global scope, the 'global' statement and/or $GLOBALS to properly use the $foo version :) I think it'd take a more educated monkey, actually ;) Zeev -- PHP Development Mailing List http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
UNSUBSCRIBE ME PLEASE!! Zeev Suraski schrieb: At 10:27 29/07/2001, Phil Driscoll wrote: >On Sunday 29 July 2001 17:35, Zeev Suraski wrote: > > *sigh* :) As I said numerous times, PHP gives you standard clean ways to > > test your variables without generating E_NOTICE's, namely, isset() (very > > popular) and empty() (less popular, but available all the same). There's a > > good, fairly darned good chance that exploitable code will generate no > > warnings whatsoever, and that code that was written with cleanliness in > > mind will actually be more difficult to debug than sucky > > E_NOTICE-generating code would. > >We'll have to agree to differ - Over the last year I must have downloaded >about 50 PHP scripts from the popular places with a view to using them. ALL >of them - yes every last one - generated warning messages under E_WARNING. Under E_WARNING or E_NOTICE? Make no mistake, I agree that quite a few and perhaps even probably the majority of the scripts are not E_NOTICE compliant. I just don't agree that the overlap between the group of scripts which are in fact E_NOTICE safe and the group of scripts which are exploitable by this issue is non existent, or even small. Zeev -- PHP Development Mailing List http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues - a bit of my experience
UNSUBSCRIBE ME PLEASE!!
Stephen van Egmond schrieb:
Rasmus Lerdorf ([EMAIL PROTECTED]) wrote:
> Think about whether in each of these cases it would have happened
if the
> developers of the app had developed with E_NOTICE on. In a
high number of
> these cases it probably wouldn't. And if this number is close
to 100%,
> then it would point to the fact that there is another less destructive
> solution here.
>
> This is why I want to go through and investigate existing PHP code
and
> have a look.
I'm a user of PHP, who would describe himself as approaching "expert"
in my knowledge.
I took a suggestion from earlier in this thread, and turned off
E_NOTICE. An excellent idea. I found a few holes in some
of my code,
which I was glad to repair, and grateful to the language for pointing
out to me.
The suggestion to turn off register_globals by default is an extremely
bad one. It would make using PHP nothing short of a pain in the ass,
break vast amounts of code, and not improve a whole lot. I _LIKE_
that
I can GET or POST to a page, and the variables will still come from
the
right place.
While considering the security angle, it's important to notice that
there is a tradeoff between a secure system and a functional system,
and that for some people, security just doesn't rate: either the
function (e.g. register_globals) is too valuable, or the downside
of a
security failure is just not all that great. A lot of people
prefer
function over security, and would find it an unwelcome arrogance if
PHP
forced them to twiddle some settings to get it back.
Finally, a small note from my PHP programming experiences:
In order to code with E_ALL, idioms like this:
if ($x)
will produce warnings if $x is not set. If you don't
want the
warnings, you have to replace it with:
if (isset($x)
$x) {
}
"if it's set and it's true"...? ugh.
One is then tempted to look for replacement functions in the
library, and immediately hits upon empty.
if (!$empty)
But as can be seen from the table at
http://bang.dhs.org/~svanegmond/logictest.php
, empty()
returns TRUE if you hand it a boolean FALSE! Otherwise, the semantics
of empty() are a good replacement for the warning-generating cast to
boolean.
This tends to make E_NOTIFY more trouble than it's worth... which is
why people (including the Debian package maintainer) keep it disabled.
Thus I recommend that empty() be fixed to return false for boolean
values. Failing that, that a non-warning-generating logical
equivalent of cast-to-boolean be provided.
--
PHP Development Mailing List http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues - a bit of my experience
UNSUBSCRIBE ME PLEASE!! Stephen van Egmond schrieb: Zeev Suraski ([EMAIL PROTECTED]) wrote: > - register_globals=on leads to insecure code, which was demonstrated time > and time again in the past. > - Once it's off, we're going to provide methods of accessing variables > which are just as easy, and quite easier in case you access them from > functions. Having form variables register as global variables is not the > 11th commandment, and it's kind of odd to see people treat it as such. It is quite the handy feature, and it will be a bummer to see it go. > - E_NOTICE is a runtime issue, one which you would have to check under all > possible paths in your logic. That's why leaving security stuff to runtime > is always never a good idea. Setting register_globals to off gives you > development-time security. I must point out that if we're referring to existing code bases, E_NOTICE and register_globals=off require as much work: all code paths have to be exercised to catch all the old-style idioms. I was trying to step back a bit and identify some of the patterns in the attacks identified in the paper. One extremely popular pattern was spoofing variables by overwriting them: GET variables overwriting POST, usually, and I suggested that some SAPI stunt be pulled to catch that. Although this would improve things, it bears noting that: - it deprecates a valid (on Apache) idiom which, at least, Rasmus uses - this only makes it harder to spoof variables, not impossible. But at least that's something. Whatever. The idea hasn't caught on. I recognize it probably wasn't worthy. -Steve -- PHP Development Mailing List http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues - a bit of my experience
UNSUBSCRIBE ME PLEASE!!UNSUBSCRIBE ME PLEASE!!UNSUBSCRIBE ME PLEASE!!UNSUBSCRIBE ME PLEASE!!UNSUBSCRIBE ME PLEASE!!UNSUBSCRIBE ME PLEASE!! Zeev Suraski schrieb: At 21:34 29/07/2001, Stephen van Egmond wrote: >Zeev Suraski ([EMAIL PROTECTED]) wrote: > > - register_globals=on leads to insecure code, which was demonstrated time > > and time again in the past. > > - Once it's off, we're going to provide methods of accessing variables > > which are just as easy, and quite easier in case you access them from > > functions. Having form variables register as global variables is not the > > 11th commandment, and it's kind of odd to see people treat it as such. > >It is quite the handy feature, and it will be a bummer to see it go. It's not going. It's just being turned off by default and flagged as "use only if you REALLY know what you're doing" feature, and don't really care about portability (the only way to write portable PHP apps is to assume register_globals is off, that's been true for a while now). > > - E_NOTICE is a runtime issue, one which you would have to check under all > > possible paths in your logic. That's why leaving security stuff to > runtime > > is always never a good idea. Setting register_globals to off gives you > > development-time security. > >I must point out that if we're referring to existing code bases, >E_NOTICE and register_globals=off require as much work: all code paths >have to be exercised to catch all the old-style idioms. I disagree. For E_NOTICE=off, you have to go through all of the possible logical paths. For register_globals=off, you only have to know your input variables, and a searchreplace would do. It's true that in some apps, where you have no idea or don't remember what the input variables are, it would take some time to figure out what the input vars are, but it's still much easier than going through all of the possible logical paths. >I was trying to step back a bit and identify some of the patterns in >the attacks identified in the paper. One extremely popular pattern was >spoofing variables by overwriting them: GET variables overwriting >POST, usually, and I suggested that some SAPI stunt be pulled to catch >that. > >Although this would improve things, it bears noting that: > >- it deprecates a valid (on Apache) idiom which, at least, Rasmus uses >- this only makes it harder to spoof variables, not impossible. > But at least that's something. > >Whatever. The idea hasn't caught on. I recognize it probably wasn't >worthy. Protecting POST vars from GET has no serious security viability, even though as I said a few days ago, in practice, a hell of a lot more people know how to spoof GET vars than those who know how to spoof POST or cookie vars. I believe that having $_POST, $_GET, $_COOKIE and $_FORM would give you the best of all worlds, as it would really lead you to use the right variable for the job. Zeev -- PHP Development Mailing List http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues - a bit of my experience
On Sunday 29 July 2001 19:42, Stephen van Egmond wrote:
will produce warnings if $x is not set. If you don't want the
warnings, you have to replace it with:
if (isset($x) $x) {
}
if it's set and it's true...? ugh.
One is then tempted to look for replacement functions in the
library, and immediately hits upon empty.
if (!$empty)
But as can be seen from the table at
http://bang.dhs.org/~svanegmond/logictest.php , empty()
returns TRUE if you hand it a boolean FALSE! Otherwise, the semantics
of empty() are a good replacement for the warning-generating cast to
boolean.
I agree - to my mind empty is broken in this respect and also in the respect
that it returns true for a string containing '0'. Consequently I (and I
assume everyone else, unless I'm missing some occasion that this behaviour is
useful) can never use empty in my code.
Zeev was recently saying that he believed empty() was not as popular as
isset() - and I suspect this is the reason.
I think that empty() (for scalars) really should behave thus:
function empty($var)
{
return !(isset($Var) strcmp($var,''));
}
as this is what needs to be done over and over again to validate form input.
Maybe people really do use empty, so changing the behaviour will break loads
of code. In which case an extra parameter $Useful, could be set to true to
give useful behaviour :)
--
Phil Driscoll
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues - a bit of my experience
At 01:22 30/07/2001, Phil Driscoll wrote:
I agree - to my mind empty is broken in this respect and also in the respect
that it returns true for a string containing '0'. Consequently I (and I
assume everyone else, unless I'm missing some occasion that this behaviour is
useful) can never use empty in my code.
Zeev was recently saying that he believed empty() was not as popular as
isset() - and I suspect this is the reason.
My guess is that empty() came into the language at a much later stage.
I think that empty() (for scalars) really should behave thus:
function empty($var)
{
return !(isset($Var) strcmp($var,''));
}
as this is what needs to be done over and over again to validate form input.
Maybe people really do use empty, so changing the behaviour will break loads
of code. In which case an extra parameter $Useful, could be set to true to
give useful behaviour :)
I don't think we can change the behavior of empty() at this stage...
Zeev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
Hi Zeev! On Sun, 29 Jul 2001, Zeev Suraski wrote: Generally I agree, except I don't think we should go as far as changing the theme of PHP. Putting form variables into a different space would be the simplest and equally secure way to do the trick. yes, but a Request class can be enriched with lots of nifty utility functions. I'm not saying that it must be done in the language (though a Request class would be nice :), it can be done in PHP too (which I did). OTOH let me say I noticed two main tendencies here: on one hand Rasmus wants the language same easy and appealing it always been, so new users can jump in easily and have a fast start on the other you, Kristian and others, who want the language focus more on supporting large applications, far more complex programs than a mysql query displaying a table with results and such (i.e. 10 liners or such) We have a team of VB programmers here, and I can say big projects in Visual Basic suck raw eggs; can lead to suicidal tendencies of the programmers :) and that's why every time PHP start going in that direction I start looking arround scared (maybe Python will save me? Java? neah, I'll stay a bit longer with good ol' pal) The `security issue' thread just uncovered this divergence in the view of the language; I guess there should be a balance there, and most of the support for large apps go in PEAR as well designed components (so far I love Stig :) So, call me ignorant but besides the plans for the new zend2 I haven't seen a paper to try to clearely state where is PHP going. Like Larry Wall wrote for Perl6 (or something). Perl is already icky :) I know. thanks for your time, ciao -- teodor -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
At 19:01 7/27/2001, Rasmus Lerdorf wrote the following: -- That's also not true. Is using $foo all that better than $_GET[foo]? For a neophyte user - most definitely. Rasmus, I disagree. As someone who's first programming language was PHP, I remember the confusion when looking at code with variables coming from nowhere. Denoting the origin of a variable is simply a huge plus. But it isn't. It's by fixing an inherent design flaw in PHP. The proposed target situation is *NOT* any more difficult to the users than the situation is today. Of course it is. $foo is conceptually simpler than $_GET[foo]. I don't see how you can say it isn't. $foo is conceptually a few keystrokes. That's all simplicity I can see. [EMAIL PROTECTED] - And the eyes of them both were opened and they saw that their files were world readable and writable, so they chmoded 600 their files. - Book of Installation chapt 3 sec 7 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
Cynic wrote: Of course it is. $foo is conceptually simpler than $_GET[foo]. I don't see how you can say it isn't. $foo is conceptually a few keystrokes. That's all simplicity I can see. I think that's the whole point ... 1) $foo 2) $_GET[foo] One looks like PHP, the other looks like Perl :-) Anil -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
At 12:06 7/30/2001, Anil Madhavapeddy wrote the following: -- Cynic wrote: Of course it is. $foo is conceptually simpler than $_GET[foo]. I don't see how you can say it isn't. $foo is conceptually a few keystrokes. That's all simplicity I can see. I think that's the whole point ... 1) $foo 2) $_GET[foo] One looks like PHP, the other looks like Perl :-) Anil --end of quote-- I admit I don't know much of Perl, but my decision not to learn it was largely based on my perception that much things in Perl happen automagically (or just the language is too terse), making it hard to understand. I'm probably a strange type of guy for a PHP coder, but I like $HTTP_*_VARS arrays, and all the servers I use have register_globals = off, and error_reporting = E_ALL (with these switched to on and E_ALL ~ E_NOTICE in Directory ... sections where third-party code resides... I think I have yet to come across a class or application that's written properly (from MPOV). [EMAIL PROTECTED] - And the eyes of them both were opened and they saw that their files were world readable and writable, so they chmoded 600 their files. - Book of Installation chapt 3 sec 7 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues (isset stuff)
Hi Phil! On Mon, 30 Jul 2001, Phil Driscoll wrote: On Sunday 29 July 2001 19:13, [EMAIL PROTECTED] wrote: ...stuff pointing out how you'd get no warning messages when the evil guy sets the variables from outside. You missed my point, which is the good guy would get the warning messages when he tested the code himself without sending in the 'bad' variables. There's no point showing the warning messages to the bad guy! Yes Phil, but does your codes rely on warnings messages alone? I test every and each variable I'm about to use in the program that contains data from the user. My point was that doing that way, you save isset() tests and go ahead and test them. To be more explicit, in the case of register_globals off you won't have to fear that if you forgot to properly initialize a variable that can be set in request by the user. The only concerns are: - if the user sends less variables than you expect - if the content of those variable is illegal for their meaning. In the 1st case most of the programmers (in globals on) test it with isset() The second one is so seldomly seen that can be said it's a legend. In web programming there are more complicated security issues that we can imagine, and not addressing the small ones means we're a bit ignorant on the consequences. For instance look for : The Dangers of Allowing Users to Post Images and Cross-Site Request Forgeries (derived from the first) threads on Bugtraq. It was quite an interesting security issue I've never thought of, and now gives me hard times :) -- teodor -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues (isset stuff)
On Monday 30 July 2001 11:13, [EMAIL PROTECTED] wrote: Hi Phil! Yes Phil, but does your codes rely on warnings messages alone? No - my code relies on exceedingly thorough and paranoid validation of input, carefully constructed program flow, painstaking testing at all stages and no doubt thousands of other things my brain does unconsciously due to over 20 years of programming experience. I cannot imagine a single error I would make which register_globals=off would cure, that setting error reporting to E_ALL would not highlight during testing. Some people agree with me, others disgree. As long as you have conrol of your php.ini file, it isn't a problem :) - although it will (indeed already does!) tend to discourage me, and probably others, from releasing any of my code for public consumption. Cheers -- Phil Driscoll -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues (isset stuff)
On Monday 30 July 2001 11:52, Phil Driscoll wrote: Some people agree with me, others disgree. As long as you have conrol of your php.ini file, it isn't a problem :) - although it will (indeed already does!) tend to discourage me, and probably others, from releasing any of my code for public consumption. But I should have added that a good implementation of import_globals will remove that discouragement! Cheers -- Phil Driscoll -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
At 13:44 7/28/2001, Zeev Suraski wrote the following: -- At 05:08 27/07/2001, [EMAIL PROTECTED] wrote: Addressed to: Rasmus Lerdorf [EMAIL PROTECTED] [EMAIL PROTECTED] Or you can simply stop these people from using PHP which is another effect turning off register_globals will have. Sorry, but that doesn't hold water. Java does not have this problem because Java is so complex that this same set of users can not program in Java. Fixing this problem by making PHP more complex and eliminating these problem users is a bad idea as far as I am concerned. YES!! NO!! :) Saying people would stop using PHP (or won't get started) because of this change is a gross exaggeration. IMHO, the one and only issue at hand here is downwards compatibility, and not usability or ease of use, not even a bit. register_globals had no effect on my decision to learn PHP, or continue using it. [...] There are a hell of a lot more cases where using uninitialized variables is entirely secure, than cases where it's not. As a 'purist' coming from C background, I'd always initialize variables. PHP users would not. I had zero C knowledge when I started learning PHP, and I always initialize variables in PHP. BTW, I'm just being argumentative here. I personally think that having E_NOTICE on is a very good idea, and that apps should be E_NOTICE-clean. A great deal of PHP programmers will not agree with me, though, so I haven't made up my mind on whether I support changing this default or not. I agree with you. [EMAIL PROTECTED] - And the eyes of them both were opened and they saw that their files were world readable and writable, so they chmoded 600 their files. - Book of Installation chapt 3 sec 7 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues - a bit of my experience
Zeev Suraski ([EMAIL PROTECTED]) wrote: I don't think we can change the behavior of empty() at this stage... isempty()? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues - a bit of my experience
AMEN! I PERSONALLY DO NOT consider it a PIA to have to access the variables via $HTTP_POST... What I USUALLY do is something like this: $fldform_var1 = $HTTP_POST_VARS[form_var1]; etc. This way, I'm GUARENETEED that I got the variable FROM the location that I was expecting. Then, I refer throughout the rest of the script to $fldform_var1. Ok, also, another thing. People have been saying that We can't turn off regsiter_globals because it would require teaching arrays and stuff before we should be getting to them. Bull... ALL you have to do is say If you wish to access the data from the form field titled my_name, you MUST do $my_name = $HTTP_POST_VARS[my_name]. That's it. The student does NOT need to know at that time that $HTTP_POST_VARS is an array. You can get to that later. On Sun, 29 Jul 2001 18:25:52 -0700, [EMAIL PROTECTED] (Zeev Suraski) wrote: What you ignored completely are three facts: - register_globals=on leads to insecure code, which was demonstrated time and time again in the past. - Once it's off, we're going to provide methods of accessing variables which are just as easy, and quite easier in case you access them from functions. Having form variables register as global variables is not the 11th commandment, and it's kind of odd to see people treat it as such. - E_NOTICE is a runtime issue, one which you would have to check under all possible paths in your logic. That's why leaving security stuff to runtime is always never a good idea. Setting register_globals to off gives you development-time security. Zeev [...first part of original message deleted...] The suggestion to turn off register_globals by default is an extremely bad one. It would make using PHP nothing short of a pain in the ass, break vast amounts of code, and not improve a whole lot. I _LIKE_ that I can GET or POST to a page, and the variables will still come from the right place. [...rest of message deleted...] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues - a bit of my experience
On Mon, 30 Jul 2001, Ramsi Sras wrote: Hey, idiot. you can just send a message to [EMAIL PROTECTED], stop spamming my mailbox, or else you'll be subscribed to alot more mailing lists than you ever wanted. -Sterling UNSUBSCRIBE ME PLEASE!!UNSUBSCRIBE ME PLEASE!!UNSUBSCRIBE ME PLEASE!!UNSUBSCRIBE ME PLEASE!!UNSUBSCRIBE ME PLEASE!!UNSUBSCRIBE ME PLEASE!! Zeev Suraski schrieb: At 21:34 29/07/2001, Stephen van Egmond wrote: Zeev Suraski ([EMAIL PROTECTED]) wrote: - register_globals=on leads to insecure code, which was demonstrated time and time again in the past. - Once it's off, we're going to provide methods of accessing variables which are just as easy, and quite easier in case you access them from functions. Having form variables register as global variables is not the 11th commandment, and it's kind of odd to see people treat it as such. It is quite the handy feature, and it will be a bummer to see it go. It's not going. It's just being turned off by default and flagged as use only if you REALLY know what you're doing feature, and don't really care about portability (the only way to write portable PHP apps is to assume register_globals is off, that's been true for a while now). - E_NOTICE is a runtime issue, one which you would have to check under all possible paths in your logic. That's why leaving security stuff to runtime is always never a good idea. Setting register_globals to off gives you development-time security. I must point out that if we're referring to existing code bases, E_NOTICE and register_globals=off require as much work: all code paths have to be exercised to catch all the old-style idioms. I disagree. For E_NOTICE=off, you have to go through all of the possible logical paths. For register_globals=off, you only have to know your input variables, and a searchreplace would do. It's true that in some apps, where you have no idea or don't remember what the input variables are, it would take some time to figure out what the input vars are, but it's still much easier than going through all of the possible logical paths. I was trying to step back a bit and identify some of the patterns in the attacks identified in the paper. One extremely popular pattern was spoofing variables by overwriting them: GET variables overwriting POST, usually, and I suggested that some SAPI stunt be pulled to catch that. Although this would improve things, it bears noting that: - it deprecates a valid (on Apache) idiom which, at least, Rasmus uses - this only makes it harder to spoof variables, not impossible. But at least that's something. Whatever. The idea hasn't caught on. I recognize it probably wasn't worthy. Protecting POST vars from GET has no serious security viability, even though as I said a few days ago, in practice, a hell of a lot more people know how to spoof GET vars than those who know how to spoof POST or cookie vars. I believe that having $_POST, $_GET, $_COOKIE and $_FORM would give you the best of all worlds, as it would really lead you to use the right variable for the job. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
At 16:28 28/07/2001, Ron Chmara wrote: On Saturday, July 28, 2001, at 12:52 PM, Zeev Suraski wrote: At 06:01 28/07/2001, Phil Driscoll wrote: I and no doubt thousands of others will turn register_globals on because it gives much more readable code, much less typing and does not IMHO add one jot to the security of my applications. I have no doubt that thousands would turn it back on. I can't do anything about it, and as I said numerous times in numerous metaphors, I'm quite alright with that. I have roughly 2,000 files to fix before I can use it with my biggest client :-) I understand that. This change, if implemented on existing code, requires changes to the vast majority of existing scripts. My guess is that chances are that at least several of these 2,000 files include issues that will be resolved once you move to register_globals=off compatibility. Some of them might be potentially exploited, even though perhaps none of them is. I also can't imagine people avoiding PHP because variables are accessed using $_FORM['foo'], instead of $foo. People are not *THAT* dumb or lazy. Discussing this issue in the OSCon, Rasmus claimed that right now he can teach PHP to a monkey in 3 hours, and he wouldn't want to be limited only to smart Gorillas in the future. I firmly believe that if a monkey can figure out $foo, $_FORM['foo'] is not going to be the showstopper. Well, there's two *new* learning curves for the never-programmed-before user (monkey?). 1. Understanding arrays. The newest of the newbies are still trying to grok strings, and concepts like get or post. Understanding variables is not intuitive to many people either. Telling people use $foo or use $_FORM['foo'] is equally complex in my opinion, since you can copy it, as is, without having to actually understand what variables, or arrays, are. 2. They have almost no examples, whatsoever, to use, for learning how to work with variables in this manner. This is why I said it should be gradual. Implement the new $_GET/$_POST/$_FORM etc. in 4.0.7, and make the default change in 4.1.0, which would come a month or two later. We can probably get the authors of some of the high profile PHP apps to fix them to be register_globals=off compliant. Both of these issues, combined, increase the monkey factor. Most online and printed tutorials available do not use HTTP_*_VARS (or any future TBI vars shorthand). The example code, all over php.net and zend.com, does not use it. Even if we encourage them to consider it the right thing to do, they don't really know how to go about doing it. I went to google.com, and typed in PHP tutorials,and started looking around... http://hotwired.lycos.com/webmonkey/99/21/index2a.html - Explains HTTP_POST_VARS, but doesn't use it. http://www.devshed.com/Server_Side/PHP/ - Many tutorials, looked at a few, none used it. http://www.linuxguruz.org/z.php - Many tutorials, looked at a few, none used it. http://www.phpdeveloper.org/ - Many tutorials, looked at a few, none used it. I think, perhaps, that this is one of the reasons that so much of the PHP codebase isn't usable with register_globals = off. The learning curve is steep, because it's basically undocumented, in terms of tutorials, examples, downloadable snippets/functions, etc. So we have a chicken/egg problem, where the new monkey has to make a big jump, and use a relatively hidden method of acccessing variables, because almost every tutorial on PHP is wrong. Even the smart gorillas, (the ones writing the tutorials), aren't using it, probably because they never learned how/why to use it.. If we can fix #2, #1 may not require as much effort. As it currently stands, if would be akin to releasing a version of PHP where we suddenly required them (by default, disable if needed) to change every variable they used from $foo to %[foo]. So, beyond my normal ramble: If we were to do this, we might want to start by putting examples in place, if only to show users _how_ to do it. Even if we don't, we still need to start populating examples, if only to show users I don't disagree with you here. I think it's important we set a goal to get into a situation where register_globals is set to off by default. It doesn't have to be tomorrow - after all, we did live with it for many years. The situation is a bit more pressing now that its exploitability is public knowledge, but we can still wait, and do this gradually while trying to educate the userbase about this issue. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
On Saturday 28 July 2001 20:52, Zeev Suraski wrote: a rebuf to each of my arguments :) Rather than prolong the agony, my point is that in all the cases where a malicious user has the chance to inject a dodgy variable, the code must normally have a logic path which allows the code to pass through an undefined usage of that variable. In testing the code with E_NOTICE on, a warning message will be displayed. The warning message could be beefed up to scare the user a bit more, but for me it is this that hits the nail on the head. I can assure you that the monkeys will screw things up whowever you change the code :) That said, It's easy to live with the proposal, especially with the import_globals() functions. Cheers -- Phil Driscoll -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
At 01:04 29/07/2001, Phil Driscoll wrote: On Saturday 28 July 2001 20:52, Zeev Suraski wrote: a rebuf to each of my arguments :) Rather than prolong the agony, my point is that in all the cases where a malicious user has the chance to inject a dodgy variable, the code must normally have a logic path which allows the code to pass through an undefined usage of that variable. In testing the code with E_NOTICE on, a warning message will be displayed. The warning message could be beefed up to scare the user a bit more, but for me it is this that hits the nail on the head. *sigh* :) As I said numerous times, PHP gives you standard clean ways to test your variables without generating E_NOTICE's, namely, isset() (very popular) and empty() (less popular, but available all the same). There's a good, fairly darned good chance that exploitable code will generate no warnings whatsoever, and that code that was written with cleanliness in mind will actually be more difficult to debug than sucky E_NOTICE-generating code would. I can assure you that the monkeys will screw things up whowever you change the code :) That said, It's easy to live with the proposal, especially with the import_globals() functions. I think the import_globals() is a good idea, provided we do it the right way, and publish it for what it is. I don't think it's going to make a remarkable difference in neither those who would have to migrate (if they want to take the benefit from register_globals=off, they'd still have to go over all of their code) or the newbies (I still believe it's not easier to use $foo than it is to use $_FORM['foo'], definitely if you have to learn about functions (import_globals()) and the notion of the global scope, the 'global' statement and/or $GLOBALS to properly use the $foo version :) I think it'd take a more educated monkey, actually ;) Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
On Sunday 29 July 2001 17:35, Zeev Suraski wrote: *sigh* :) As I said numerous times, PHP gives you standard clean ways to test your variables without generating E_NOTICE's, namely, isset() (very popular) and empty() (less popular, but available all the same). There's a good, fairly darned good chance that exploitable code will generate no warnings whatsoever, and that code that was written with cleanliness in mind will actually be more difficult to debug than sucky E_NOTICE-generating code would. We'll have to agree to differ - Over the last year I must have downloaded about 50 PHP scripts from the popular places with a view to using them. ALL of them - yes every last one - generated warning messages under E_WARNING. People who code sloppily, code sloppily, the warning messages will get out. Even people who code well but don't test under E_WARNING will find that E_WARNING is their friend. I don't think that the typical uses of isset and empty actually serve to hide the warning messages that would appear in vulnerable code. Anyway, I'll shut up now and leave you in peace :) -- Phil Driscoll -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
At 10:27 29/07/2001, Phil Driscoll wrote: On Sunday 29 July 2001 17:35, Zeev Suraski wrote: *sigh* :) As I said numerous times, PHP gives you standard clean ways to test your variables without generating E_NOTICE's, namely, isset() (very popular) and empty() (less popular, but available all the same). There's a good, fairly darned good chance that exploitable code will generate no warnings whatsoever, and that code that was written with cleanliness in mind will actually be more difficult to debug than sucky E_NOTICE-generating code would. We'll have to agree to differ - Over the last year I must have downloaded about 50 PHP scripts from the popular places with a view to using them. ALL of them - yes every last one - generated warning messages under E_WARNING. Under E_WARNING or E_NOTICE? Make no mistake, I agree that quite a few and perhaps even probably the majority of the scripts are not E_NOTICE compliant. I just don't agree that the overlap between the group of scripts which are in fact E_NOTICE safe and the group of scripts which are exploitable by this issue is non existent, or even small. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues - a bit of my experience
Rasmus Lerdorf ([EMAIL PROTECTED]) wrote:
Think about whether in each of these cases it would have happened if the
developers of the app had developed with E_NOTICE on. In a high number of
these cases it probably wouldn't. And if this number is close to 100%,
then it would point to the fact that there is another less destructive
solution here.
This is why I want to go through and investigate existing PHP code and
have a look.
I'm a user of PHP, who would describe himself as approaching expert
in my knowledge.
I took a suggestion from earlier in this thread, and turned off
E_NOTICE. An excellent idea. I found a few holes in some of my code,
which I was glad to repair, and grateful to the language for pointing
out to me.
The suggestion to turn off register_globals by default is an extremely
bad one. It would make using PHP nothing short of a pain in the ass,
break vast amounts of code, and not improve a whole lot. I _LIKE_ that
I can GET or POST to a page, and the variables will still come from the
right place.
While considering the security angle, it's important to notice that
there is a tradeoff between a secure system and a functional system,
and that for some people, security just doesn't rate: either the
function (e.g. register_globals) is too valuable, or the downside of a
security failure is just not all that great. A lot of people prefer
function over security, and would find it an unwelcome arrogance if PHP
forced them to twiddle some settings to get it back.
Finally, a small note from my PHP programming experiences:
In order to code with E_ALL, idioms like this:
if ($x)
will produce warnings if $x is not set. If you don't want the
warnings, you have to replace it with:
if (isset($x) $x) {
}
if it's set and it's true...? ugh.
One is then tempted to look for replacement functions in the
library, and immediately hits upon empty.
if (!$empty)
But as can be seen from the table at
http://bang.dhs.org/~svanegmond/logictest.php , empty()
returns TRUE if you hand it a boolean FALSE! Otherwise, the semantics
of empty() are a good replacement for the warning-generating cast to
boolean.
This tends to make E_NOTIFY more trouble than it's worth... which is
why people (including the Debian package maintainer) keep it disabled.
Thus I recommend that empty() be fixed to return false for boolean
values. Failing that, that a non-warning-generating logical
equivalent of cast-to-boolean be provided.
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues (isset stuff)
Hi Phil!
On Sat, 28 Jul 2001, Phil Driscoll wrote:
That's not going to find half, or a quarter, or whatever of the problems,
since PHP has tools to cleanly handle undefined variables - namely isset()
and empty(). They, or at least isset(), are quite popular.
I always use something like:
if(!isset($Thing) /*and possibly some range checking*/))
$Thing=sensible default;
In no way is
if(!isset(_GET['Thing']) /*and possibly some range checking*/))
{
$Thing=sensible default;
well, lemme tell you my favourite:
$defRequest = array ('thing1' = '', 'thing2'='' /* ... */);
$myRequest = array_merge ($defRequest, $HTTP_GET_VARS); /* or POST*/;
This way you'll be able to simply say:
if ($myRequest[var] != default) {
// do something
}
and be sure you have something there.
any more secure (nor would it be if I wrote sensible default back to _GET.
Anyway, to check my sanity i have reread the security advisory which I first
read on the day it was published, and I am even more conviced now that
register globals=off has the tiniest of effects for gpc variables wheras
E_NOTICE has a massive effect.
Here are the examples from the advisory:
--
?php
if ($pass === hello) //= corrected to ===
$auth = 1;
...
if ($auth == 1)
echo some important information;
?
replace $pass with _GET['pass'] and the code is
equally insecure. Turn E_NOTICE on and the novice programmer will get a
nope,
in the first case I can say http://your.site/your_page.php?pass=whateverauth=1
warning message for the unset $pass.
--
?php
if (!($fd = fopen($filename, r))
echo(Could not open file: $filenameBR\n);
?
replace $filename with _GET['filename'] and this lunatic piece of code
remains a lunatic piece of code. If $filename is not meant to be coming from
the outside world then with E_NOTICE on there would be a warning message for
the unset filename.
The issue here was as always 'untrusted user data' used as trusted (I can say
?fielname='../../../etc/passwd' etc.)
And *maybe* seeing :
$fd = fopen ($_GET['filename'],'r');
something will click in the mind of the programmer ('geez, wait, this is
*straight* form the request[is sais GET], what if...)
--
?php
include($libdir . /languages.php);
?
Ok, with register_globals=off then $libdir could not be directly overwritten
from outside (unless there was some code which made that happen) however
E_NOTICE would generate a warning for an unset $libdir
Again, it will be set, and no notice will pop up, but it will be set by the
evil guy.
The advisory was not like one from eEye as clear and professional, but had a
very well defined point. And sadly, it was right.
-- teodor
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
Hi Zeev!
On Thu, 26 Jul 2001, Zeev Suraski wrote:
At 02:18 26/07/2001, Ron Chmara wrote:
If most of the PHP apps out there are or were vulnerable to
register_globals=on attacks, we can't (shouldn't) blame the whole world,
but fix the language instead.
I'd suggest fixing the code religion instead, but changing faiths is hard.
:-) If they aren't checking their vars before processing, no language
would fix it, would it?
Most would, actually. Pretty much any language which requires you to
declare variables, or, that doesn't allow external sources to declare
variables, does not have this problem. PHP is quite unique in that sense,
which is why I agree that the language is at fault. Of course, declaring
and not initializing your variable is still a programming error, but it's
much less severe and much less prone to exploits than this problem.
May I jump in? :)
As I see it, the security issue is Untrusted data coming from the user,
which collects under the request term.
What is overwritten? Server vars or user vars, and that's because there's no
hard separation between them in the register globals on case (all in the
same pot).
So why wouldn't PHP propose a Reques-Response paradigm like ASP,JSP or Zope,
before we have namespaces and such?
If I say $Request-getAttribute('geez') I am damn sure it comes from the user
and I consider the value inherently suspicious (i.e. don't just stuck it in
a mysql_query() string w/o testing.)
This can be done at PHP level or language level (where other security tests
can be addressed.)
The best teaching the pear/php devs can give to the user in the security issue
is to promote best programming practices, and IMO this is one of them;
otherwise they'll have to gulp bitter advisories about this and that popular
PHP application having an ungly bug (see phpMyAdmin, IMP, Phorum, etc.)
my 2c
-- teodor
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues (backward fix)
Hi Ron! On Sat, 28 Jul 2001, Ron Chmara wrote: On Saturday, July 28, 2001, at 12:52 PM, Zeev Suraski wrote: At 06:01 28/07/2001, Phil Driscoll wrote: I and no doubt thousands of others will turn register_globals on because it gives much more readable code, much less typing and does not IMHO add one jot to the security of my applications. I have no doubt that thousands would turn it back on. I can't do anything about it, and as I said numerous times in numerous metaphors, I'm quite alright with that. I have roughly 2,000 files to fix before I can use it with my biggest client :-) Directory /old/apps php_value auto_prepend_file globals_fix.php /Directory [globals_fix.php] extract($HTTP_GET_VARS); extract($HTTP_POST_VARS); extract($HTTP_COOKIE_VARS); etc. now they all work with register_globals off erm? :) -- teodor -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues - a bit of my experience
What you ignored completely are three facts:
- register_globals=on leads to insecure code, which was demonstrated time
and time again in the past.
- Once it's off, we're going to provide methods of accessing variables
which are just as easy, and quite easier in case you access them from
functions. Having form variables register as global variables is not the
11th commandment, and it's kind of odd to see people treat it as such.
- E_NOTICE is a runtime issue, one which you would have to check under all
possible paths in your logic. That's why leaving security stuff to runtime
is always never a good idea. Setting register_globals to off gives you
development-time security.
Zeev
At 11:42 29/07/2001, Stephen van Egmond wrote:
Rasmus Lerdorf ([EMAIL PROTECTED]) wrote:
Think about whether in each of these cases it would have happened if the
developers of the app had developed with E_NOTICE on. In a high number of
these cases it probably wouldn't. And if this number is close to 100%,
then it would point to the fact that there is another less destructive
solution here.
This is why I want to go through and investigate existing PHP code and
have a look.
I'm a user of PHP, who would describe himself as approaching expert
in my knowledge.
I took a suggestion from earlier in this thread, and turned off
E_NOTICE. An excellent idea. I found a few holes in some of my code,
which I was glad to repair, and grateful to the language for pointing
out to me.
The suggestion to turn off register_globals by default is an extremely
bad one. It would make using PHP nothing short of a pain in the ass,
break vast amounts of code, and not improve a whole lot. I _LIKE_ that
I can GET or POST to a page, and the variables will still come from the
right place.
While considering the security angle, it's important to notice that
there is a tradeoff between a secure system and a functional system,
and that for some people, security just doesn't rate: either the
function (e.g. register_globals) is too valuable, or the downside of a
security failure is just not all that great. A lot of people prefer
function over security, and would find it an unwelcome arrogance if PHP
forced them to twiddle some settings to get it back.
Finally, a small note from my PHP programming experiences:
In order to code with E_ALL, idioms like this:
if ($x)
will produce warnings if $x is not set. If you don't want the
warnings, you have to replace it with:
if (isset($x) $x) {
}
if it's set and it's true...? ugh.
One is then tempted to look for replacement functions in the
library, and immediately hits upon empty.
if (!$empty)
But as can be seen from the table at
http://bang.dhs.org/~svanegmond/logictest.php , empty()
returns TRUE if you hand it a boolean FALSE! Otherwise, the semantics
of empty() are a good replacement for the warning-generating cast to
boolean.
This tends to make E_NOTIFY more trouble than it's worth... which is
why people (including the Debian package maintainer) keep it disabled.
Thus I recommend that empty() be fixed to return false for boolean
values. Failing that, that a non-warning-generating logical
equivalent of cast-to-boolean be provided.
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
Zeev Suraski [EMAIL PROTECTED]
CTO co-founder, Zend Technologies Ltd. http://www.zend.com/
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
Generally I agree, except I don't think we should go as far as changing the
theme of PHP. Putting form variables into a different space would be the
simplest and equally secure way to do the trick.
At 08:32 26/07/2001, [EMAIL PROTECTED] wrote:
Hi Zeev!
On Thu, 26 Jul 2001, Zeev Suraski wrote:
At 02:18 26/07/2001, Ron Chmara wrote:
If most of the PHP apps out there are or were vulnerable to
register_globals=on attacks, we can't (shouldn't) blame the whole
world,
but fix the language instead.
I'd suggest fixing the code religion instead, but changing faiths is
hard.
:-) If they aren't checking their vars before processing, no language
would fix it, would it?
Most would, actually. Pretty much any language which requires you to
declare variables, or, that doesn't allow external sources to declare
variables, does not have this problem. PHP is quite unique in that sense,
which is why I agree that the language is at fault. Of course, declaring
and not initializing your variable is still a programming error, but it's
much less severe and much less prone to exploits than this problem.
May I jump in? :)
As I see it, the security issue is Untrusted data coming from the user,
which collects under the request term.
What is overwritten? Server vars or user vars, and that's because there's no
hard separation between them in the register globals on case (all in the
same pot).
So why wouldn't PHP propose a Reques-Response paradigm like ASP,JSP or Zope,
before we have namespaces and such?
If I say $Request-getAttribute('geez') I am damn sure it comes from the user
and I consider the value inherently suspicious (i.e. don't just stuck it in
a mysql_query() string w/o testing.)
This can be done at PHP level or language level (where other security tests
can be addressed.)
The best teaching the pear/php devs can give to the user in the security issue
is to promote best programming practices, and IMO this is one of them;
otherwise they'll have to gulp bitter advisories about this and that popular
PHP application having an ungly bug (see phpMyAdmin, IMP, Phorum, etc.)
my 2c
-- teodor
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
Zeev Suraski [EMAIL PROTECTED]
CTO co-founder, Zend Technologies Ltd. http://www.zend.com/
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues - a bit of my experience
Zeev Suraski ([EMAIL PROTECTED]) wrote: - register_globals=on leads to insecure code, which was demonstrated time and time again in the past. - Once it's off, we're going to provide methods of accessing variables which are just as easy, and quite easier in case you access them from functions. Having form variables register as global variables is not the 11th commandment, and it's kind of odd to see people treat it as such. It is quite the handy feature, and it will be a bummer to see it go. - E_NOTICE is a runtime issue, one which you would have to check under all possible paths in your logic. That's why leaving security stuff to runtime is always never a good idea. Setting register_globals to off gives you development-time security. I must point out that if we're referring to existing code bases, E_NOTICE and register_globals=off require as much work: all code paths have to be exercised to catch all the old-style idioms. I was trying to step back a bit and identify some of the patterns in the attacks identified in the paper. One extremely popular pattern was spoofing variables by overwriting them: GET variables overwriting POST, usually, and I suggested that some SAPI stunt be pulled to catch that. Although this would improve things, it bears noting that: - it deprecates a valid (on Apache) idiom which, at least, Rasmus uses - this only makes it harder to spoof variables, not impossible. But at least that's something. Whatever. The idea hasn't caught on. I recognize it probably wasn't worthy. -Steve -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues - a bit of my experience
I was trying to step back a bit and identify some of the patterns in the attacks identified in the paper. One extremely popular pattern was spoofing variables by overwriting them: GET variables overwriting POST, usually, and I suggested that some SAPI stunt be pulled to catch that. That's not the case. The default variable_order is EGPCS which means that POST variables will always overwrite GET variables of the same name. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues - a bit of my experience
At 21:34 29/07/2001, Stephen van Egmond wrote: Zeev Suraski ([EMAIL PROTECTED]) wrote: - register_globals=on leads to insecure code, which was demonstrated time and time again in the past. - Once it's off, we're going to provide methods of accessing variables which are just as easy, and quite easier in case you access them from functions. Having form variables register as global variables is not the 11th commandment, and it's kind of odd to see people treat it as such. It is quite the handy feature, and it will be a bummer to see it go. It's not going. It's just being turned off by default and flagged as use only if you REALLY know what you're doing feature, and don't really care about portability (the only way to write portable PHP apps is to assume register_globals is off, that's been true for a while now). - E_NOTICE is a runtime issue, one which you would have to check under all possible paths in your logic. That's why leaving security stuff to runtime is always never a good idea. Setting register_globals to off gives you development-time security. I must point out that if we're referring to existing code bases, E_NOTICE and register_globals=off require as much work: all code paths have to be exercised to catch all the old-style idioms. I disagree. For E_NOTICE=off, you have to go through all of the possible logical paths. For register_globals=off, you only have to know your input variables, and a searchreplace would do. It's true that in some apps, where you have no idea or don't remember what the input variables are, it would take some time to figure out what the input vars are, but it's still much easier than going through all of the possible logical paths. I was trying to step back a bit and identify some of the patterns in the attacks identified in the paper. One extremely popular pattern was spoofing variables by overwriting them: GET variables overwriting POST, usually, and I suggested that some SAPI stunt be pulled to catch that. Although this would improve things, it bears noting that: - it deprecates a valid (on Apache) idiom which, at least, Rasmus uses - this only makes it harder to spoof variables, not impossible. But at least that's something. Whatever. The idea hasn't caught on. I recognize it probably wasn't worthy. Protecting POST vars from GET has no serious security viability, even though as I said a few days ago, in practice, a hell of a lot more people know how to spoof GET vars than those who know how to spoof POST or cookie vars. I believe that having $_POST, $_GET, $_COOKIE and $_FORM would give you the best of all worlds, as it would really lead you to use the right variable for the job. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
I wrote a thorough response while being disconnected, but it's kind of pointless to send it considering the face to face discussion we had today. The only thing I'd like say here is that in my opinion, the fact form variables are defined as globals (as opposed to being defined just as automatically inside $_GET/$_POST or $_FORM) is hardly what makes PHP what it is. Auto form variable registration is very important and is one of the cornerstones of PHP, but it'd be equally good if it had a different syntax. Other cornerstones that make PHP what it is are the clean and non obscure syntax (I bet Thies doesn't use PHP for his shell scripts because of auto form variable registration...), the easy to use database APIs which come within the binary, and the fact it contains a full set of Web tools built into it. I think that portraying PHP as some weak version of Perl with auto global form variables is not even an understatement, but just plain wrong... 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. Again, I'm just pitching this idea, I'm not entirely sure if it's good or not. Personally, I still lean towards having register_globals off by default for new installations. This will have a very small effect on existing apps (for better and worse), it'd encourage (force) application developers to write portable applications (which is a good thing - apps based on register_globals=on are not portable, since many security-aware people turn it off), and obviously, solve the security issues we've been discussing. If we release it as 4.1.0, it's going to generate enough noise to make people aware of this issue, which is also a good thing. Zeev At 10:30 27/07/2001, Rasmus Lerdorf wrote: This is an important step, that as I said, I wanted to make for years. I just argue that as protective as you are over register_globals=on, the real flaw is there, and this is the place it should be fixed. Fixing the fact that E_NOTICE is on may also be viable, but in practice: - A huge number of cases where E_NOTICE's will be generated isn't related to security in any way, and people will be kind of pissed by it, and probably turn it back off That's an issue that can be addressed. We perhaps need better granularity on the E_NOTICE. If we distribute a php.ini-recommended, we can, and probably should enable E_NOTICE's by default. It's not the solution to the problem raised in the advisory. The very first and primary example in the advisory would most definitely have been caught by an E_NOTICE, so I don't see how this doesn't address the advisory. For reference the first example in the advisory is: ?php if ($pass = hello) $auth = 1; ... if ($auth == 1) echo some important information; ? First, the guy who wrote the advisory didn't check his code, because the above could never actually be a problem since he confuses == and = and actually always sets $auth=1, but ignoring that and fixing his code, if you turn on E_NOTICE this script generates: Warning: Undefined variable: pass in foo.php on line 2 Warning: Undefined variable: auth in foo.php on line 5 And the second example is: ?php if (!($fd = fopen($filename, r)) echo(Could not open file: $filenameBR\n); ? Again, an obvious bracket mismatch so this example also doesn't run, but running this with E_NOTICE gives: Warning: Undefined variable: filename in foo.php on line 2 Warning: Undefined variable: filename in foo.php on line 3 Same goes for example 3 which is: ?php include($libdir . /languages.php); ? Then he talks about the file upload issues which is a separate problem and one we have addressed. And then he talks about .inc files and suggests that people who just use .php for include files are vulnerable because their scripts could be run out of context. This is a different issue as well. But that's not the point. The point is that people who don't care about security or coding style (beginners or professionals, doesn't really matter) are less likely to write insecure code, because there's one mistake less that they can make. As long as they stick to the defaults, anyway. And one language less that these people are able to use. That's an empty statement, Rasmus... The auto-registered form variables are not any less usable if we change the access method to
RE: [PHP-DEV] Security Issues
At 12:36 27/07/2001, Brian Tanner wrote: Differently - sometimes Dangerously - Never I think that this means that this is quite serious, and mind-bogglingly common security flaw. When your app behaves differently, there's a one out of two, or one out of five, or one out of ten chance that this can be exploited for bad purposes. Most security exploits originate in an application which behaves in a way that the author did not anticipate. In your case, you're either lucky, talented, or both. My view is that if your apps can behave differently, chances are that there's a huge number of other apps which can also be manipulated to behave differently, and quite a few of them can be manipulated into doing 'dangerous' things. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] Security Issues
Yes, a $_FORM variable container is also on my TODO list for the new track_vars implementation... At 14:00 27/07/2001, Brian Tanner wrote: Brian Foddy actually brings up a really important issue, which would go along way to making (at least me) much happier with the proposed change. *If* there will be: $_Get[] $_Post[] $_Cookie[] -- can we also have something else to the tune of: $_External or $_User or $_Something That gets populated based on the ordering set for GPC right now in the .ini file? I think it would go really far towards helping a newbie (and to helping people fix their existing code), if there was one place that they could look, to find the old value that they are now missing. People can still go to _Get, _Post, and _Cookie if they require that level of granularity, but I think most will be happy with a general container for what Register_Globals *would* have done. -Brian T -Original Message- If I can just interject once, I was a bit skeptical of this thread at first but I'm starting to come around to Zeev's point of view. Security aside (which I know it shouldn't be) I found in my own coding I always started naming post or get variables like $form_user_name or $post_user_name so I could easily tell just by looking at individual sections of the code that this variable was web input, vs my own internal variable. But even still, it can be confusing to newbes trying to understand just how did this variable get its value?. Having the $_GET[ post_user_name] is much more straight forward. But is there a $_POST call also? Making a important distinction between data posted or getted input? If so, that may be a small inconvienence. Good debate tho, and well timed for other issues I'm dealing with. Brian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
On Sat, 28 Jul 2001, 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.
I think one issue here is that people are so used to using certain
kind of language syntax that they're simply overestimating the effort
of typing $_{GET,POST}['foo'] when needed. With some time to
get used to it, I think most of the people will see why this is a good
idea. Your idea sounds like something that might help with this.
One thing that would further this cause would be to explain how to
start converting your existing codebase to be more secure in
small chunks.
I have no experience with other web servers than Apache, but with
Apache I use for my own homepages a .htaccess similar to the one
below. I have similar settings for many virtual hosts and directories
in the server configuration files.
# Security
php_flag register_globals Off
# Error tracking / displaying / logging
php_value error_reporting 2047
php_flag display_errors Off
php_flag log_errors On
php_value error_log 'REPLACE_ME'
php_flag track_errors On
Zeev
--
--
Heikki Korpela -- [EMAIL PROTECTED] -- http://iki.fi/heko/
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
At 05:08 27/07/2001, [EMAIL PROTECTED] wrote:
Addressed to: Rasmus Lerdorf [EMAIL PROTECTED]
[EMAIL PROTECTED]
Or you can simply stop these people from using PHP which is another
effect turning off register_globals will have.
Java does not have this problem because Java is so complex that this
same set of users can not program in Java. Fixing this problem by
making PHP more complex and eliminating these problem users is a bad
idea as far as I am concerned.
YES!!
NO!! :) Saying people would stop using PHP (or won't get started) because
of this change is a gross exaggeration. IMHO, the one and only issue at
hand here is downwards compatibility, and not usability or ease of use, not
even a bit.
As I see it the whole issue revolves around the fact that some people
get used to the fact that undefined variables have a value, and rely on
it. These are the people who get hit when a hacker slips in his own
value in on such variables. If the programmer had just initialized
the variable at the top of the program, there would not be a problem.
I think the best thing you could do about this issue is:
1. ALWAYS report the use of an uninitialized variable, no matter what
level of error checking is in effect. At the very least send a message
to the error_log for every undefined variable. If the error level allows
it also complain to the browser and send an email to ServerAdmin. That
won't break any existing scripts, but depending on the text of the
email, it could give system administrators incentive to correct problem
scripts. [1] The 'send email' default should be on in the distribution.
That's not going to find half, or a quarter, or whatever of the problems,
since PHP has tools to cleanly handle undefined variables - namely isset()
and empty(). They, or at least isset(), are quite popular.
2. Make it a FATAL error. Too bad that would break so many scripts...
Maybe it could be a major effect of the E_SECURE bit. On the other
hand, if you are serious about stamping out the uninitialized variable
problem, this will do it.
I'd argue that that's actually going to make an equally messy effect on the
PHP developer community, with a much lower gain, and also, a considerable loss.
There's *nothing* wrong with the following code:
function foo()
{
for ($i=0; $i10; $i++) {
$str .= $i;
}
return $str;
}
It's safe, it's quick, and it uses an uninitialized variable. There are a
hell of a lot more cases where using uninitialized variables is entirely
secure, than cases where it's not. As a 'purist' coming from C background,
I'd always initialize variables. PHP users would not.
BTW, I'm just being argumentative here. I personally think that having
E_NOTICE on is a very good idea, and that apps should be E_NOTICE-clean. A
great deal of PHP programmers will not agree with me, though, so I haven't
made up my mind on whether I support changing this default or not.
Another main difference between having E_NOTICE turned on and having
register_globals=off is that with register_globals being off, your app will
not work, fair and square, unless you modify it to read its arguments from
the right track vars arrays. As for just setting E_NOTICE - it won't help
unless people actually check all the possible control paths of their
logic. Of course, they should do it in the testing phase. And yes, I'm
willing to bet that a great deal of them does not.
Register Globals is very convienent for people who write code with
PHP. Turning it off would be a great loss. The problem is not that
values passed to the server appear as variables, it is that some
programmers don't make sure they initialize every variable before they
use it.
There are two problems:
1. Programmers are humans, and humans are creatures that tend to make
mistakes, including stupid ones, and worse, repeat them over and over again
2. PHP, with register_globals=on, mixes information coming from the user
with information coming from code written by the developer, to a degree
where it's impossible to differentiate between the two. Given problem #1,
this often leads to security problems.
In a perfect world, you'd be able to address #1 and then #2 would have been
a non issue. But we're walking the Earth, and not wonderland, so I think
we should concentrate on solving #2 :)
Zeev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
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 [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
Apologies in advance to Zeev for arguing on this one, but be assured I firmly
believe that your solution would be to the detriment of PHP and a better
solution is possible :)
On Saturday 28 July 2001 12:44, Zeev Suraski wrote:
NO!! :) Saying people would stop using PHP (or won't get started) because
of this change is a gross exaggeration. IMHO, the one and only issue at
hand here is downwards compatibility, and not usability or ease of use, not
even a bit.
Sorry Zeev - the answer is YES. I and no doubt thousands of others will turn
register_globals on because it gives much more readable code, much less
typing and does not IMHO add one jot to the security of my applications.
That's not going to find half, or a quarter, or whatever of the problems,
since PHP has tools to cleanly handle undefined variables - namely isset()
and empty(). They, or at least isset(), are quite popular.
I always use something like:
if(!isset($Thing) /*and possibly some range checking*/))
$Thing=sensible default;
In no way is
if(!isset(_GET['Thing']) /*and possibly some range checking*/))
{
$Thing=sensible default;
}
else
{
$Thing=(_GET['Thing']);
}
any more secure (nor would it be if I wrote sensible default back to _GET.
Anyway, to check my sanity i have reread the security advisory which I first
read on the day it was published, and I am even more conviced now that
register globals=off has the tiniest of effects for gpc variables wheras
E_NOTICE has a massive effect.
Here are the examples from the advisory:
--
?php
if ($pass === hello) //= corrected to ===
$auth = 1;
...
if ($auth == 1)
echo some important information;
?
replace $pass with _GET['pass'] and the code is
equally insecure. Turn E_NOTICE on and the novice programmer will get a
warning message for the unset $pass.
--
?php
if (!($fd = fopen($filename, r))
echo(Could not open file: $filenameBR\n);
?
replace $filename with _GET['filename'] and this lunatic piece of code
remains a lunatic piece of code. If $filename is not meant to be coming from
the outside world then with E_NOTICE on there would be a warning message for
the unset filename.
--
?php
include($libdir . /languages.php);
?
Ok, with register_globals=off then $libdir could not be directly overwritten
from outside (unless there was some code which made that happen) however
E_NOTICE would generate a warning for an unset $libdir
--
File upload.
If you don't use the new functions you are potentially stuffed with register
globals on or off.
As an aside - we could have a php.ini directive which could 'break' code
which did not use the new functions - if we save an uploaded file with one
name, but set the $userfile_name to something else, and only rename the
original to $userfile_name after a call to is_uploaded_file or
move_uploaded_file.
--
?php
if (file_exists($theme)) // Checks the file exists on the local system (no
remote files)
include($theme);
?
This seems to be the same as the fopen($filename... example above.
--
In libdir/loadlanguage.php:
?php
...
include($langDir/$userLang);
?
include files called out of context. The solution is to configure your web
server, or put the include files outside the webroot so that they cannot be
run out of context.
In this example, typically $langdir should have been set inside the
application or a configuration file, but $userLang will typically have come
from the user either with this request, or previously and stored in a
database in the users profile.
So under the register_globals = off scheme, we would often end up with
something along the lines of:
?php
...
include($langDir/_GET['userLang']);
?
where $langDir is unset. We can all see how secure that is :)
--
Session files.
I am happy to concede that there should be a php.imi directive which stops
variables which can more or less be trusted, such as env and session from
entering the global namespace, so that if you want to read them you have to
look in the correct place.
--
In conclusion I would urge those who want to set register_globals=off to
reconsider. A better solution is required. The better solution involves some,
all, or more of:
E_WARNING
more granularity to the register_globals directive
the file upload changes I mentioned as an aside
Cheers
--
Phil Driscoll
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
On Sat, 28 Jul 2001, Zeev Suraski wrote: BTW, I'm just being argumentative here. I personally think that having E_NOTICE on is a very good idea, and that apps should be E_NOTICE-clean. A great deal of PHP programmers will not agree with me, though, so I haven't made up my mind on whether I support changing this default or not. Consider it this way: If an user decides to use my library that is E_NOTICE clean and doesn't have E_NOTICE, what happens? If I decide to use a library that isn't E_NOTICE clean and I have E_NOTICE, what happens? The main issue here from my point of view is interoperation and distribution of software. 2. PHP, with register_globals=on, mixes information coming from the user with information coming from code written by the developer, to a degree where it's impossible to differentiate between the two. Given problem #1, this often leads to security problems. As long as we have a small quantity of small programs and libraries with minor distribution, the maintainance effort of obfuscated code is not vast, and thus flexibility may be default, and perhaps the primary aim. As software written in PHP grows in popularity and the codebase itself grows in size, maintainance becomes harder. Thus I think that a clear message from the developers - whether it's E_NOTICE or register_globals or an open letter called Code Together - that states we are concerned that it's becoming increasingly hard to incorporate large codebases together without compromising stability and security is in my opinion in place. But that's of course only me. Zeev -- -- Heikki Korpela -- [EMAIL PROTECTED] -- http://iki.fi/heko/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] 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 [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
Hey, I thought of an idea yesterday which could make everyone happy. In the default php.ini we set the register_globals to a new value unset. If PHP runs with this INI value it will display a page telling you that you need to define the register_globals option in your php.ini and explains the pros/cons security concerns involved (IMO we should recommend register_globals=off). This way we won't break existing sites which already have php.ini and we have an easy way to feed new users w/ the required information. Of course, I still think we should think of a nicer way to access form variables such as $_FORM[] in order to make it easier for the developer. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
Björn Schotte wrote: * Rasmus Lerdorf wrote: significantly more secure PHP scripts out there. It will simply cause scripts to break in non-obvious ways and the knee-jerk fix will be to swear at those annoying PHP folks and then turn register_globals on, or they will do something like: foreach($HTTP_POST_VARS as $key=$val) $$key = $val; foreach($HTTP_GET_VARS as $key=$val) $$key = $val; foreach($HTTP_COOKIE_VARS as $key=$val) $$key = $val; I fully agree here with Rasmus and I also think this will be the workaround for most people -- if one _does_ care about security, he even knows what and how to do nowadays. I don't think turning register_globals to off will evangelize people to develop more secure scripts/applications. We could at least educate people about extract(). :-P - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
On Saturday, July 28, 2001, at 12:52 PM, Zeev Suraski wrote: At 06:01 28/07/2001, Phil Driscoll wrote: I and no doubt thousands of others will turn register_globals on because it gives much more readable code, much less typing and does not IMHO add one jot to the security of my applications. I have no doubt that thousands would turn it back on. I can't do anything about it, and as I said numerous times in numerous metaphors, I'm quite alright with that. I have roughly 2,000 files to fix before I can use it with my biggest client :-) I also can't imagine people avoiding PHP because variables are accessed using $_FORM['foo'], instead of $foo. People are not *THAT* dumb or lazy. Discussing this issue in the OSCon, Rasmus claimed that right now he can teach PHP to a monkey in 3 hours, and he wouldn't want to be limited only to smart Gorillas in the future. I firmly believe that if a monkey can figure out $foo, $_FORM['foo'] is not going to be the showstopper. Well, there's two *new* learning curves for the never-programmed-before user (monkey?). 1. Understanding arrays. The newest of the newbies are still trying to grok strings, and concepts like get or post. 2. They have almost no examples, whatsoever, to use, for learning how to work with variables in this manner. Both of these issues, combined, increase the monkey factor. Most online and printed tutorials available do not use HTTP_*_VARS (or any future TBI vars shorthand). The example code, all over php.net and zend.com, does not use it. Even if we encourage them to consider it the right thing to do, they don't really know how to go about doing it. I went to google.com, and typed in PHP tutorials,and started looking around... http://hotwired.lycos.com/webmonkey/99/21/index2a.html - Explains HTTP_POST_VARS, but doesn't use it. http://www.devshed.com/Server_Side/PHP/ - Many tutorials, looked at a few, none used it. http://www.linuxguruz.org/z.php - Many tutorials, looked at a few, none used it. http://www.phpdeveloper.org/ - Many tutorials, looked at a few, none used it. I think, perhaps, that this is one of the reasons that so much of the PHP codebase isn't usable with register_globals = off. The learning curve is steep, because it's basically undocumented, in terms of tutorials, examples, downloadable snippets/functions, etc. So we have a chicken/egg problem, where the new monkey has to make a big jump, and use a relatively hidden method of acccessing variables, because almost every tutorial on PHP is wrong. Even the smart gorillas, (the ones writing the tutorials), aren't using it, probably because they never learned how/why to use it.. If we can fix #2, #1 may not require as much effort. As it currently stands, if would be akin to releasing a version of PHP where we suddenly required them (by default, disable if needed) to change every variable they used from $foo to %[foo]. So, beyond my normal ramble: If we were to do this, we might want to start by putting examples in place, if only to show users _how_ to do it. Even if we don't, we still need to start populating examples, if only to show users how they _can_ work with register globals= off. -Ronabop --2D426F70|759328624|00101101011001100111 [EMAIL PROTECTED], 520-326-6109, http://www.opus1.com/ron/ The opinions expressed in this email are not necessarily those of myself, my employers, or any of the other little voices in my head. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
At 08:48 26/07/2001, Rasmus Lerdorf wrote: Just replace your if ($ok) with if (!empty($ok)), and you have a perfect exploitable code that produces no warnings. But in this case someone has gone to the trouble to figure out what empty() does. And generally they use empty() on things that come from the user anyway. I don't think I have ever seen people use empty() to check to see if they themselves have set an internal variable to something. I have... And quite a lot use isset(), which is much more common and popular than empty(). My guess is that we're dealing with a fairly big number of users/scripts here, which are exploitable even though they're 'clean' scripts with no warnings. I'm all in favour of turning E_NOTICE's on (I was since day one and so was Andi, but back then, most people supported the 'loose' behavior of PHP/FI 2 as a default, and leave E_NOTICEs as an option you have to explicitly turn on). Right, but I gave a more specific example - HTTPS, which doesn't always exist, and its very existence implies something. Not all variables are exploitable, perhaps even most aren't, but many are. Don't people use $SERVER_PORT for this? Would seem to make more sense. But sure, there may be a few variables like this. Yes, it was just an example. I know at least one script in zend.com which uses HTTPS that I came across a while ago, so such cases definitely exist. They're trivial to come up with; Pretty much any good code (E_NOTICE free) that doesn't take into account the fact that variables can pop out of nowhere into your global namespace is exploitable. I still think that turning on E_NOTICE by default is a good first step that we can take right away without waiting for a 4.1 and adding more emphasis to the documentation about these issues. With the E_NOTICE people at least get a warning and a line number and most apps will still work, they will just look very ugly forcing people to go and address the warnings. Turning off register_globals will simply break the applications with absolutely no hint as to why the application was broken and the end result will be that people simply turn register_globals back on to get things to work. I actually think that turning E_NOTICE on is going to have a huge effect on a mind boggling number of scripts, probably on the same order of magnitude as setting register_globals to off (probably less, but not that much less). I think that unless we explain explicitly and vocally why we're making these changes (register_globals and/or error level), people will just reconfigure php.ini to the old settings - I don't think they'll start running after new E_NOTICE's they suddenly get after upgrading, unless they'd know they have a good reason to. I think that new PHP installations should come with register_globals set to off. Instead of php.ini-dist and php.ini-optimized, we should probably have php.ini-recommended, which would be the default installed file (assuming there's no php.ini to begin with), and php.ini-compat, which would be what php.ini-dist is today. No doubt, this would cause many (perhaps even most) PHP applications out there not to install out of the box, but I think that setting register_globals off is a pretty pressing matter, and without some pain (i.e., forcing app authors to update their apps to work with the track_vars arrays) we won't get anywhere. The way I think we should go about this is: (a) Improve the accessibility of the track vars array by shortening their names to $_GET[], $_POST[], etc. and possibly making them implicitly available inside functions. This can be done relatively quickly. (b) Get the word out that as of PHP 4.0.8, register_globals will be off, so that app authors will have a chance to fix their apps. (c) Release 4.0.7 with the new improved track vars, but with register_globals still set to on (d) Release 4.0.8 with register_globals set to off We can (and probably should) make the E_NOTICE change at the same time. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
At 08:32 7/27/2001, Zeev Suraski wrote the following: -- Zeev, while I'll applaud to the changes you propose, I suggest this happens in 4.1. I know, this is really a cosmetic change only, and doesn't justify the bump from the perspective of the PHP developers, but is a major one from the perspective of a PHP user. Defaulting error_reporting to E_ALL, and turning register_globals off means 99% percent of current applications won't work, and given the current behavior of zend_error(), where PHP basically reports bogus line numbers (http://www.php.net/bugs.php?id=1225) this is really hard to get around. With 4.1, it'll be clear that a massive change is coming. I'd vote for 4.7 (current state of things) - 4.1 (register_globals off, error_reporting E_ALL). Other than that, hip hip hurray!!! The way I think we should go about this is: (a) Improve the accessibility of the track vars array by shortening their names to $_GET[], $_POST[], etc. and possibly making them implicitly available inside functions. This can be done relatively quickly. (b) Get the word out that as of PHP 4.0.8, register_globals will be off, so that app authors will have a chance to fix their apps. (c) Release 4.0.7 with the new improved track vars, but with register_globals still set to on (d) Release 4.0.8 with register_globals set to off We can (and probably should) make the E_NOTICE change at the same time. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] --end of quote-- [EMAIL PROTECTED] - And the eyes of them both were opened and they saw that their files were world readable and writable, so they chmoded 600 their files. - Book of Installation chapt 3 sec 7 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
Well, we actually could just bump the version number to 4.1.0 for these changes alone. I don't think we should wait for *any* of the other changes that people had in mind for a major or semi major version, but bumping the number to 4.1.0 instead of staying at 4.0.8 is probably a good idea. Zeev At 23:56 26/07/2001, Cynic wrote: At 08:32 7/27/2001, Zeev Suraski wrote the following: -- Zeev, while I'll applaud to the changes you propose, I suggest this happens in 4.1. I know, this is really a cosmetic change only, and doesn't justify the bump from the perspective of the PHP developers, but is a major one from the perspective of a PHP user. Defaulting error_reporting to E_ALL, and turning register_globals off means 99% percent of current applications won't work, and given the current behavior of zend_error(), where PHP basically reports bogus line numbers (http://www.php.net/bugs.php?id=1225) this is really hard to get around. With 4.1, it'll be clear that a massive change is coming. I'd vote for 4.7 (current state of things) - 4.1 (register_globals off, error_reporting E_ALL). Other than that, hip hip hurray!!! The way I think we should go about this is: (a) Improve the accessibility of the track vars array by shortening their names to $_GET[], $_POST[], etc. and possibly making them implicitly available inside functions. This can be done relatively quickly. (b) Get the word out that as of PHP 4.0.8, register_globals will be off, so that app authors will have a chance to fix their apps. (c) Release 4.0.7 with the new improved track vars, but with register_globals still set to on (d) Release 4.0.8 with register_globals set to off We can (and probably should) make the E_NOTICE change at the same time. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] --end of quote-- [EMAIL PROTECTED] - And the eyes of them both were opened and they saw that their files were world readable and writable, so they chmoded 600 their files. - Book of Installation chapt 3 sec 7 -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
On Thu, 26 Jul 2001, Zeev Suraski wrote: But in this case someone has gone to the trouble to figure out what empty() does. And generally they use empty() on things that come from the user anyway. I don't think I have ever seen people use empty() to check to see if they themselves have set an internal variable to something. I have... And quite a lot use isset(), which is much more common and popular than empty(). I use both isset() and empty() in hundreds of lines of code that check my own internally defined structures, such as predefined arrays that define behaviour of the code. I actually think that turning E_NOTICE on is going to have a huge effect on a mind boggling number of scripts, probably on the same order of magnitude as setting register_globals to off (probably less, but not that much less). One major problem I'm currently having is that I like to reuse other people's PHP code if any is available, and I have to hack up a horrible number of directory- and virtual host-specific error_reporting values because the code otherwise generates megabytes of log over a very short while. This makes it extremely hard to maintain a codebase that uses both our own and others' code where our code is strictly developed against E_NOTICE and others' will have to either be reviewed thoroughly or constrained in a shell where different rules apply. I've been told that E_NOTICE generates warnings that you would have to bypass by making things more complicately and that this would hurt one of the greatest advantages of the language: flexibility. This does, of course, hold some truth, but I think that time and experience has shown that this specific flexibility (E_NOTICE and register_globals) causes too much damage and has too many security implications to be left as is. Unexperienced programmers should be given defaults that guide them in a right direction with good programming practices, and leave the advanced flexibility options to more experienced programmers. No doubt, this would cause many (perhaps even most) PHP applications out there not to install out of the box, but I think that setting register_globals off is a pretty pressing matter, and without some pain (i.e., forcing app authors to update their apps to work with the track_vars arrays) we won't get anywhere. Maintaining backward compatibility at all costs has made Perl what it is today. I've been happy that PHP has this far not taken this matter to such limits. Zeev -- -- Heikki Korpela -- [EMAIL PROTECTED] -- http://iki.fi/heko/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] Security Issues
accept_parameters($user_string); // or something similar register_globals off. $user_string=$HTTP_POST_VARS[user_string]; This accomplishes the same thing as your example, and doesn't introduce any new syntax... I don't really see the advantage of the accept_parameters idea. Well, the programmer doesn't need to know if it was introduced by POST or GET or whatever, and will be made to think about what parameters he/she is accepting... thereby making him aware of the security issues. Plus, it looks better :-) (yeah I know, subjective...) Cheerio, Marc. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
At 08:48 26/07/2001, Rasmus Lerdorf wrote: Just replace your if ($ok) with if (!empty($ok)), and you have a perfect exploitable code that produces no warnings. But in this case someone has gone to the trouble to figure out what empty() does. And generally they use empty() on things that come from the user anyway. I don't think I have ever seen people use empty() to check to see if they themselves have set an internal variable to something. I have... And quite a lot use isset(), which is much more common and popular than empty(). My guess is that we're dealing with a fairly big number of users/scripts here, which are exploitable even though they're 'clean' scripts with no warnings. I'm all in favour of turning E_NOTICE's on (I was since day one and so was Andi, but back then, most people supported the 'loose' behavior of PHP/FI 2 as a default, and leave E_NOTICEs as an option you have to explicitly turn on). I think you missed my point. People use empty() and isset() on a variable to check to see if that variable was set by the user. As such that variable is unclean and whether it came in via register_globals or not is quite irrelevant. If it is unclean it is unclean. It doesn't matter at all which mechanism (GET/POST/COOKIE) populated the data from a security perspective. I actually think that turning E_NOTICE on is going to have a huge effect on a mind boggling number of scripts, probably on the same order of magnitude as setting register_globals to off (probably less, but not that much less). I think that unless we explain explicitly and vocally why we're making these changes (register_globals and/or error level), people will just reconfigure php.ini to the old settings - I don't think they'll start running after new E_NOTICE's they suddenly get after upgrading, unless they'd know they have a good reason to. Baby-steps are needed for changes like this. We can get away with the E_NOTICE change I think. The register_globals change is much too drastic and it changes the basic nature of the language. There are plenty of people using PHP today who have no clue what an array is. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
At 10:35 7/27/2001, Rasmus Lerdorf wrote the following: -- I actually think that turning E_NOTICE on is going to have a huge effect on a mind boggling number of scripts, probably on the same order of magnitude as setting register_globals to off (probably less, but not that much less). I think that unless we explain explicitly and vocally why we're making these changes (register_globals and/or error level), people will just reconfigure php.ini to the old settings - I don't think they'll start running after new E_NOTICE's they suddenly get after upgrading, unless they'd know they have a good reason to. Baby-steps are needed for changes like this. We can get away with the E_NOTICE change I think. The register_globals change is much too drastic and it changes the basic nature of the language. There are plenty of people using PHP today who have no clue what an array is. This may be a stupid idea, but... When the code is ready for 4.0.7, release it as 4.0.7 with the first step of the changes, whatever it is, AND as 4.1.0 with all the changes you want. 4.0.8 would turn the screw some more (also released as 4.1.1, no changes to php.ini required in that branch). Finally, when the configurations get in sync, release the code as 4.1.x only. [EMAIL PROTECTED] - And the eyes of them both were opened and they saw that their files were world readable and writable, so they chmoded 600 their files. - Book of Installation chapt 3 sec 7 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
At 01:35 27/07/2001, Rasmus Lerdorf wrote: I think you missed my point. People use empty() and isset() on a variable to check to see if that variable was set by the user. As such that variable is unclean and whether it came in via register_globals or not is quite irrelevant. If it is unclean it is unclean. It doesn't matter at all which mechanism (GET/POST/COOKIE) populated the data from a security perspective. I got your point, but I disagree on it. I think that lots of users use isset() for implementing the same logic you demonstrated in your example, only in a clean, E_NOTICE-free way. I know I used to do that, Heikki says he does, and my assumption is that it's a very common practice. I actually think that turning E_NOTICE on is going to have a huge effect on a mind boggling number of scripts, probably on the same order of magnitude as setting register_globals to off (probably less, but not that much less). I think that unless we explain explicitly and vocally why we're making these changes (register_globals and/or error level), people will just reconfigure php.ini to the old settings - I don't think they'll start running after new E_NOTICE's they suddenly get after upgrading, unless they'd know they have a good reason to. Baby-steps are needed for changes like this. We can get away with the E_NOTICE change I think. The register_globals change is much too drastic and it changes the basic nature of the language. There are plenty of people using PHP today who have no clue what an array is. I respectfully disagree :) I think this issue is critical, and the way we handle it would show a lot on how serious we (less important) and PHP (more important) are considered. In this case, making decision according to the least common denominator doesn't make since IMHO, and we should derive our decision from a security/reliability perspective, and not the newbie-friendliness perspective. Zeev Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
At 01:35 27/07/2001, Rasmus Lerdorf wrote: I think you missed my point. People use empty() and isset() on a variable to check to see if that variable was set by the user. As such that variable is unclean and whether it came in via register_globals or not is quite irrelevant. If it is unclean it is unclean. It doesn't matter at all which mechanism (GET/POST/COOKIE) populated the data from a security perspective. I got your point, but I disagree on it. I think that lots of users use isset() for implementing the same logic you demonstrated in your example, only in a clean, E_NOTICE-free way. I know I used to do that, Heikki says he does, and my assumption is that it's a very common practice. I think that assumption is wrong. And also your previous assumption that the E_ALL error_reporting level change would break just as many scripts as the register_globals change. The way to figure this out would be to actually go and check instead of making such broad assumptions. Take the first 25 projects listed at php.net/projects.php, install them and run them with E_ALL and then with register_globals=off and see how they do. It's almost 3am, and I am rather tired, but I grabbed the first one listed and installed it. Then clicked through it and did various things. So here is my entry for it if someone wants to actually take on this task of auditing the first 25 (or more) projects: Adaptive Website Framework URL: http://www.liquidbytes.net/index.php?id=143subject=/awf/ Worked perfectly without even a single warning when run under with E_ALL, but failed to work at all with register_globals = Off. A look through the code revealed decent checking and isset() consistently used on user-supplied data. Baby-steps are needed for changes like this. We can get away with the E_NOTICE change I think. The register_globals change is much too drastic and it changes the basic nature of the language. There are plenty of people using PHP today who have no clue what an array is. I respectfully disagree :) I think this issue is critical, and the way we handle it would show a lot on how serious we (less important) and PHP (more important) are considered. In this case, making decision according to the least common denominator doesn't make since IMHO, and we should derive our decision from a security/reliability perspective, and not the newbie-friendliness perspective. Sure the issue is critical. I have never said otherwise. Security is critical. My disagreement is in how to help users write more secure scripts. I do not agree that turning off register_globals will result in significantly more secure PHP scripts out there. It will simply cause scripts to break in non-obvious ways and the knee-jerk fix will be to swear at those annoying PHP folks and then turn register_globals on, or they will do something like: foreach($HTTP_POST_VARS as $key=$val) $$key = $val; foreach($HTTP_GET_VARS as $key=$val) $$key = $val; foreach($HTTP_COOKIE_VARS as $key=$val) $$key = $val; And yes, I have run across code like this. Assuming E_ALL, register_globals only fixes the case where users forget to initialize a variable and at the same time they use isset() or empty() to check to see if they have set that variable. I contend that the instances of this are actually very rare and do not warrant the massive breakage a change to the default register_globals change will cause. And we haven't even explored alternative approaches to perhaps help users catch this particular situation. I could see a some sort of audit mode or lint that produced a little report of external variables (anything checked/used with or without isset/empty before they are assigned), internal variables, constants and perhaps unused variables. Or as has been brought up a few times, something similar to Perl's taint mode. Tough to do in our architecture, sure, but simply changing things without exploring alternatives or researching the real state of the problem doesn't make any sense to me. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
* Rasmus Lerdorf wrote: significantly more secure PHP scripts out there. It will simply cause scripts to break in non-obvious ways and the knee-jerk fix will be to swear at those annoying PHP folks and then turn register_globals on, or they will do something like: foreach($HTTP_POST_VARS as $key=$val) $$key = $val; foreach($HTTP_GET_VARS as $key=$val) $$key = $val; foreach($HTTP_COOKIE_VARS as $key=$val) $$key = $val; I fully agree here with Rasmus and I also think this will be the workaround for most people -- if one _does_ care about security, he even knows what and how to do nowadays. I don't think turning register_globals to off will evangelize people to develop more secure scripts/applications. -- PHP Schulungen und| International PHP Conference Schulungsmaterial:| 05. - 07.11.2001 http://thinkphp.de/ | Astron Hotel, Frankfurt http://rent-a-phpwizard.de/schulungen.php | http://www.php-kongress.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
I fully agree here with Rasmus and I also think this will be the workaround for most people -- if one _does_ care about security, he even knows what and how to do nowadays. I don't think turning register_globals to off will evangelize people to develop more secure scripts/applications. thats it. what we could do to make people to write more secure script is: - telling them to do so, - telling them what is insecure - telling them why something is insecure - writing a special type of documentation, about how to write secure scripts maybe we could do something like a php-security-central, where everyone who wants to learn about security could read this kind of documenation, a special mailinglist where issues about security of php-applications is discussed, etc. you cant fight security holes without knowing what the hole is, and you cant make others writing secure apps without teaching them about how this works, we shouldnt change php, we should give more information about this problems, so everyone is able to learn how to avoid them. - Peter -- *ZIMT - where PHP meets needs* Homepage: www.cyberfly.net - [EMAIL PROTECTED] PHP Usergroups: www.phpug.de - [EMAIL PROTECTED] Just for Fun: www.fist-center.de - [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
At 03:09 27/07/2001, Rasmus Lerdorf wrote: At 01:35 27/07/2001, Rasmus Lerdorf wrote: I think you missed my point. People use empty() and isset() on a variable to check to see if that variable was set by the user. As such that variable is unclean and whether it came in via register_globals or not is quite irrelevant. If it is unclean it is unclean. It doesn't matter at all which mechanism (GET/POST/COOKIE) populated the data from a security perspective. I got your point, but I disagree on it. I think that lots of users use isset() for implementing the same logic you demonstrated in your example, only in a clean, E_NOTICE-free way. I know I used to do that, Heikki says he does, and my assumption is that it's a very common practice. I think that assumption is wrong. And also your previous assumption that the E_ALL error_reporting level change would break just as many scripts as the register_globals change. I didn't say just as many, but same order of magnitude. Most of the scripts I came across in the past 4 years would not run properly with E_NOTICE's turned on. Even if it's just 20% of the scripts, it's still the same order of magnitude. No doubt, the number would be less, since turning register_globals off would break virtually all apps out there today, but it'd be a major blow still. I argue that the security benefit from it is much smaller than doing the real thing, which is turning register_globals off. The way to figure this out would be to actually go and check instead of making such broad assumptions. Take the first 25 projects listed at php.net/projects.php, install them and run them with E_ALL and then with register_globals=off and see how they do. It's almost 3am, and I am rather tired, but I grabbed the first one listed and installed it. Then clicked through it and did various things. So here is my entry for it if someone wants to actually take on this task of auditing the first 25 (or more) projects: I think that's a good idea, but given the fact that the advisory mentioned exploits for some very common apps means that either - These apps are not E_NOTICE 'safe', otherwise, these issues would have been resolved or - These issues would not have been solved by turning E_NOTICE's on Sure the issue is critical. I have never said otherwise. Security is critical. My disagreement is in how to help users write more secure scripts. I do not agree that turning off register_globals will result in significantly more secure PHP scripts out there. I think that's the source of our disagreement - I think it's going to push the base security level of PHP applications a few notches all by itself. It will simply cause scripts to break in non-obvious ways and the knee-jerk fix will be to swear at those annoying PHP folks and then turn register_globals on, or they will do something like: foreach($HTTP_POST_VARS as $key=$val) $$key = $val; foreach($HTTP_GET_VARS as $key=$val) $$key = $val; foreach($HTTP_COOKIE_VARS as $key=$val) $$key = $val; And yes, I have run across code like this. If somebody wants to shoot himself in the head, he's quite welcome to do it. But when you hand a gun over to somebody, you don't point it at his head, but safely hand it to his hands. What he does afterwards is his own business (assuming he doesn't come after you :) Assuming E_ALL, register_globals only fixes the case where users forget to initialize a variable and at the same time they use isset() or empty() to check to see if they have set that variable. I contend that the instances of this are actually very rare and do not warrant the massive breakage a change to the default register_globals change will cause. See my argument above. The most common PHP apps were exploitable, by exploits which by definition would have either not been resolved by turning on E_NOTICE's, or they're E_NOTICE-unsafe. In addition, having seen quite a bit of PHP code that does use this kind of methods (which are basically the correct development methods in PHP when you have E_NOTICE's set to on, which good coders do), I think that it's crucial that we give an answer to this audience as well. Again, even if it's just 20% of the cases, or even 2% of the cases, if it leads to security issues, that's an ENORMOUS amount. And we haven't even explored alternative approaches to perhaps help users catch this particular situation. I could see a some sort of audit mode or lint that produced a little report of external variables (anything checked/used with or without isset/empty before they are assigned), internal variables, constants and perhaps unused variables. I don't think that's related. register_globals encourages insecure coding, and should be phased out as quickly as possible, regardless of whatever other security analysis methods we may have or add in the future. Or as has been brought up a few times, something similar to Perl's taint mode. Tough to do in
Re: [PHP-DEV] Security Issues
Guys, Please read the advisory. You simply can't say that register_globals=off wouldn't have resulted in more secure apps, because there are *3* examples (or more, I don't remember) there of applications that would have not been exploitable had register_globals=on was in effect! Unless we make the very unlikely assumption that these are the only apps that were vulnerable (and from what I understand in the advisory, pretty much any app they checked was vulnerable at one point or another), saying that setting register_globals to off is going to improve security is pretty much a fact, and not an opinion. Zeev At 03:15 27/07/2001, Björn Schotte wrote: * Rasmus Lerdorf wrote: significantly more secure PHP scripts out there. It will simply cause scripts to break in non-obvious ways and the knee-jerk fix will be to swear at those annoying PHP folks and then turn register_globals on, or they will do something like: foreach($HTTP_POST_VARS as $key=$val) $$key = $val; foreach($HTTP_GET_VARS as $key=$val) $$key = $val; foreach($HTTP_COOKIE_VARS as $key=$val) $$key = $val; I fully agree here with Rasmus and I also think this will be the workaround for most people -- if one _does_ care about security, he even knows what and how to do nowadays. I don't think turning register_globals to off will evangelize people to develop more secure scripts/applications. -- PHP Schulungen und| International PHP Conference Schulungsmaterial:| 05. - 07.11.2001 http://thinkphp.de/ | Astron Hotel, Frankfurt http://rent-a-phpwizard.de/schulungen.php | http://www.php-kongress.de/ -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
At 20:22 02/01/1999, Peter Petermann wrote: I fully agree here with Rasmus and I also think this will be the workaround for most people -- if one _does_ care about security, he even knows what and how to do nowadays. I don't think turning register_globals to off will evangelize people to develop more secure scripts/applications. thats it. what we could do to make people to write more secure script is: - telling them to do so, - telling them what is insecure - telling them why something is insecure - writing a special type of documentation, about how to write secure scripts These methods are flawed by definition, since they assume that you'd be able to communicate to all, or even just most users. Are they good things to do? Definitely. Are they enough? Not really, because as the advisory claims, if the language encourages you to write insecure code (assuming you don't read 'general' documentation, which is very common), the language is at fault. Will the applications of such people always be secure now that register_globals is off? Of course not, but it's definitely going to knock down a huge amount of exploits in their apps, and there are good chances that these would be the only exploits in it. maybe we could do something like a php-security-central, where everyone who wants to learn about security could read this kind of documenation, a special mailinglist where issues about security of php-applications is discussed, etc. you cant fight security holes without knowing what the hole is, and you cant make others writing secure apps without teaching them about how this works, we shouldnt change php, we should give more information about this problems, so everyone is able to learn how to avoid them. The way I see it, register_globals=on is pretty much like a swiss cheese factory as far as it comes to security holes. No php-security-central is going to help here, and closing this factory down *is* going to help a lot. This doesn't come to say it'd eliminate all security holes out there, obviously, just a great deal of them. Again, I want to say that there are some good ideas being raised in this discussion, but given the fact (or my view, rather) that register_globals=on is *SUCH* a bad thing, none of them has too much to do with it. They're good and should be discussed regardless of this issue, which should be resolved specifically, and in my opinion, by changing the default. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
At 03:36 27/07/2001, Zeev Suraski wrote: Guys, Please read the advisory. You simply can't say that register_globals=off wouldn't have resulted in more secure apps, because there are *3* examples (or more, I don't remember) there of applications that would have not been exploitable had register_globals=on was in effect! ... had register_globals=on not be in effect 3:45am, signing off for today :) Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
Peter Petermann wrote: I fully agree here with Rasmus and I also think this will be the workaround for most people -- if one _does_ care about security, he even knows what and how to do nowadays. I don't think turning register_globals to off will evangelize people to develop more secure scripts/applications. thats it. I see your point, but I disagree. Register_globals is a lanugage-feature which can result in security-gaps when people don't initialize their variables. It's a common mistake, a pitfall, especially for beginners, that could be resolved by turning register_globals off. There's a lot of beginners using PHP, and this wouldn't only make their applications a little more secure (just a little, but better than nothing), it will also teach them manners. Using $HTTP_*_VARS ist cleaner, IMO. what we could do to make people to write more secure script is: - telling them to do so, - telling them what is insecure - telling them why something is insecure - writing a special type of documentation, about how to write secure scripts Please, can you say beginner? Once people read that kind of stuff, they are not beginners any more. They aren't the problem. You can't force people to write secure applications, but you can make it easier. regards Wagner -- Madness takes its toll. Please have exact change. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
register_globals is off? Of course not, but it's definitely going to knock down a huge amount of exploits in their apps, and there are good chances that these would be the only exploits in it. as rasmus wrote, this would only result in users using foreach to do that. you cant fight security holes without knowing what the hole is, and you cant make others writing secure apps without teaching them about how this works, we shouldnt change php, we should give more information about this problems, so everyone is able to learn how to avoid them. The way I see it, register_globals=on is pretty much like a swiss cheese factory as far as it comes to security holes. No php-security-central is going to help here, and closing this factory down *is* going to help a lot. This doesn't come to say it'd eliminate all security holes out there, obviously, just a great deal of them. discussion, but given the fact (or my view, rather) that register_globals=on is *SUCH* a bad thing, none of them has too much to do with it. They're good and should be discussed regardless of this issue, which should be resolved specifically, and in my opinion, by changing the default. as long there are peoples driving car, without knowing howto drive, they are dangerous for all of us. but do you think driving car should no longer be allowed? you cant make mercedes, porsche etc. responsible for people killed by people who cant drive but did. i think we are talking about something like this right now, the language is not responsible for users, who dont know about security and, PHP is written in C, so maybe C should be changed to make it impossible to create in php something like register_globals=on... this is what you say, if you blame the language for that php is just a language, if people are not able to use it the right way it is nothing wrong with the language, it is about the people -- *ZIMT - where PHP meets needs* Homepage: www.cyberfly.net - [EMAIL PROTECTED] PHP Usergroups: www.phpug.de - [EMAIL PROTECTED] Just for Fun: www.fist-center.de - [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
what we could do to make people to write more secure script is: - telling them to do so, - telling them what is insecure - telling them why something is insecure - writing a special type of documentation, about how to write secure scripts Please, can you say beginner? Once people read that kind of stuff, they are not beginners any more. They aren't the problem. ive seen a lot of professionells who dont care about security, and i have seen beginner who do. You can't force people to write secure applications, but you can make it easier. i dont think it is easier to write more secure applications with turning a feature of. - Peter -- *ZIMT - where PHP meets needs* Homepage: www.cyberfly.net - [EMAIL PROTECTED] PHP Usergroups: www.phpug.de - [EMAIL PROTECTED] Just for Fun: www.fist-center.de - [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
At 20:53 02/01/1999, Peter Petermann wrote: register_globals is off? Of course not, but it's definitely going to knock down a huge amount of exploits in their apps, and there are good chances that these would be the only exploits in it. as rasmus wrote, this would only result in users using foreach to do that. Two things: (a) How about just setting register_globals to on? We're not talking about taking this option away, for now, just turn it off by default. (b) As I said, if someone wants to use a gun to shoot himself in the head, he's welcome to do so. The least we could do is hand him the gun safely pointed in the other direction, and not point it to his brain. as long there are peoples driving car, without knowing howto drive, they are dangerous for all of us. but do you think driving car should no longer be allowed? you cant make mercedes, porsche etc. responsible for people killed by people who cant drive but did. You argue that having a car with no brakes and just a better airbag is acceptable? Peter, we're *NOT* talking about absolute things in here. Of course, using your example, the only way to protect users, is by preventing them from writing scripts. That's not the issue here. The issue here is similar to giving them a car without brakes, and expecting them to handle it. Can you blame the driver for the accident with a brakeless car? It'd be quite dumb... Shipping PHP with register_globals set to on is equivalent to shipping cars without brakes. You hope that the user would be bright enough to install brakes, or use all sorts of advanced preventive measures like airbags, but the right thing to i think we are talking about something like this right now, the language is not responsible for users, who dont know about security and, PHP is written in C, so maybe C should be changed to make it impossible to create in php something like register_globals=on... this is what you say, if you blame the language for that php is just a language, if people are not able to use it the right way it is nothing wrong with the language, it is about the people I strongly suspect you haven't read the advisory, because it deals exactly with these issues. In a perfect world, we'd just have something like security=on that'd handle all of the possible security issues. Since non of us is holding his breath for such a world, we should try to provide a system that at least isn't prone to common, repeated and innocent looking security bugs. PHP with register_globals=on is. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
At 20:58 02/01/1999, Peter Petermann wrote: i dont think it is easier to write more secure applications with turning a feature of. Read the advisory before your next post or I'll have Kristian smack you the next time he sees you! :) Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
* Zeev Suraski wrote: equivalent to shipping cars without brakes. You hope that the user would be bright enough to install brakes, Hoping that is not enough. If you really change the behaviour to ship PHP with register_globals to off, then I suggest you should also ship some README_Security or something similar where Kris writes a nice tutorial about writing secure PHP applications. (This README_Security should also be inserted into the Manual and all places where it makes sense) Also, before doing make install a less README_Security should be done by the makefile. -- PHP Schulungen und| International PHP Conference Schulungsmaterial:| 05. - 07.11.2001 http://thinkphp.de/ | Astron Hotel, Frankfurt http://rent-a-phpwizard.de/schulungen.php | http://www.php-kongress.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
Peter Petermann wrote: i dont think it is easier to write more secure applications with turning a feature of. In this particular case, it would. There are several reported cases of security-holes caused by this feature. Without it, there would be fewer insecure PHP-applications out there. Thats a fact. Thats the past. Now let's talk about the future. Turning register_globals off won't fix old code. If code relies on register_globals, people will fix it with foreach (Rasmus' example), or by turning register_globals on. But that's not the point. The point is that people who don't care about security or coding style (beginners or professionals, doesn't really matter) are less likely to write insecure code, because there's one mistake less that they can make. As long as they stick to the defaults, anyway. regards Wagner -- Madness takes its toll. Please have exact change. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] Security Issues
Changing to register globals=off surely does very little in
terms of security for the easily fakeable GPC variables.
Maybe not for these variables, but other variables used in your script
cannot be faked by passing them as HTTP_POST_VARS.
e.g., with register_globals=off
if ($HTTP_POST_VARS['user_string'] == 'check_for_security') {
// do something, but be aware of security issues
}
if ($internal_variable == 'whatever') {
// do something, knowing that a user could never have set this
}
The second check is where a lot of scripts are exploitable, I think, if
register_globals=on, because programmers do not expect user-input in this
variable.
Cheerio, Marc.
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
On Friday 27 July 2001 12:51, Marc Boeren wrote:
if ($internal_variable == 'whatever') {
// do something, knowing that a user could never have set this
}
The second check is where a lot of scripts are exploitable, I think, if
register_globals=on, because programmers do not expect user-input in this
variable.
...but will be caught perfectly by E_ALL
--
Phil Driscoll
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
(b) As I said, if someone wants to use a gun to shoot himself in the head, he's welcome to do so. The least we could do is hand him the gun safely pointed in the other direction, and not point it to his brain. we are not talking about people who want to have security holes, we are talking about people who do not know they have.. this is like giving a loaded weapon to someone, dont telling him that he could kill with it. it. Can you blame the driver for the accident with a brakeless car? It'd be quite dumb... Shipping PHP with register_globals set to on is equivalent to shipping cars without brakes. You hope that the user would be bright enough to install brakes, or use all sorts of advanced preventive measures like airbags, but the right thing to well, i think you misunderstood me. we are not talking of a brakeless car, and we are not talking about a language who is not able to be used secure. we are talking about something that has the abilities to be secure, we just need to teach the people how, the same as people need to learn how to drive, without they can start the engine, and dont know how to brake, but the brakes are there! i think we are talking about something like this right now, the language is not responsible for users, who dont know about security and,PHP is written in C, so maybe C should be changed to make it impossible to create in php something like register_globals=on... this is what you say, if you blame the language for that php is just a language, if people are not able to use it the right way it is nothing wrong with the language, it is about the people I strongly suspect you haven't read the advisory, because it deals exactly with these issues. In a perfect world, we'd just have something like security=on that'd handle all of the possible security issues. Since non of us is holding his breath for such a world, we should try to provide a system that at least isn't prone to common, repeated and innocent looking security bugs. PHP with register_globals=on is. i have read the advisory, but i cant agree that register_globals=on is the problem the user, who cant deal with that is the problem php is a language, if people dont secure there applications, they are wrong, not php is. if i give machines to you, allowing you to build cars secure ones, and insecure ones (those without brakes ;) and you build a insecure one, thats not my fault. but if i want to help you, i wouldnt turn of one of the switches you use, and hope you dont use another one for the same, i would teach you how to build the secure cars, how to do crashtests etc. - Peter -- *ZIMT - where PHP meets needs* Homepage: www.cyberfly.net - [EMAIL PROTECTED] PHP Usergroups: www.phpug.de - [EMAIL PROTECTED] Just for Fun: www.fist-center.de - [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
On Fri, 27 Jul 2001, Zeev Suraski wrote:
(a) How about just setting register_globals to on? We're not talking about
taking this option away, for now, just turn it off by default.
(b) As I said, if someone wants to use a gun to shoot himself in the head,
he's welcome to do so. The least we could do is hand him the gun safely
pointed in the other direction, and not point it to his brain.
We know that tricks and complications don't make anything more
secure - quite the contrary, they make the applications more
bug-prone.
We also know that good programming practices and routines help avoid
bugs. Alone, they won't help, but a person who is adviced or even
enforced to apply those practices will usually wonder: huh, why
shouldn't I use tempnam or gets? Hmm, maybe I'll read the manual
page Indirectly, this also leads to changes in attitude as
the programmer starts to realize that the threats he or she is
being warned of are real and not mere paranoia of people encrypting
their swap.
The question here is whether or not register_globals is a trick
or a way to advise people of better practices.
Would anyone like to show me the design that gets innecessarily
('innecessary' meaning 'if the application wasn't well designed
in the first place, it's obvious it should be changed') complicated
when you enforce E_NOTICE and register_globals?
//
Everyone's emphasizing documentation on security concerns. What would
be the first things I'd like to see (or do) tre he possible security
implications for function calls or language structures in the reference
manual, next to their corresponding references. See, for example,
the bugs section of one implementation of the manual page for
mktemp(3):
http://www.openbsd.org/cgi-bin/man.cgi?query=mktempsektion=3
Yes, sure it would be nice if there was a guide to secure programming
in PHP. Oh, but wait... I think there are some; but people don't
necessarily read them. They think that security issues don't concern
them.
--
--
Heikki Korpela -- [EMAIL PROTECTED] -- http://iki.fi/heko/
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
Peter Petermann wrote: I fully agree here with Rasmus and I also think this will be the workaround for most people -- if one _does_ care about security, he even knows what and how to do nowadays. I don't think turning register_globals to off will evangelize people to develop more secure scripts/applications. thats it. I see your point, but I disagree. Register_globals is a lanugage-feature which can result in security-gaps when people don't initialize their variables. It's a common mistake, a pitfall, especially for beginners, that could be resolved by turning register_globals off. And is resolved by turning on E_NOTICE. Please, can you say beginner? Once people read that kind of stuff, they are not beginners any more. They aren't the problem. You can't force people to write secure applications, but you can make it easier. Or you can simply stop these people from using PHP which is another effect turning off register_globals will have. Java does not have this problem because Java is so complex that this same set of users can not program in Java. Fixing this problem by making PHP more complex and eliminating these problem users is a bad idea as far as I am concerned. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
Peter Petermann wrote: i dont think it is easier to write more secure applications with turning a feature of. In this particular case, it would. There are several reported cases of security-holes caused by this feature. Without it, there would be fewer insecure PHP-applications out there. Thats a fact. Thats the past. Now let's talk about the future. Please, everyone keeps stating this and immediately jumping to turning register_globals off as being the one and only solution simply because it is the most obvious solution. Think about whether in each of these cases it would have happened if the developers of the app had developed with E_NOTICE on. In a high number of these cases it probably wouldn't. And if this number is close to 100%, then it would point to the fact that there is another less destructive solution here. This is why I want to go through and investigate existing PHP code and have a look. But that's not the point. The point is that people who don't care about security or coding style (beginners or professionals, doesn't really matter) are less likely to write insecure code, because there's one mistake less that they can make. As long as they stick to the defaults, anyway. And one language less that these people are able to use. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] Security Issues
Is all of this springing from that security advisory that was published a
short while ago?
I remember reading that, and feeling that many of the issues were overblown
(if I'm thinking of the same one).
Also, wasn't that advisory just written by some guy? Its not like W3C is
writing a web security standards document and made an example out of PHP or
something, its just the security suggestions/opinions of some guy.
Seems like a whole lot of trouble (breaking thousands of scripts) -- just to
appease some document by some guy.
Also, about this whole car with no brakes or gun aimed at the head
business. I like the car analogy... and the register_globals=off.
See.. turning register_globals off is like adding a huge brake, and then
hiding the accelerator. For beginner drivers, or existing drivers that are
not up on current events, it will be very hard to get going.
I'd say that leaving register_globals on is *exactly* like a regular car.
Its dangerous, hell yeah. However, as long as you learn how to use it in an
enclosed environment, and practice the safety techniques -- you are not too
much of a danger to others when you get onto the highway.
Same concept applies... if you take a beginner and put them on an enterprise
server writing code that manipulates a DNS file or does updates and deletes
to a crucial database, you are asking for trouble.
Thats why people write simple, inconsequential application as they are
*learning*, and after that have some experience, they should write things
where they can actually hurt someone.
Anyway, thats my .02. I'm done talking about this issue... its a difference
of opinion, which is generally very hard to resolve -- and no amount of
logical dicussion can change the mind of either group.
-Brian T
-Original Message-
From: Zeev Suraski [mailto:[EMAIL PROTECTED]]
Sent: July 25, 2001 6:29 PM
To: Rasmus Lerdorf
Cc: Andy; [EMAIL PROTECTED]
Subject: Re: [PHP-DEV] Security Issues
At 07:31 25/07/2001, Rasmus Lerdorf wrote:
Because not everyone agrees that this is actually highly recommended.
Most third-party PHP code you may want to run will not work very well with
register_globals off. And turning register_globals off isn't actually as
helpful from a security perspective as many people seem to think.
The basic thing it would help would be in cases like this:
?
if($user=='rasmus') {
$ok = true;
}
if($ok) {
... secure code ...
}
?
Here if someone injected ?ok=1 in the URL then the secure code part would
be run regardless of the $user setting. Obviously the fix here is to make
sure that $ok is initialized to false at the top of the script. But since
many people forget to do that, turning off register_globals fixes the
problem.
I tend to agree with the advisory, in the sense that register_globals=on
encourages insecure code, and it would in fact help to disable it by
default. It's true that some (many) people don't understand that they
shouldn't 'trust' any data coming from POST or cookies anymore than they
should trust GET (well, in practice - slightly more, as it takes slightly
more advanced users to work around POST or cookies, than it does to add GET
variables to the URL). However, *lots* of pieces of code, probably even
most of them, are vulnerable to logic bugs because of register_globals set
to on, bugs that would have otherwise not exist. Bugs which occur due to
misunderstanding the 'reliability' of the form data sources are (much) more
rare, and usually, if not always, involve basic misunderstanding of the Web
environment. Security issues that are a result of register_globals=on
often occur even when the user is knowledgeable, and tries to avoid
security bugs. The WTF factor there is pretty high.
The change I would rather see in php.ini would be to have the default
error_level be set to E_ALL because then the above script would generate a
warning complaining about the fact that $ok was not initialized. Since
PHP can determine when variables are not initialized the case for
turning register_globals off in this example is rather weak.
PHP does not require or even encourage initialization of variables -
setting $ok to 1, and then checking it with empty() is considered 'clean'
code, but it'd be equally insecure.
Many people also seem to think that it is somehow more secure if you know
exactly where data is coming from. So that if you use
$HTTP_POST_VARS['var'] then somehow $var is not spoofable because if you
put ?var=foo in the URL it won't affect anything. But injecting variables
into POST or Cookie data is trivial so I don't see this argument holding
much water either.
As I said, it's easy, but it is considerably less easy than it is to add
GET variables. Let alone the fact that we're also dealing with SERVER and
ENV vars, which cannot be injected at all. How about people who check
server variables, such as HTTPS, using isset()? register_globals
Re: [PHP-DEV] Security Issues
On Fri, 27 Jul 2001, Zeev Suraski wrote: It will simply cause scripts to break in non-obvious ways and the knee-jerk fix will be to swear at those annoying PHP folks and then turn register_globals on, or they will do something like: foreach($HTTP_POST_VARS as $key=$val) $$key = $val; foreach($HTTP_GET_VARS as $key=$val) $$key = $val; foreach($HTTP_COOKIE_VARS as $key=$val) $$key = $val; And yes, I have run across code like this. If somebody wants to shoot himself in the head, he's quite welcome to do it. But when you hand a gun over to somebody, you don't point it at his head, but safely hand it to his hands. What he does afterwards is his own business (assuming he doesn't come after you :) I think Rasmus is right. We've been shooting the guy in the head for the last few years while register_globals was/is on. People incorporating other PHP libraries like Horde/PHPLIB (just examples) and what have you, will immediately break, even after they fix their own code, the third party libraries will still be broken. This means that the library maintainers will be under significant pressure to release a patch; fixing the code to use a safer method of accessing user data. My guess is the above patch is what will make it in, not because the guy doesn't understand it's bad, but he was already shot in the head by the default php.ini setting and so he's not really _losing_ anything now. -- John Donagher Application Engineer Intacct Corp. - Powerful Accounting on the Web 408-395-0989 720 University Ave. Los Gatos CA 95032 www.intacct.com Public key available off http://www.keyserver.net Key fingerprint = 4024 DF50 56EE 19A3 258A D628 22DE AD56 EEBE 8DDD -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
I have been watching this thread for too long and I can no longer resist commenting. If a programmer does not initialize SECURE variables properly, he is going to make far worse security decisions in his software. Next thing we are going to hear is that php does not auto TAINT check parsed variables. I personally disagree with making register_globals=off a default. I really don't think it will make that big of a difference, and come on everyone, this is one of the coolest features of php. -Jason - Original Message - From: Rasmus Lerdorf [EMAIL PROTECTED] To: Alexander Wagner [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, July 27, 2001 9:37 AM Subject: Re: [PHP-DEV] Security Issues Peter Petermann wrote: I fully agree here with Rasmus and I also think this will be the workaround for most people -- if one _does_ care about security, he even knows what and how to do nowadays. I don't think turning register_globals to off will evangelize people to develop more secure scripts/applications. thats it. I see your point, but I disagree. Register_globals is a lanugage-feature which can result in security-gaps when people don't initialize their variables. It's a common mistake, a pitfall, especially for beginners, that could be resolved by turning register_globals off. And is resolved by turning on E_NOTICE. Please, can you say beginner? Once people read that kind of stuff, they are not beginners any more. They aren't the problem. You can't force people to write secure applications, but you can make it easier. Or you can simply stop these people from using PHP which is another effect turning off register_globals will have. Java does not have this problem because Java is so complex that this same set of users can not program in Java. Fixing this problem by making PHP more complex and eliminating these problem users is a bad idea as far as I am concerned. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
At 04:33 27/07/2001, Phil Driscoll wrote: I must be much more stupid than I give myself credit for. Changing to register globals=off surely does very little in terms of security for the easily fakeable GPC variables. I can see that for environment variables the picture is slightly different - you do need to be sure that this *really* is an SSL connection etc. Have you read the advisory? That's simply not true. There are two main types of security problems related to this: (a) Ones that originate in the fact that people don't know they mustn't trust any input coming from the user, be it GET, POST or cookies, that they're all insecure (b) Ones that don't, and there are many of them For those of type (a), register_globals being off or on doesn't change much. For (b), it does, big time. I propose the following - which will break *NO* scripts. Examine the environment variable issues such as those which pertain to SSL and then, just as recently happened with the file upload vulnerability, implement some functions which do 'full strength' checking for the user e.g. is_secure_connection() That's the unthorough and prone-to-errors approach. It's like trying to fill each and every hole in a piece of Swiss cheese. Then to address the uninitialised variables issue, modify the error reporting system so that the default setting (E_SECURE) emails warnings and errors to the administrator rather than displaying them in the output. Maybe some other refinement of the technique involving a sensible mixture of display_error, error_reporting, and a new email_errors directive might be better. With this solution, we break no scripts and we encourage more secure programming. So now, tear it to pieces :) It won't really address the issues that were raised in the advisory, will be prone to errors (i.e., it's pretty much impossible for us to think of everything), and I'd argue that it'd be less convenient on the long run, as people know and expect to rely on environment/server variables. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
At 04:48 27/07/2001, Peter Petermann wrote: well, i think you misunderstood me. we are not talking of a brakeless car, and we are not talking about a language who is not able to be used secure. we are talking about something that has the abilities to be secure, we just need to teach the people how, the same as people need to learn how to drive, without they can start the engine, and dont know how to brake, but the brakes are there! We are talking about a brakeless car here. It's not impossible to drive a brakeless car. If you're aware of it, you can probably drive around reasonably, if you pay close attention all the time, and drive slow enough. You may be proficient enough to use the parking-brakes instead too. But it's much less secure by definition. register_globals=off means significantly increased probability for security trouble. It's as simple as that. i have read the advisory, but i cant agree that register_globals=on is the problem the user, who cant deal with that is the problem php is a language, if people dont secure there applications, they are wrong, not php is. That's where I, Kristian, the advisory and others disagree. If a random PHP app you'd pick, even one written by a good coder that is written in a modular and clean way, is likely to have bugs related to this feature, than it means the feature is at fault. In a perfect world, people would be able to work alongside that feature to write secure apps, as it is possible, but it's *DIFFICULT*, and it's non intuitive. Thus, in the average case, it would lead to security bugs. Thus, it's flawed and should be changed. if i give machines to you, allowing you to build cars secure ones, and insecure ones (those without brakes ;) and you build a insecure one, thats not my fault. That's not the case here. Peter, we're not talking about liability concerns. It's not as if we're afraid one of those users would sue us because we provided him with an insecure language. It's about the perception of PHP. If you think that PHP is going to retain a reputation of a good language, when every 2nd PHP application out there ends up having security problems, and when advisories repeatedly find flaws which they, as well as a large number of PHP developers believe to be related to PHP's behavior, you're wrong. This hurts PHP big time. but if i want to help you, i wouldnt turn of one of the switches you use, and hope you dont use another one for the same, i would teach you how to build the secure cars, how to do crashtests etc. That's exactly like providing one with a brakeless car, and investing a huge amount of resources on teaching him how to drive slower and using the parking brakes to achieve equivalent safety. It works, but it's wrong. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
At 07:37 27/07/2001, Rasmus Lerdorf wrote: I see your point, but I disagree. Register_globals is a lanugage-feature which can result in security-gaps when people don't initialize their variables. It's a common mistake, a pitfall, especially for beginners, that could be resolved by turning register_globals off. And is resolved by turning on E_NOTICE. That's simply not true. It can solve it only in a subset of the cases, maybe a fairly large subset, but definitely not anywhere close to 100%. From my experience it'd be perhaps half of the cases, and it would especially be useless with those apps which were written by good coders, that use isset(), and that were written to be E_NOTICE free. Please, can you say beginner? Once people read that kind of stuff, they are not beginners any more. They aren't the problem. You can't force people to write secure applications, but you can make it easier. Or you can simply stop these people from using PHP which is another effect turning off register_globals will have. That's also not true. Is using $foo all that better than $_GET[foo]? I don't think so. As a matter of fact, the 2nd alternative is probably going to be preferred by a fair amount of users, as it's much clearer what you're dealing with. Java does not have this problem because Java is so complex that this same set of users can not program in Java. Fixing this problem by making PHP more complex and eliminating these problem users is a bad idea as far as I am concerned. But it isn't. It's by fixing an inherent design flaw in PHP. The proposed target situation is *NOT* any more difficult to the users than the situation is today. Yes, there's going to be some great deals of pain for those who migrate, but new comers will find it equally easy (at the least), and old users will be made aware, quite clearly, that this feature is unsafe. They can always turn it back on if they wish to take the chances. Right now, we're taking the chances for them. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] Security Issues
At 10:19 27/07/2001, Brian Tanner wrote: Is all of this springing from that security advisory that was published a short while ago? I remember reading that, and feeling that many of the issues were overblown (if I'm thinking of the same one). Also, wasn't that advisory just written by some guy? Its not like W3C is writing a web security standards document and made an example out of PHP or something, its just the security suggestions/opinions of some guy. Seems like a whole lot of trouble (breaking thousands of scripts) -- just to appease some document by some guy. I don't know if that's just one guy or a group of people, but that one guy found exploitable bugs in pretty much any big PHP app he researched. Instead of ignoring his findings and saying he's just one guy, it's best to read the advisory and understand that he's really right about his assessment, that register_globals is the mother of a huge number of security flaws in PHP applications. Also, about this whole car with no brakes or gun aimed at the head business. I like the car analogy... and the register_globals=off. See.. turning register_globals off is like adding a huge brake, and then hiding the accelerator. For beginner drivers, or existing drivers that are not up on current events, it will be very hard to get going. That's simply not true, and it should be clear that it's not true. Teaching people to use $_GET[foo] is not more difficult than teaching them to use $foo. It's also more explicit and clear to read. If we were in front of a blank design board right now, it wouldn't have even be a question. The new method is equally clear, and has some advantages (the only disadvantage being a few more keystrokes, but that's not a big deal). The only reason we're having this debate is due to downwards compatibility. I'd say that leaving register_globals on is *exactly* like a regular car. Its dangerous, hell yeah. However, as long as you learn how to use it in an enclosed environment, and practice the safety techniques -- you are not too much of a danger to others when you get onto the highway. Same concept applies... if you take a beginner and put them on an enterprise server writing code that manipulates a DNS file or does updates and deletes to a crucial database, you are asking for trouble. Thats why people write simple, inconsequential application as they are *learning*, and after that have some experience, they should write things where they can actually hurt someone. Anyway, thats my .02. I'm done talking about this issue... its a difference of opinion, which is generally very hard to resolve -- and no amount of logical dicussion can change the mind of either group. Take a look at your apps, take a close look, and see if they're vulnerable to such attacks. Your apps may not be doing any 'dangerous' stuff, but try to see if a remote user, knowing the source code of the script, could cause your apps to behave differently with the right input. From my experience, many, if not most of the scripts fall into this category. If it's 0.1% of the population making mistakes, it's one thing. If it's 20% or 50%, it means that the language is at flaw. Even if you disagree that the language is at flaw and 'people should be taught how to drive more safely', there's no doubt that decreasing the chances of them making an accident very considerably is a good thing. As I told Peter, we're not talking about liability here, or who's to blame. We're trying to figure out the best way to convey PHP to people, and make them create good PHP applications. Right now, PHP encourages them to write bad apps, which is a bad thing, and gives PHP bad reputation. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
I'm definitely in favour of that, and some of the other suggestions that were raised. We won't be able to make all steps at once, but whomever can contribute is obviously quite welcome to do so. Zeev At 04:15 27/07/2001, Björn Schotte wrote: * Zeev Suraski wrote: equivalent to shipping cars without brakes. You hope that the user would be bright enough to install brakes, Hoping that is not enough. If you really change the behaviour to ship PHP with register_globals to off, then I suggest you should also ship some README_Security or something similar where Kris writes a nice tutorial about writing secure PHP applications. (This README_Security should also be inserted into the Manual and all places where it makes sense) Also, before doing make install a less README_Security should be done by the makefile. -- PHP Schulungen und| International PHP Conference Schulungsmaterial:| 05. - 07.11.2001 http://thinkphp.de/ | Astron Hotel, Frankfurt http://rent-a-phpwizard.de/schulungen.php | http://www.php-kongress.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
At 10:01 27/07/2001, Rasmus Lerdorf wrote: That's also not true. Is using $foo all that better than $_GET[foo]? For a neophyte user - most definitely. But it isn't. It's by fixing an inherent design flaw in PHP. The proposed target situation is *NOT* any more difficult to the users than the situation is today. Of course it is. $foo is conceptually simpler than $_GET[foo]. I don't see how you can say it isn't. Because it's a matter of taste, and different people see things different ways. Personally I find $_GET[foo] much clearer than $foo. It tells me, beyond a reasonable doubt, where this thing is coming from. The one and only drawback I see for this method is that it's a few more keystrokes, but that's by far less important than what it gives you. As a matter of fact, if I make $_GET and its friends be implicitly global, it'd actually safe you keystrokes in many situations, and is definitely easier than teaching users about the notion of the global scope, the global statement or $GLOBALS. I *really* don't see how you can go on claiming that register_globals is not at fault, when we have so many examples, both practical past exploits and theoretical problems, directly related to it. That, on the other hand, is not a matter of taste. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] Security Issues
At 04:51 27/07/2001, Marc Boeren wrote:
Changing to register globals=off surely does very little in
terms of security for the easily fakeable GPC variables.
Maybe not for these variables, but other variables used in your script
cannot be faked by passing them as HTTP_POST_VARS.
e.g., with register_globals=off
if ($HTTP_POST_VARS['user_string'] == 'check_for_security') {
// do something, but be aware of security issues
}
if ($internal_variable == 'whatever') {
// do something, knowing that a user could never have set this
}
The second check is where a lot of scripts are exploitable, I think, if
register_globals=on, because programmers do not expect user-input in this
variable.
*exactly*.
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
On Friday 27 July 2001 17:35, Zeev Suraski wrote: Have you read the advisory? That's simply not true. Yes, and I beleive it is true in most cases. There are two main types of security problems related to this: (a) Ones that originate in the fact that people don't know they mustn't trust any input coming from the user, be it GET, POST or cookies, that they're all insecure So, you admit that register_globals=off for GPC variables gains us nothing, but will break shed loads of code? (b) Ones that don't, and there are many of them For those of type (a), register_globals being off or on doesn't change much. For (b), it does, big time. Then if you don't like my suggestion, how about a half way house - register-globals=GPC registers the insecure variables in the global namespace since we can't trust them wherever they appear in the namespace, whilst env variables and possibly session variables have to be read out of arrays. I know that this would break none of my scripts, but I can't speak for other scripts out there. I do feel, however, that you are really missing the point on E_NOTICE which IMHO has a much greater effect on the security of PHP than accessing GPC variables in a different way. I'd personally be even harsher than E_NOTICE is - if a production site generates a notice message for an uninitialised variable, then that's a fatal error in my book! Cheers -- Phil Driscoll -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
At 08:58 27/07/2001, Jason Greene wrote: I have been watching this thread for too long and I can no longer resist commenting. If a programmer does not initialize SECURE variables properly, he is going to make far worse security decisions in his software. Next thing we are going to hear is that php does not auto TAINT check parsed variables. I personally disagree with making register_globals=off a default. I really don't think it will make that big of a difference, and come on everyone, this is one of the coolest features of php. Fact is that for many scripts (I'd argue most), this issue alone is going to be the one and only security issue he'd bump to. It's all too common. It's true that given other security 'decisions' he may have to make, he may make wrong decisions. What's argued here is that register_globals=off gives a clean, harmless looking way of shooting yourself in the foot. I also don't subscribe to the idea that it's one of the coolest features of PHP because it's a global variable. Auto registration of form variables is equally cool if it's made in a secure way, instead of the security pitfall we have right now. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
That's also not true. Is using $foo all that better than $_GET[foo]? For a neophyte user - most definitely. But it isn't. It's by fixing an inherent design flaw in PHP. The proposed target situation is *NOT* any more difficult to the users than the situation is today. Of course it is. $foo is conceptually simpler than $_GET[foo]. I don't see how you can say it isn't. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
At 10:26 27/07/2001, Phil Driscoll wrote: On Friday 27 July 2001 17:35, Zeev Suraski wrote: Have you read the advisory? That's simply not true. Yes, and I beleive it is true in most cases. There are two main types of security problems related to this: (a) Ones that originate in the fact that people don't know they mustn't trust any input coming from the user, be it GET, POST or cookies, that they're all insecure So, you admit that register_globals=off for GPC variables gains us nothing, but will break shed loads of code? Of course not. The advisory includes several references to cases that demonstrate the exact opposite, and it makes perfect sense that many other such cases exist. (b) Ones that don't, and there are many of them For those of type (a), register_globals being off or on doesn't change much. For (b), it does, big time. Then if you don't like my suggestion, how about a half way house - register-globals=GPC registers the insecure variables in the global namespace since we can't trust them wherever they appear in the namespace, whilst env variables and possibly session variables have to be read out of arrays. I know that this would break none of my scripts, but I can't speak for other scripts out there. I do feel, however, that you are really missing the point on E_NOTICE which IMHO has a much greater effect on the security of PHP than accessing GPC variables in a different way. I'd personally be even harsher than E_NOTICE is - if a production site generates a notice message for an uninitialised variable, then that's a fatal error in my book! I think you missed the main point of the advisory. People use global variables. If people from the outside can pollute the global namespace using ANY method, it causes a common security pitfall. I don't want to argue about the E_NOTICE stuff because of lack of time, and because IMHO, it's really very loosely related to the issue at hand. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] Security Issues
Thanks for the cool response Zeev.. I was a little agitated when I wrote that letter, glad you didn't take it the wrong way. Again, my position is very simple. I agree that what you are suggesting would greatly reduce the exploits of the language. Just concerned about the cost, and if the benefit/cost ratio is in the right ballpark. I think it might be too much of a cost, for not enough benefit. I personally feel that these issues up to the programmer, (hence the difference of opinion). This change will break many of my scripts, some of which can take variables from Get, Post, or Cookies. I'm not looking forward to writing the logic to *fix* all of these, when my scripts are secure as it stands now. You asked if I examined my scripts, could they be caused to behave differently if someone knew the source? Differently - sometimes Dangerously - Never And my apps are not exactly hit counters either. I'm actually working on a very large project that I'm going to tell you all about one day soon, when its done ;) -Brian T -Original Message- From: Zeev Suraski [mailto:[EMAIL PROTECTED]] Sent: July 27, 2001 10:06 AM To: Brian Tanner Cc: [EMAIL PROTECTED] Subject: RE: [PHP-DEV] Security Issues At 10:19 27/07/2001, Brian Tanner wrote: Is all of this springing from that security advisory that was published a short while ago? I remember reading that, and feeling that many of the issues were overblown (if I'm thinking of the same one). Also, wasn't that advisory just written by some guy? Its not like W3C is writing a web security standards document and made an example out of PHP or something, its just the security suggestions/opinions of some guy. Seems like a whole lot of trouble (breaking thousands of scripts) -- just to appease some document by some guy. I don't know if that's just one guy or a group of people, but that one guy found exploitable bugs in pretty much any big PHP app he researched. Instead of ignoring his findings and saying he's just one guy, it's best to read the advisory and understand that he's really right about his assessment, that register_globals is the mother of a huge number of security flaws in PHP applications. Also, about this whole car with no brakes or gun aimed at the head business. I like the car analogy... and the register_globals=off. See.. turning register_globals off is like adding a huge brake, and then hiding the accelerator. For beginner drivers, or existing drivers that are not up on current events, it will be very hard to get going. That's simply not true, and it should be clear that it's not true. Teaching people to use $_GET[foo] is not more difficult than teaching them to use $foo. It's also more explicit and clear to read. If we were in front of a blank design board right now, it wouldn't have even be a question. The new method is equally clear, and has some advantages (the only disadvantage being a few more keystrokes, but that's not a big deal). The only reason we're having this debate is due to downwards compatibility. I'd say that leaving register_globals on is *exactly* like a regular car. Its dangerous, hell yeah. However, as long as you learn how to use it in an enclosed environment, and practice the safety techniques -- you are not too much of a danger to others when you get onto the highway. Same concept applies... if you take a beginner and put them on an enterprise server writing code that manipulates a DNS file or does updates and deletes to a crucial database, you are asking for trouble. Thats why people write simple, inconsequential application as they are *learning*, and after that have some experience, they should write things where they can actually hurt someone. Anyway, thats my .02. I'm done talking about this issue... its a difference of opinion, which is generally very hard to resolve -- and no amount of logical dicussion can change the mind of either group. Take a look at your apps, take a close look, and see if they're vulnerable to such attacks. Your apps may not be doing any 'dangerous' stuff, but try to see if a remote user, knowing the source code of the script, could cause your apps to behave differently with the right input. From my experience, many, if not most of the scripts fall into this category. If it's 0.1% of the population making mistakes, it's one thing. If it's 20% or 50%, it means that the language is at flaw. Even if you disagree that the language is at flaw and 'people should be taught how to drive more safely', there's no doubt that decreasing the chances of them making an accident very considerably is a good thing. As I told Peter, we're not talking about liability here, or who's to blame. We're trying to figure out the best way to convey PHP to people, and make them create good PHP applications. Right now, PHP encourages them to write bad apps, which is a bad thing, and gives PHP bad reputation. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe
Re: [PHP-DEV] Security Issues
This is an important step, that as I said, I wanted to make for years. I just argue that as protective as you are over register_globals=on, the real flaw is there, and this is the place it should be fixed. Fixing the fact that E_NOTICE is on may also be viable, but in practice: - A huge number of cases where E_NOTICE's will be generated isn't related to security in any way, and people will be kind of pissed by it, and probably turn it back off That's an issue that can be addressed. We perhaps need better granularity on the E_NOTICE. If we distribute a php.ini-recommended, we can, and probably should enable E_NOTICE's by default. It's not the solution to the problem raised in the advisory. The very first and primary example in the advisory would most definitely have been caught by an E_NOTICE, so I don't see how this doesn't address the advisory. For reference the first example in the advisory is: ?php if ($pass = hello) $auth = 1; ... if ($auth == 1) echo some important information; ? First, the guy who wrote the advisory didn't check his code, because the above could never actually be a problem since he confuses == and = and actually always sets $auth=1, but ignoring that and fixing his code, if you turn on E_NOTICE this script generates: Warning: Undefined variable: pass in foo.php on line 2 Warning: Undefined variable: auth in foo.php on line 5 And the second example is: ?php if (!($fd = fopen($filename, r)) echo(Could not open file: $filenameBR\n); ? Again, an obvious bracket mismatch so this example also doesn't run, but running this with E_NOTICE gives: Warning: Undefined variable: filename in foo.php on line 2 Warning: Undefined variable: filename in foo.php on line 3 Same goes for example 3 which is: ?php include($libdir . /languages.php); ? Then he talks about the file upload issues which is a separate problem and one we have addressed. And then he talks about .inc files and suggests that people who just use .php for include files are vulnerable because their scripts could be run out of context. This is a different issue as well. But that's not the point. The point is that people who don't care about security or coding style (beginners or professionals, doesn't really matter) are less likely to write insecure code, because there's one mistake less that they can make. As long as they stick to the defaults, anyway. And one language less that these people are able to use. That's an empty statement, Rasmus... The auto-registered form variables are not any less usable if we change the access method to them slightly. I'd argue it actually makes the code much more readable and newbie-friendly, actually. Why are new users latching onto PHP instead of Perl:CGI? PHP is not an inherently better scripting language. In fact it is probably significantly weaker. People use PHP because they find it easy to understand and easy to learn and because it is targeted to the Web problem. We have a responsibility to help people write more secure scripts, but we also cannot keep adding complexity to the point where we lose what makes PHP what it is. And we need to explore all the options we have here instead of jumping to conclusions. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
In article [EMAIL PROTECTED], Rasmus Lerdorf wrote: But that's not the point. The point is that people who don't care about security or coding style (beginners or professionals, doesn't really matter) are less likely to write insecure code, because there's one mistake less that they can make. As long as they stick to the defaults, anyway. And one language less that these people are able to use. I do not think that the current php users would drop the language. Maybe it would prevent certain users to start working with it. I'm sure that some good faqs on security issues would prevent a lot of harm. Not only with issues on uninitialized vars (which I tend to forget too) but problems like default passwords in a new installed application, using extentions for libs that could are handled as plain text, etc... I think that settings like 'allow_url_fopen' is causing much more issues then people can imagine. A short visit to Google will bring you to a lot of sites that are exploitable. Regards, Hans -- http://phpreview.nl.linux.org -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
Zeev Suraski wrote: Because it's a matter of taste, and different people see things different ways. Personally I find $_GET[foo] much clearer than $foo. It tells me, beyond a reasonable doubt, where this thing is coming from. The one and only drawback I see for this method is that it's a few more keystrokes, but that's by far less important than what it gives you. As a matter of fact, if I make $_GET and its friends be implicitly global, it'd actually safe you keystrokes in many situations, and is definitely easier than teaching users about the notion of the global scope, the global statement or $GLOBALS. If I can just interject once, I was a bit skeptical of this thread at first but I'm starting to come around to Zeev's point of view. Security aside (which I know it shouldn't be) I found in my own coding I always started naming post or get variables like $form_user_name or $post_user_name so I could easily tell just by looking at individual sections of the code that this variable was web input, vs my own internal variable. But even still, it can be confusing to newbes trying to understand just how did this variable get its value?. Having the $_GET[ post_user_name] is much more straight forward. But is there a $_POST call also? Making a important distinction between data posted or getted input? If so, that may be a small inconvienence. Good debate tho, and well timed for other issues I'm dealing with. Brian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] Security Issues
Brian Foddy actually brings up a really important issue, which would go along way to making (at least me) much happier with the proposed change. *If* there will be: $_Get[] $_Post[] $_Cookie[] -- can we also have something else to the tune of: $_External or $_User or $_Something That gets populated based on the ordering set for GPC right now in the .ini file? I think it would go really far towards helping a newbie (and to helping people fix their existing code), if there was one place that they could look, to find the old value that they are now missing. People can still go to _Get, _Post, and _Cookie if they require that level of granularity, but I think most will be happy with a general container for what Register_Globals *would* have done. -Brian T -Original Message- If I can just interject once, I was a bit skeptical of this thread at first but I'm starting to come around to Zeev's point of view. Security aside (which I know it shouldn't be) I found in my own coding I always started naming post or get variables like $form_user_name or $post_user_name so I could easily tell just by looking at individual sections of the code that this variable was web input, vs my own internal variable. But even still, it can be confusing to newbes trying to understand just how did this variable get its value?. Having the $_GET[ post_user_name] is much more straight forward. But is there a $_POST call also? Making a important distinction between data posted or getted input? If so, that may be a small inconvienence. Good debate tho, and well timed for other issues I'm dealing with. Brian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
Addressed to: Rasmus Lerdorf [EMAIL PROTECTED] [EMAIL PROTECTED] Or you can simply stop these people from using PHP which is another effect turning off register_globals will have. Java does not have this problem because Java is so complex that this same set of users can not program in Java. Fixing this problem by making PHP more complex and eliminating these problem users is a bad idea as far as I am concerned. YES!! As I see it the whole issue revolves around the fact that some people get used to the fact that undefined variables have a value, and rely on it. These are the people who get hit when a hacker slips in his own value in on such variables. If the programmer had just initialized the variable at the top of the program, there would not be a problem. I think the best thing you could do about this issue is: 1. ALWAYS report the use of an uninitialized variable, no matter what level of error checking is in effect. At the very least send a message to the error_log for every undefined variable. If the error level allows it also complain to the browser and send an email to ServerAdmin. That won't break any existing scripts, but depending on the text of the email, it could give system administrators incentive to correct problem scripts. [1] The 'send email' default should be on in the distribution. 2. Make it a FATAL error. Too bad that would break so many scripts... Maybe it could be a major effect of the E_SECURE bit. On the other hand, if you are serious about stamping out the uninitialized variable problem, this will do it. Register Globals is very convienent for people who write code with PHP. Turning it off would be a great loss. The problem is not that values passed to the server appear as variables, it is that some programmers don't make sure they initialize every variable before they use it. --- [1]: To: System Administrator [EMAIL PROTECTED] From: [EMAIL PROTECTED] Subject: Potential Security Problem in a PHP Script Warning: an undefined variable $I was accessed in myscript.php on line 123. This could be a serious security problem. For more information see: http://www.php.net/manual/en/security.uninitialized.php In most cases you can correct this error by simply adding $I = 0; somewhere before you attempt to use its value. If line 123 is within a loop, be sure to initialize the value before the beginning of the loop. A simple way to handle this is to initialize all variables you get this warning on at the very top of the script. You can stop these emails by removing E_UNINIT_EMAIL from error_reporting in your php.ini file. This problem has serious security implications and should not be ignored. Please read the web page listed above before you decide what to do. Rick Widmer Internet Marketing Specialists http://www.developersdesk.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] Security Issues
On Fri, 27 Jul 2001 23:00:54 +0200, Brian Tanner [EMAIL PROTECTED] wrote: *If* there will be: $_Get[] $_Post[] $_Cookie[] -- can we also have something else to the tune of: $_External or $_User or $_Something Important point. It's stupid if we suddenly have to hard-code for GET/POST/cookie-generated data. The interesting bit is to be aware of what data which has external origin. -- Greetings from Troels Arvin, Copenhagen, Denmark -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
