Re: 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