Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:27006
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 66.249.82.229 as permitted sender)
DomainKey-Status: good
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer:sender;
        b=RM68McK9Wlnah/+pfN1M+GcmTN0hSsXpupYVcp/PZwXJDEW35lKo/yfzRJl35rrEQjR8pibwF7KV/M8YLGXJuWoVCpLZYKiIVBVbWpetBmx4jwWhSd1dz5eSKoudcMWExX8kzsMT/hbDworRqQR1n3AzGa4rEWugU0HCr/5aSCo=
In-Reply-To: <45832F71.2080503@zend.com>
References: <20061215201448.B16D8BC1AB@spike.porcupine.org> <7AE00699-23C2-4759-A50C-3D94199DA85A@prohost.org> <45831090.1000704@zend.com> <18A7CF93-7BFD-4764-847D-6C107A62875E@prohost.org> <45831A87.6050301@zend.com> <EED341E1-CC7E-4573-BF76-1EE50B01C7A1@prohost.org> <45832B9B.2080109@zend.com> <8BC86061-CCC5-45C3-8C40-92B06ADBB117@prohost.org> <45832F71.2080503@zend.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-ID: <7C8CB695-3E81-4009-9699-2499DBF7B366@prohost.org>
Cc: PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: 7bit
Date: Fri, 15 Dec 2006 18:43:54 -0500
To: Stanislav Malyshev <stas@zend.com>
Sender: Ilia Alshanetsky <iliaal@gmail.com>
Subject: Re: [PHP-DEV] Run-time taint support proposal
From: ilia@prohost.org (Ilia Alshanetsky)


On 15-Dec-06, at 6:27 PM, Stanislav Malyshev wrote:

>> So you claim that without taint mode it is not possible to write  
>> safe PHP code?
>
> Actually, I said exactly the opposite - if you write secure code,  
> you do not need it. If you are concerned about your code  
> potentially being buggy and do not want to rely only on your own  
> smarts to avoid it - you need security tools. Tainting is one of  
> such tools.
>
>> Tainting is a false security it makes you feel secure, when you  
>> aren't.
>
> Well, everything is false security then, because I know of no  
> remotely accessible system that didn't have one or other way to  
> circumvent the access control. Programs have bugs, passwords can be  
> stolen or guessed, etc. So I would propose to move away from  
> generic statements to something more concrete.

Not quite. If you have a function that let's say designed  
specifically to take unsafe data and make it safe for a particular  
use. For example htmlentities(value, ENT_QUOTES) will make input data  
safe to print on screen without concerns about XSS. At the this  
limited and very simple level it is very simple to provide user with  
convenient and simple means of auditing the data and making it safe.  
Tainting as such is not a tool, because it does not secure data, it  
just imposes arbitrary limits on what's safe or not, which is only  
sometimes right, because you cannot predict every (even every common)  
code path. If we take tools like coverity and alike there is a reason  
why majority of the thing they find are false positives. The problem  
with so many false positives is that they reduce the value of the  
tool and make users ignore it or work to simply bypass it.

Consider E_NOTICE, it is a superb tool for finding out things like un- 
declared variables (which often cause all manner of exploits), and  
yet most developers keep it off because it gets in a way, even though  
it has 0 false positives. However I suppose it is simpler and  
ultimately harmless to do $value = (int)$_POST['value']; without  
checking if $_POST['value'] exists via isset.

Another interesting example I want to bring to your attention is a  
seemingly innocuous function strlen(), which you've mentioned before.  
Suppose strlen() is said to allow tainted input, since afterall  
what's the harm. One simple exploit leading to information disclosure  
is to pass it an array() causing the function to generate an error  
exposing the script's path.

>> Good luck, I suppose on a base level it is entertaining seeing  
>> someone bang their head against the wall time and time again.
>
> You could enjoy the entertainment or you could bring some tools and  
> help bring the wall down :) Whatever you heart desires.

Standing next to a wall and trying to knock down its foundations is a  
rather dangerous endeavor :)

Ilia Alshanetsky