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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
