Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:27094
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain interjinn.com from 66.11.173.122 cause and error)
To: Zeev Suraski <zeev@zend.com>
Cc: Ilia Alshanetsky <ilia@prohost.org>, Stanislav Malyshev <stas@zend.com>,  PHP internals <internals@lists.php.net>
In-Reply-To: <D4.84.28369.81AB7854@pb1.pair.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>
	 <7C8CB695-3E81-4009-9699-2499DBF7B366@prohost.org>
	 <4583375C.5060302@zend.com>
	 <2F093E93-7021-4C0F-A391-A99CBF080596@prohost.org>
	 <45833C93.4020909@zend.com>
	 <87774C2D-1959-459A-B892-F2F6F6A5C676@prohost.org>
	 <45835ABE.5040909@zend.com>
	 <6526D55D-DC87-40D4-8335-CCB0FA810646@prohost.org>
	 <45846491.6020101@zend.com>
	 <7FD783B9-68A7-4EC7-B6C3-8DBC44A51597@prohost.org>
	 <D4.84.28369.81AB7854@pb1.pair.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: InterJinn
Date: Tue, 19 Dec 2006 05:51:11 -0500
Message-ID: <1166525471.10091.170.camel@blobule>
Mime-Version: 1.0
Subject: Re: [PHP-DEV] Run-time taint support proposal
From: robert@interjinn.com (Robert Cummings)

On Tue, 2006-12-19 at 12:08 +0200, Zeev Suraski wrote:
> At 23:40 16/12/2006, Ilia Alshanetsky wrote:
> >>>You're not helping them, just making assumptions about how their
> >>>code should work and making them adhere to them.
> >>
> >>Yes, and this is helping. Every language does that. Saying "you
> >>can't make 100% work exactly as I wanted without any effort, so
> >>entire thing isn't even worth discussing" is a road nowhere.
> >>There's a lot of places it would be helpful, and there's a lot of
> >>places it won't - and that's ok.
> >
> >I am saying that you should not try to outsmart the developer because
> >you assume you know best.
> 
> Ilia,
> 
> Why are we outsmarting developers?  Security bugs are out there, in 
> fact in web apps they're pretty much a plague (irregardless of the 
> language).  Does it mean that some developers aren't smart and many 
> are not properly informed?  Absolutely YES - that's the world we live 
> in...  Given that, and the likelihood it'd only get worse (more and 
> more people are programming the web with less and less training) - 
> whatever we can provide in the direction of creating better apps can help.
> 
> My 2c on this piece is that tainting can be a nice helper tool to 
> reduce the likelihood of security problems in your code.  Nothing 
> more and nothing less.
> 
> I too fear the possibility of tainting becoming the new 
> safe_mode.  "Outsource your security to PHP, it'll take care of 
> it".  But I think there's a way of both designing and pitching 
> tainting so that we avoid this false perception.  If we pitch 
> tainting as a development-time only tool the points out a certain 
> class of security mistakes, and is by no means an invisible magnetic 
> shield that actually protects you from them - then I think it can be 
> quite useful.
> 
> As such, I would consider:
> - Saying tainting should not be enabled in production (avoid the 
> false sense of security people might have if they turn on tainting in 
> production).
> - Not necessarily the fastest possible implementation, since it'd be 
> used for development purposes only.
> - Consider making this a compile time option with significant 
> overhead and a big DO NOT ENABLE IN PRODUCTION, so that people have 
> an even clearer idea they shouldn't rely on it to find their bugs, 
> and that in fact it's just a helper tool, not unlike a strong IDE.

Ummm, wouldn't it be nice to have the option without taking a great big
artificial overhead penalty for having it enabled? I mean, I for one,
and definitely you for two, cannot possibly expect to catch every single
logic path in an application, and as we've already determined a simple
generic untaint is going to be pointless. It would be best to untaint as
close to the usage of the data as possible. Thus I think E_TAINT or
something being generated in a production environment is perfectly
acceptable in the same sense that E_NOTICE is.

> 
> We could possibly even come up with a new name other than tainting so 
> that there is not prior perception as to what this feature is 
> supposed or not supposed to do.

blighting :)

<?php

exec( $_GET['foo'] );

?>

>>> A blight is upon you in /path/to/source/foo.php on line 1

Cheers,
Rob.
-- 
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting  |
| a powerful, scalable system for accessing system services  |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for       |
| creating re-usable components quickly and easily.          |
`------------------------------------------------------------'