PHP, Perl, Ruby Variable Tainting
Approaches for Perl and Ruby are somewhat different. One difference is that in Perl you have some operations that untaint variables automatically, while in Ruby you have always to explicitly declare a variable non tainted anymore.
Also, Ruby has different levels of protection, so tainting can be a nuisance on the low level or full sandbox mode on a high level. Though in PHP due to the fact that all runtime data are isolated per-request and the engine is built to support multiple requests, it might be easier to implement sandboxing in a different way, but the Ruby approach is interesting to explore, the author writes.
Of course, due to the multitude of functions in PHP the approach of ‘mark unsafe functions’, which Ruby seems to use is prone to the same failures as the safe mode—there’s always at least one function that isn’t properly restricted. So if you want to implement proper tainting or sandboxing, it probably should be based on more generic approach that would account for existence of functions unknown in design time. It’s still not 100% as carefully miswritten extension can do anything the OS permissions allow C code to do, but some restrictions might still be done. For example, on some security level function the engine might prohibit calls to functions not marked ‘safe for tainted data’ with tainted arguments. That’d probably break 99% of the existing code, so it would come at cost in any case. But the benefit would be that once the application passes such tests, we can reasonably claim certain level of security not 100% security, but at least decent level of protection for people that do not remember to validate their data properly
