Rasmus Lerdorf:
> You can also choose to never store the raw single quote and always work
> with encoded data. Or, as I suggest, always filter it by default and in
> the places where you want the raw quote back or you want it filtered for
> a specific use, specify explicitly which filter you want to apply. It
> is the data firewall approach. Filter everything by default with an
> extremely strict filter and poke holes in your data firewall as
> necessary. It also makes it easy to audit your code because you only
> have to track look at the places where you have poked a hole.
I think I have calmed down enough that I can respond to this thread.
Unfortunately, this data firewall does not protect all interfaces.
For example, replacing characters by &foo; does nothing for shell
commands where & and ; are command separators. Instead of poking
small holes, you already have one big gaping security hole.
> > Data flow control (a.k.a. taint support) can detect when output
> > isn't converted with the proper conversion function. This can be
> > done in reporting mode (my approach) or it can be done in "automatic
> > fixing" mode (other people). These different approaches make
> > different trade-offs between programmer effort and system overhead,
> > and avoid the data corruption that input filtering would introduce.
>
> Having to do active checks on each use is extremely expensive. You said
> yourself you suggest only enabling this during development. The data
> firewall approach isn't actually all that different from the taint
> approach. The big win is that there is no runtime checking necessary
> and thus no performance hit.
The "reporting mode" (my approach) overhead is down to the 1% level,
as the result of some very careful design and implementation choices
that I could not anticipate when I discussed my initial proposal.
This level of overhead is low enough that continuous run-time
deployment becomes a realistic option. Thus, technical objections
can now make place for religious objections...
Wietse
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
