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:zeev@zend.com] Sent: July 27, 2001 10:06 AM To: Brian Tanner Cc: php-dev@lists.php.net 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