On Fri, 2006-12-15 at 18:43 -0500, Ilia Alshanetsky wrote:
> On 15-Dec-06, at 6:27 PM, Stanislav Malyshev wrote:
>
> 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.
I have a couple of things to say, the first being to reiterate other's
point of view where the tainting feature would be a tool to help
determine locations of suspect code. Obviously it won't make your code
any more safer, but if you enable it and react to the feedback from
warnings/errors then you WILL have more secure code. False positives
suck, and for such cases I would suggest allowing a developer to easily
untaint data that they feel/know in their (preferrably) expert opinion
is clean. For instance:
(untaint)$someVar;
I think it should be a language level construct for optimal speed.
Additionally I think there should be a (taint)$someVar construct also so
that APIs can specifically taint return values that they know should be
tainted but that might have been untainted during whatever processing
they performed.
> 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.
I think the tainting system would be a complimentary system to E_NOTICE
and E_WARNING. Both of these are useless if you don't pay attention to
the messages generated. The same would be true of the tainting system.
You don't get anything for free, you need to actively handle such
issues. This brings me to another issue...
Since tainting is about helping the developer to improve the security of
their code I think that it should be configurable for PHP_INI_ALL. This
would send a clear message to hosting companies that this does not make
their PHP installations more secure.
Additionally I think that there should be three possible settings for
such a tainting mode.
tainting = on
tainting = off
tainting = promiscuous
The first two are obvious. The last would essentially work the same as
tainting being enabled with the exception that scripts will work as
though it was turned off but warnings/errors will show up in error log.
This will allow hosting companies to enable it by default without
adversely affecting scripts.
Lastly, is this something that can be turned off at the compile level so
that the checks for tainting being enabled are completely skipped.
Sometimes you just want to eke out the extra speed in a production
environment.
+1 for tainting (from null karma source :)
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. |
`------------------------------------------------------------'
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
