Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:16973
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
To: Russell Nelson <nelson@crynwr.com>
Cc: internals@lists.php.net
In-Reply-To: <17089.18702.450236.614561@desk.crynwr.com>
References: <42BDDC82.6020208@ohgaki.net>
	<17088.52397.92440.326561@desk.crynwr.com> <42C0CF76.6090203@lerdorf.com>
	<42C0F4DA.4000605@php.net>  <17089.18702.450236.614561@desk.crynwr.com>
Content-Type: multipart/alternative; boundary="=-d9gr879lK42n/+Q2wQZy"
Date: Tue, 28 Jun 2005 18:43:00 -0400
Message-ID: <1119998580.13690.109.camel@localhost>
Mime-Version: 1.0
Subject: Re: [PHP-DEV] allow_url_fopen should be INI_ALL
From: ajb732@comcast.net (Al Baker)

--=-d9gr879lK42n/+Q2wQZy
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

There is nothing wrong with fopen or include, and PHP isn't
instrinically broken here.  The only thing intrinsic about PHP that has
anything to do with these security areas is how PHP is powerfully simple
- lowering the bar for adoption.  When you do this, you pick up newbie
programmers who code up insecure applications.  The bar also gets
lowered for juvenile attackers who can easily browse and understand
source code.

Real software engineers - like those in the enterprise - know how to
write secure code and look at how flexible PHP is and see an amazing
tool to increase productivity.  

Turning PHP into a babysitter only hurts PHP, by restricting the
enterprise / experienced developers, and curtailing innovation on how
PHP is used.  There are already solutions available for hosting
companies that want a stop gap solution.  I've even seen hosting
companies that offer security consulting and can work with their
customers to secure their site.

Your "do this because Google proves it" argument only shows me that
there are mainly educational articles on topics of security, and I would
say that people are learning more about web security as time goes on -
hence the high page rank of those articles.  Using google to prove a
point is both flawed and useless.

I agree with Stefan's previous emails.

Al

On Tue, 2005-06-28 at 08:56 -0400, Russell Nelson wrote:

> Stefan Esser writes:
>  > I agree with Rasmus. Remote URL Includes are dieing out.
> 
> That's not what Rasmus said.
> 
>  > Most released advisories are SQL Injections nowadays and well maybe
>  > Russells next mail says: mysql_query() considered harmful.
> 
> When the top Google result for 'php security flaw' returns
> mysql_query() instead of include(), I will agree that you are correct.
> 
>  > Ohhh btw Russell, if you really consider include harmful, then simply 
>  > install the Hardening-Patch for PHP and live with it.
> 
> I'm not trying to fix this for me.  Clearly there are at least a
> half-dozen things I could do to fix the problem for myself[!].  I
> believe that the problem's cause is the design of the language
> intrinsic.  Therefore, fixing the problem for myself doesn't address
> the cause of the problem.  It just prevents me from seeing the problem
> anymore.  The problem is still there.
> 
> [!] The first six:
>  1) rm -rf php
>  2) don't allow my users access to php.
>  3) audit all code written by my users.
>  4) turn allow_url_fopen off.
>  5) install Hardening.
>  6) write my own patch removing url_fopen capability from 'include'.
> 
> -- 
> --My blog is at     blog.russnelson.com         | If you want to find
> Crynwr sells support for free software  | PGPok | injustice in economic
> 521 Pleasant Valley Rd. | +1 315-323-1241       | affairs, look for the
> Potsdam, NY 13676-3213  |                       | hand of a legislator.
> 

--=-d9gr879lK42n/+Q2wQZy--