Date: Thu, 04 Jan 2007 10:59:17 -1000
From: Jim Manico <jim@...ico.net>
To: Ronald Chmara <ron@...s1.COM>
Cc: Darren Reed <avalon@...igula.anu.edu.au>,
	Jim Harrison <Jim@...tools.org>, bugtraq@...urityfocus.com
Subject: Re: PHP as a secure language? PHP worms? [was: Re: new linux malware]

> I'm quite confident that someone could develop a very secure
interpreted language.

Thats a moot point, it's not about languages anymore, it's about
FRAMEWORKS on top of languages with security baked in.

In Java my team has one "validation" servlet that every request must go through - so even if my junior programmers screw up, I'm catching it in a "framework-like" way. Struts Java framework allows you to validate form/request data via XML configuration so an InfoSec guy can add regex's to each-and-every element of your forms AFTER the fact WITHOUT programmer intervention.

In .NET, we win. .NET does not scale well (MySpace is suffering the cost of trying to deploy .NET globally, poor guys) BUT - .NET has a framework that automagically does input validation for you - and almost does it well. There WAS a 2.0 framework input validation bug a few months back, but MS patched it up within hours of discovery, and heck, most PPL are at .NET 1.1 still. Even the craptacular Drupal (4.7.4+) CMS PHP framework does CSRF protection very well via form keys. How many of your web apps defend again CSRF right now? 

I prefer Java and am not fond of M$, but I must nod my head to the security considerations baked into .NET (If only it scaled well) and some of the more mature Java frameworks like Struts. 

In the future - we will code web apps only to frameworks (or raw languages will start to add framework features at the language core). No more of this "raw language" BS for web apps (sorry Swa, wherever you are). It's all about the frameworks! Programmers are NOT coding more securely, I've seen architects recently not even able to TALK to me about CSRF, let alone defend against it! Pick a framework with a good security history, use it, and track it in a rather meticulous way.

- Jim





Ronald Chmara wrote:
> On Jan 2, 2007, at 10:37 AM, Darren Reed wrote:
>> In some mail from Jim Harrison, sie said:
>>> 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.
>
> "Genuine Security" is a marketing term (a misleading one, at that). A
> programming language without security risks is pretty much useless. A
> capable web programming language without security risks is darned near
> 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.
>
> Sorry, /bin/sh needs read access to /etc/passwd for uname checks, and
> thus, allows for information disclosure.
>
> Hm.
>
> LOGO is pretty safe to use. I'm not sure how much you can do with it
> anymore. You might be able to draw web pages.... really.... slowly.....
>
>> 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*.
>
> PHP was engineered with the power (and responsibilities) of C. It
> allows for on-the-fly database administration, file access at the
> level of permission given to the web server process, and input/output
> at the level of raw data streams.
>
> PHP is not a web "scripting" language, so much as a scripting
> interface to raw binary libraries on the disk, and raw machine
> resources. Thus, if an admin wants to build a PHP program to
> administer a massive DB cluster at the CLUI level, they can. If they
> want to run the world's largest online encyclopedia, they can.
>
> They can also write an address book.
>
>> 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.
>
> I think you might be a tad confused about the goals of PHP, or hoping
> that their goals match yours.
>
> "PHP, which stands for "PHP: Hypertext Preprocessor" is a widely-used
> Open Source general-purpose scripting language that is especially
> suited for Web development and can be embedded into HTML. Its syntax
> draws upon C, Java, and Perl, and is easy to learn. The main goal of
> the language is to allow web developers to write dynamically generated
> webpages quickly, but you can do much more with PHP."
>
> Note: "web developers", not "bored college students who tend to put
> SQL arguments into a GET string" or "oops, I didn't bother to check my
> args because the bong distracted me".
>
> Just because it's easy to learn how to use a gun does *not* give
> people license to shoot themselves in the foot and then complain that
> the gun was "too easy to use".
>
>> Just as
>> people using perl generally don't need to worry about buffer
>> overflows,
>
> Er, what? As soon as a perl user "glues" into an external library,
> they better start to worry about such things, or expect to get a pink
> slip.
>
>> why should people using PHP need to worry about SQL
>> escapes and filepath issues?
>
> Let us entertain your idea.
>
> Let us imagine a language that is near useless for database
> administration, because all of the "dangerous" statements to drop
> tables, or bulk update data, are removed.
> Let us imagine a language where every "dangerous" file path is
> removed, and thus, renders the language useless for any operation that
> traverses a file path.
> Let us imagine a language that only allows for limited looping, so it
> cannot suck too much CPU.
> Let us imagine a language where all data is "auto-sanitized", so it
> cannot handle complex binary streams.
>
> PHP is *not*, and *never has been*, this language.
>
> Perhaps, though, there is such a need for such a language that it can
> be developed...
>
> ...but I wouldn't use it, and neither would most of the people who
> need powerful code tools. I suggest you study the last 10 years of
> "web languages", it's a veritable highway of death of similar
> intentions, and dead-ends.
>
> -Bop
>
>
>

-- 
Best Regards,
Jim Manico
GIAC GSEC Professional, Sun Certified Java Programmer
jim@...ico.net
808.652.3805

Powered by blists - more mailing lists