[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0701021356080.9580@pegasus.billn.net>
Date: Tue, 2 Jan 2007 14:07:29 -0700 (MST)
From: Bill Nash <billn@...ln.net>
To: Darren Reed <avalon@...igula.anu.edu.au>
Cc: Jim Harrison <Jim@...tools.org>, bugtraq@...urityfocus.com
Subject: Re: PHP as a secure language? PHP worms? [was: Re: new linux malware]
On Wed, 3 Jan 2007, Darren Reed wrote:
> 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.
The point Darren is driving home with a large hammer, isn't the
languages themselves, but how they are used, in combination with the
almost absent barrier-to-entry in deploying vulnerable platforms.
I think another major factor with regard to modern
vulnerabilities, is that many bounds checks and input validation are being
done with Javascript, or to be more specific, the untrustable client
device. This is the equivalent of loaning money to someone, and later
asking them to remind you how much they owe you because you forgot.
PHP, or Perl, or ASP, as popular engines, could all benefit from a
community driven set of validation routines applied either in the base
interpreters, or as an includable library to give the less clueful a leg
up. It's a very easy thing for me to take my custom platform and include
such a thing, it's not much farther to do the same for others.
Cherry pick the top ten root causes of your 100 favorite
vulnerabilities. Come up with standard routines that developers can use to
scrub their input, and release them for the most affected platforms. Get
with the distributors of those platforms and get them implemented into the
next versions. Rinse, lather, repeat. The problem here, of course, is
finding a group with the motivation, time, and resources to do so. Without
some intended course of action, this thread is just talk.
Also, if you're on vacation, which many of you are, a large
contingent of you have crappy auto-responders that don't recognize mailing
list membership. I hope Santa brought you coal.
- billn
Powered by blists - more mailing lists