On 15-Dec-06, at 4:16 PM, Stanislav Malyshev wrote:
Sounds awefuly like yet another safe_mode, something that
proclaims security, yet being unable to provide it.
Repeating my comments on that, I think that it can be done not like
safe_mode, if we take different approach. Namely, not "mark unsafe,
accept otherwise" but "mark safe, deny otherwise".
Ok this is better, but it will break every single application out
there. I for one think that this is unacceptable.
Meaning, first we separate functions into 3 categories:
1. Cleaners - can take tainted data, produce untainted data
2. Regulars - can take tainted data, produce tainted data
3. Protected - can take only untainted data
Then we mark all "unknown" function protected, then - the hard
part, lot of work alert - go over code base and extensions and put
"regular" flags on some basic functions (like string manipulation)
and "cleaner" flag on some like filters. This can be done on engine
level - meaning, except some special cases, most function would
never need any code change but a bit in function table description.
My opinion is that besides cleaners, most functions actually would
be fine never receiving tainted data without prior cleaning.
Of course, it would break a lot of code, but it would be also a
powerful way to drive people to write more secure code. E.g. if
your app passes taint-check before deployment, it means most
probably you didn't make the top 80% of PHP security mistakes. Of
course, it won't be bulletproof - but no security enhancement is,
and ensuring 100% secure code with automatic tools is quite a dream
anyway.
When it comes to security things like "most probably" and "likely"
usually are synonymous with insecure. The biggest issue with
safe_mode (and I suspect tainting as well) is the faulty assumption
that if you enable it, you get instant security and you can quite
being paranoid. Which leads to false sense of security and eventually
getting hacked.
You would need to go through some 5,000+ functions that PHP offers
and determine which one can and cannot receive tainted data,
something that virtually guarantees things will be missed, bring
us back to the safe_mode/open_basedir problem.
That's why - see above - I would recommend reverse approach.
So you reverse the problem, you'd still need to examine every
function and determine which of its parameters can be tainted and
which cannot.
Again, many functions have different behaviors etc... Let's take
an example htmlspecialchars() is great against XSS but does
nothing for exec(), so if you htmlspecialchars a string then pass
it to exec, it thinks that the data is non-tainted and executes it
resulting in command injection.
Yep, this is a problem, thus I'm not sure htmlspecialchars should
be always given cleaner attribute. There are a number of ways to
deal with it:
1. Let the user be smart - if he thought using htmlspecialchars he
probably is aware of filtering, so we hope he can do it right. Most
of problems are due to lack of any filtering at all because nobody
even thought of doing it.
2. Let the user to say us the function is really cleaning - e.g.
add some parameter that would say "untaint" - suppsing that if one
bothered to put this parameter one probably gave some thought to it.
3. Let the user use specific cleaner functions - like filters - so
that we reasonably sure he knows what he's doing.
I think we should ensure that we can provide users with reliable
means to validate data via things like filter and database escaping
functions and let people decide what and where things should be used.
Doing automated validation is prone to error and we are almost
guaranteed to never get it right.
Ilia Alshanetsky
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
