output to browser, output to system (console/whatever else), sql, xml,
streams, etc... all of them require special attentions.
Hello, safe mode 2.0! :)
Seriously, I do not think tainting is made for that - and we will have a
ton of trouble trying to describe what is "safe for SQL" (is it for
MySQL? Oracle? DB2? sqlite? a ton of other SQLs each with own quirks and
quoting rules?) and what is "safe for output" (is it OK to output HTML
tags?). Tainting mode, as I see it, is meant to achieve exactly one
simple task - force you (as much as it can) to take explicit action on
sanitizing the parameters before they can do any harm. I do not think it
should make you use any specific way of sanitizing or check data for
anything specific - this is impossible without domain-specific
knowledge. This is task for filters and yes - for you as a developer.
Tainting mode only makes sure for you that you do you job. It's like
code coverage report - it doesn't make your code bug-free, it only
ensures you actually did some checking. And that's why it can be dumb
and not try to figure out what is safe for output and what is safe for xml.
I do not want the mode 3, for the reasons I explained earlier. I also
Actually, I do. Especially if I had some legacy non-filtering
application which I wanted to secure. I would prefer to break it hard
and then assemble the pieces in the correct way, rather than play
find-the-next-hole.
think many developers have the same reasons against it. It will be
enabled by default by many ISP and will bring back the pain of
safe_mode.
It is not like safe mode, and I explained about dozen times what is the
main difference. Please read it. We are going in circles here.
--
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
