[A quote that I might end up using somewhere]
> > Very well put/explained.
>
> If it was only about the input filtering, you can use (and should)
> ext/filter (filter.default=string with default flag strip low/high).
>
> And more generally since I use filter filter in my projects, I do not
> use anymore the auto globals (GPCCES) but only the filter functions. I
> would love to simply drop them, they were nice and handy years ago but
> it was a mistake to introduce them.
>
> It is something I always wanted to do and is close to what we have in
> all other languages (perl cgi, python cgi, etc.), it is safe as you
> _have_ to think about the filter to use instead of blindly do
> somecratythings($_GET['foo']);
>
> Now, about taint mode, is it possible to leave the input filtering for
> a second and explain me what else you like to do? How do you plan to
> manage the contexts? Do you want this horrible mode 3? Or will you
> argue about input filtering, sory taint mode until next year? :)
My plan is to gather feedback from the list over the next few weeks,
and to start early 2007 with the first of many incremental steps
of design and implementation, once the over-all design is complete.
My expectation is that taint checks will be useful mostly for new
versions of PHP source code. Indiscriminate application of taint
checks on existing source code would result in many false positives.
For example, as hinted at in my proposal, code like this is certain
to be flagged:
$junk = $_GET['foo'];
if (some conditional expression involving $_GET['foo']) {
...do shell or sql command with $_GET['foo']...
}
The reason is that the compiler would not know if the conditional
expression performs data sanitization, let alone if the condition
would be appropriate for the specific shell/sql context at hand.
Implementing "audit mode" taint checking is all the work. Adding
"enforcement mode" presents no technical challenge (change warning
into hard error), and I know people who want this. I am not too
worried that enforcement mode will be turned on indiscriminately.
As explained above, enforcement mode will not be useful unless
software was explicitly developed for run-time taint checking.
To help developers of existing software I would try to provide a
way to gradually deploy taint *checking* one source PHP file at a
time. This way, people can benefit immediately without having to
first update an entire source tree (of course taint *propagation*
would be enabled across the entire application). Gradual deployment
would require some pragma (or whatever it is called with PHP).
People concerned about the presence of such controls can simply
use ``find .. | xargs grep ..'' on the source tree.
Right now, multiple untaint contexts are not in my plans, but I
would be willing to correctly maintain (bit-wise AND) the unused
seven zval bits for taint propagation, so that someone else can
build support for multiple untaint contexts on top of my work. My
tainters and untainters would simply flip all bits together, and
my taint checks would simply test all bits for non-zero.
Wietse
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
