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:zeev@zend.com] Sent: July 25, 2001 6:29 PM To: Rasmus Lerdorf Cc: Andy; php-dev@lists.php.net 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 *is* evil. >And the case for leaving register_globals on is that it is a whole lot >easier for people to figure out how to get started with PHP when the data >is just there and you don't have to do any strange array tricks to get at >your data. I don't think that this arguments holds much water, as register_globals is the mother of many many security bugs, found in the most popular PHP apps out there. We need to find a way to access form variables easily, but without encouraging insecure coding, the way we do now. Zeev -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: php-dev-unsubscribe@lists.php.net For additional commands, e-mail: php-dev-help@lists.php.net To contact the list administrators, e-mail: php-list-admin@lists.php.net