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". 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.
Unlikely to ever be the case, the overhead of taint modes is generally
quite significant.
This is important consideration. However, if one works with it as
pre-deployment test step and not production, it might be less important
- especially if combined with some kind of unit-testing and coverage
solution.
This of course can be - and should be - combined with runtime solution
like filtering. It is my impression that some view tainting as something
opposed to filtering, while the correct approach would be that tainting
complements filtering, ensuring that no data route left uncovered.
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.
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.
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
