Re: short_open_tag
| From: | (Wietse Venema) | Date: | Tue, 01 Apr 2008 21:29:31 +0000 |
| Subject: | Re: short_open_tag | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-36759@lists.php.net to get a copy of this message | ||
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