Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:14549
Return-Path: <andi@zend.com>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 79552 invoked by uid 1010); 3 Feb 2005 00:43:44 -0000
Delivered-To: ezmlm-scan-internals@lists.php.net
Delivered-To: ezmlm-internals@lists.php.net
Received: (qmail 79536 invoked from network); 3 Feb 2005 00:43:44 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 3 Feb 2005 00:43:44 -0000
X-Host-Fingerprint: 80.74.107.235 mail.zend.com Linux 2.4/2.6
Received: from ([80.74.107.235:59237] helo=mail.zend.com)
	by pb1.pair.com (ecelerity HEAD (r4105:4106)) with SMTP
	id 7C/EB-30841-FB371024 for <internals@lists.php.net>; Wed, 02 Feb 2005 19:43:44 -0500
Received: (qmail 6495 invoked from network); 3 Feb 2005 00:43:38 -0000
Received: from localhost (HELO andi-notebook.zend.com) (127.0.0.1)
	by localhost with SMTP; 3 Feb 2005 00:43:38 -0000
Message-ID: <5.1.0.14.2.20050202164228.0271b7d0@localhost>
X-Sender: andi@localhost
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 02 Feb 2005 16:43:34 -0800
To: Rasmus Lerdorf <rasmus@lerdorf.com>,Jeff Moore <jeff@procata.com>
Cc: internals@lists.php.net
In-Reply-To: <42013DB9.5000601@lerdorf.com>
References: <99da3c6937a48377bdb7790dccfaef1e@procata.com>
	<5.1.0.14.2.20050201111730.0299da70@localhost>
	<5.1.0.14.2.20050201111730.0299da70@localhost>
	<5.1.0.14.2.20050201142816.026d21c0@localhost>
	<420005A3.8050605@lerdorf.com>
	<99da3c6937a48377bdb7790dccfaef1e@procata.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: Re: [PHP-DEV] PHP 5.1
From: andi@zend.com (Andi Gutmans)

At 12:53 PM 2/2/2005 -0800, Rasmus Lerdorf wrote:
>Pick 10 random PHP apps out there and go through them.  With very very few 
>exceptions 10 out of 10 will be insecure.  And the blame here is not just 
>on the developers of those applications, we are partially to blame for not 
>providing enough tools and guidelines.  This is what I am trying to 
>rectify with minimum impact to the existing code and the way people do 
>things.  Some of your suggestions are good, but some just aren't 
>feasible.  For example, it would be difficult to implement your idea of 
>only letting data through if a filter was assigned to it and having those 
>filter assignments happen in the scripts themselves since that is too late 
>in the game.  It could be hacked, but it would be ugly and 
>complex.  Having just a single optional default filter per request is 
>simpler to manage and implement.

We could filter the superglobals at run-time. There are two options:
a) Go over the super globals and filter each one.
b) If the superglobal JIT thingy works (which I think it does) then you 
could set a flag before using the first superglobal and it would happen JIT.

I'd probably prefer (a) though.

Andi