On Dec 19, 2006, at 10:53 AM, Ilia Alshanetsky wrote:
Bottom line is that does not, there are plenty of Perl application supposedly safe from XSS due to tainting while in reality are trivially exploitable via XSS due to the fact validation regex which does the un-tainting of data is sub-par.
If you incorrectly untaint data, how is that worse than not knowing that there was a tainted data path in your code in the first place?
The perfect is the enemy of the good. I think we can all agree that tainting can never be perfect. The question is it better than what we have now?
Relying on developers to correctly sanitize data every time and every place is certainly not perfect. Even the best and smartest developers make mistakes sometimes. Isn't this one of the problems with safe mode? I think the purpose of a taint mode should be to help find existing security problems, not to try to prevent security violations as with safe mode. Giving developers a dynamic security auditing tool is not a bad thing.
I think the real problem with a taint mode is the issue of false positives. It could end up being more annoying that the value it provides. But then, until its implemented, who can know?
I do think that once taint mode is enabled, there should be no way to turn it off or get around it, except to untaint the data. It should be fatal. No E_TAINT. No half measures. A program should either pass the "taint audit" or not pass, but it shouldn't be able to opt out of the audit with an ini_set, an .htaccess file, or an error handler. Tainting should not be a mode you run in, it should be an (imperfect) audit that you pass or fail.
A staged, conservative rollout as strictly an auditing feature might not even include an untaint or an is_tainted function. If you want to prevent ISPs from putting this in production, that would be one way to do it. Without untaint or is_tainted, tainting become strictly a debugging tool. If it turned out a bad idea, it would also be easily revokable. (Maybe is_tainted and untaint start out in PECL and the zval flag, function flags and fatal error only go into the core with an --enable configuration option?)
I think that a tainting audit mode could be a useful tool, provided that the number of false positives turns out to be reasonable. Marking functions as sensitive or such is certainly useful. I cringe at the idea of another global mode to deal with, another ini setting or another error_reporting level.
Regardless of whether this is included in PHP 6, I hope someone implements it. I want to run my programs with tainting and see what happens.
Best Regards, Jeff -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
