Hi, I guess a taint mode would give users the impression that the data is safe while it isn't safe.
As an example: $data = mysql_real_escape_sring($_GET['data']); query(with $data); echo "Saved $data"; For the first part the data is safe and the escape removes the taint flag. Having the taint mode enabled and annoyed by the warnings the user is happy having no warning in the second case, thinking "hey, there's no warning - I don't need to care anymore" - but still having a security issue. Having systems with a lot higher complexity people might tend to just check whether they get taint-warnings or not and assume all other data safe. Knowing the PHP users I think it's simpler to teach them "all data is unsafe" instead of teaching "well, the taint mode gives you an idea which data is unsafe but still: All data is unsafe". I think a taint mode leads to the same kind of problems which lead to the safe_mode removal for PHP 6. johannes On Fri, 2006-12-15 at 15:23 -0800, Andi Gutmans wrote: > Well the tool would point the developer at the data they have to > validate/filter. At that point the developer has to have a brain and needs > to know what he's doing with the data. Fortunately, if he has the right sets > of APIs in ext/filter which help him with this task, then it should be clear > to the average developer which ext/filter API he should choose. If we need > to improve those APIs then that can be done in parallel. > > > -----Original Message----- > > From: Ilia Alshanetsky [mailto:[EMAIL PROTECTED] On Behalf Of > > Ilia Alshanetsky > > Sent: Friday, December 15, 2006 3:12 PM > > To: PHP internals > > Subject: Re: [PHP-DEV] Run-time taint support proposal > > > > > > On 15-Dec-06, at 6:06 PM, Wietse Venema wrote: > > > > > Ilia Alshanetsky: > > >> On 15-Dec-06, at 5:19 PM, Wietse Venema wrote: > > >>> Ilia Alshanetsky: > > >>>> That means an additional element to a struct that has > > thousands of > > >>>> instances in most scripts, this will be the first > > overhead caused > > >>>> by the memory footprint increase. > > >>> > > >>> There is no need for that. > > >>> > > >>> < zend_uchar is_ref; > > >>> --- > > >>>> zend_uchar is_ref:7; > > >>>> zend_uchar taint_flag:1; > > >>> > > >>> Perhaps a working implementation will be convincing. I > > offer to do > > >>> the work, other people lose nothing except the > > possibility that they > > >>> will be proven right. > > >> > > >> By all means :-) > > >> > > >> I suppose by making taint_flag 1 bit, you are assuming taint is > > >> purely black and white and that all untaint functions will secure > > >> data against all forms of usage. > > > > > > If the default fail-close security policy is no function receives > > > tainted input unless explicitly stated otherwise, then one bit > > > suffices. That is actually the easiest part. > > > > And here is your first exploit, let's say we say > > mysql_real_escape_string() takes tainted data and makes it > > untainted, what happens when this "safe" data is passed to > > exec(). You are going to need to deal with different levels > > of taint-untainted and 1 bit is not going to give you that > > flexibility. You are going to need an int/ long, maybe even a > > long long. > > > > Ilia Alshanetsky > > > > -- > > PHP Internals - PHP Runtime Development Mailing List To > > unsubscribe, visit: http://www.php.net/unsub.php > > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
