Re: short_open_tag

From: 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

« previous php.internals (#36759) next »