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