Zeev Suraski:
> My 2c on this piece is that tainting can be a nice helper tool to
> reduce the likelihood of security problems in your code. Nothing
> more and nothing less.
>
> I too fear the possibility of tainting becoming the new
> safe_mode. "Outsource your security to PHP, it'll take care of
> it". But I think there's a way of both designing and pitching
> tainting so that we avoid this false perception. If we pitch
> tainting as a development-time only tool the points out a certain
> class of security mistakes, and is by no means an invisible magnetic
> shield that actually protects you from them - then I think it can be
> quite useful.
Following up on an earlier suggestion in this thread, I could see
at least three modes of operation:
1) Disabled. The default setting.
2) Audit mode. Report perceived problems to logfile. This can be
used by developers to catch bugs, and by deployers for quality
assessment (but developers please don't start screaming yet).
3) Enforcement mode. Don't allow execution past a perceived problem.
It won't come as a surprise that I will try very hard to reduce
time and space overhead, so that taint checks can be used in
production environments (both modes 2 and 3 above).
As for positioning the feature, I don't think the problem is with
the name "taint" itself. It was introduced under this name with
Perl3 in 1989(*), and later under the same name in Ruby and other
programming languages. I am not aware that shortcomings in taint
support have ever been implicated as a cause for security
vulnerabilities (but I'm always willing to be corrected). That's
17 years of past experience speaking.
I do agree that it is important to build support by explaining what
taint support does. The primary purpose of the tool is to help
catch a common class of programming error: unchecked inputs in
shell/sql commands or other sensitive operations. With a pessimistic
taint propagation approach, there will unavoidably be false positives;
those false positives will have to be reduced to a practical level.
Some expressed concern that the tool would empower me and others
to force a particular programming idiom onto developers (you shall
code the way I want to). This is unlikely with the simple
black-and-white taint support as proposed initally, where untaint
is a broad operation that marks data as good for multiple contexts.
I think it's more likely to be a problem with narrow untaint
operators: untaint for HTML can be done only with a limited set of
untaint operators, and untaint for SQL can be done only with another
limited set of untaint operators, and so on. This would raise many
false alarms in existing code that is not vulnerable. I'm concerned
that this would not win over the hearts and minds of many.
As long as we don't overreach (try to stop every problem) and
oversell (promise it will stop every problem) then we should be
fine, if 17 years of past experience can be applied to PHP.
Wietse
(*)
http://mirrors.develooper.com/perl/really-ancient-perls/oldperl/dist/dex/perl/3.000-3.044/kit3.000/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
