Production mode

Continuing on the theme of security, another idea: having php.ini switch production=On. What it would so is:

• display_errors automatically disabled - or filenames, etc. are removed from error messages
• phpinfo() doesn’t work - this is protection for people leaving debug pages for Google to grab and for automated exploit scritpts to visit then. Maybe too harsh - alternatively - doesn’t work if requestor is not localhost? This might be a problem with insecure URL fopen though.
• expose_php off or stripped to not give out full version
• max_execution_time and memory_limit ensured to not be unlimited
• other things people constantly forget to configure correctly?

php -T

Perl and Ruby have variable tainting. Maybe PHP should have it too?

Approaches for Perl and Ruby are somewhat different. One difference is that in Perl you have some operations that untaint variables automagically, while in Ruby you have always to explicitly declare a variable non tainted anymore.
Also, Ruby has different levels of protection, so tainging can be light nuisance on the low level or full sandbox mode on a high level. That’s another interesting thing ot explore - using tainting to sandbox scripts. 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.

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 one wants to implement proper tainting or sandboxing, it probably should be based on more generic approach that would account for existance 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 - e.g., on some security level function calls to functions not marked “safe for tainted data” with tainted arguments might be prohibited by the engine. 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 test, 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.

This can also be connected to zval custom info idea, as taitning flag is a good example of the custom info.