"..comment has nothing to do with either.." - I'm addressing the generalistic "genuine security" arguments offered in this discussion. I have no contrary argument to the point that PHP in its current incarnation is not designed to be secure; only that those who espouse the idyllic language are in for a nasty surprise (if they're paying attention at all). "..you're saying "genuine security" is impossible.." - yes; that's exactly what I'm saying. I'm not trying to use it as a dissuading argument, only a reality check. -----Original Message----- From: Darren Reed [mailto:avalon@xxxxxxxxxxxxxxxxxxx] Sent: Tuesday, January 02, 2007 10:37 AM To: Jim Harrison Cc: bugtraq@xxxxxxxxxxxxxxxxx Subject: Re: PHP as a secure language? PHP worms? [was: Re: new linux malware] In some mail from Jim Harrison, sie said: > > No; this wasn't flame-bait, although I'd be silly not to expect some. > Let me make my position clear; the goals of secure coding and secure > languages are both grand and well worth the time spent. > > There are two primary factors which make this an impossible task: > > 1. "secure" is moving, contextual target. That which is deemed "secure" > by today's standards will be "just ok" or "watta joke" by future > evaluators. What is good enough for Joe's Garage won't even make it > in the door of Fred's Bank (3 anti-social points for each reference), > although some could argue that Joe's security requirements should > equal Fred's, since they both pin their business on it. This discussion is about secure programming and the problems related to PHP. Your comment has nothing to do with either except to state that what is considered secure by two different environments are actually different (big deal.) > 2. Until the human factor is removed from both, mistakes and simple > ignorance will always render them both "less than secure" in any > context. This is the core of my argument. > > Again; I agree with and fully support the effort. What I'm trying to > point out is the literal impossibility of actually achieving "genuine > security" in either our code or the languages it's written in. Well given that the ultimate root of any invention is going to be human, you're saying "genuine security" is impossible. I'm quite confident that someone could develop a very secure interpreted language. It might not do a lot, but it could easily be done (even if only to prove you wrong) - if one doesn't already exist. I could probably even prove a case with /bin/sh. The problem we have right now is that the language commonly used for dynamic web pages on non-Microsoft platforms is PHP and that this has not been engineered *for security*. The goal of a language such as PHP should be to make it possible to do what is required without the person using it needing to know anything about security or secure programming practices. Just as people using perl generally don't need to worry about buffer overflows, why should people using PHP need to worry about SQL escapes and filepath issues? They shouldn't. Darren All mail to and from this domain is GFI-scanned.
