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?
About these ads

6 thoughts on “Production mode

  1. Pingback: PHPDeveloper.org

  2. Interesting, but I don’t think it will work. For one thing:

    max_execution_time and memory_limit ensured to not be unlimited

    OK, so you ensure it not to be unlimited, but what value should it be then? Do you not allow any php execution until non-unlimited values have been entered? That won’t work.

    I think it will, as mentioned before, just lead to confusion. People that turn this setting on that then think they are safe. And of course, that simply isn’t the case.

  3. Meta-settings like “production” seem like they would be confusing to users and allow security ignorance to persist. What if you set both production and production-affected settings in php.ini?

    I’ve wondered about this myself while building a configuration system, and I think the way to go about it would be some sort of import/include mechanism that simply inlines another ini file in where the import was. That way, it’s clear which setting takes precedence: the later one, and you can always freeze the files if there’s an incompatible change. Might murder performance though.

    Related note: PHP already ships with a php.ini-recommended, which covers some of the issues, but not all of them (it explicitly sets error reporting to E_ALL).

  4. Its a good idea for beginners but experienced users like myself don’t forget to turn everything off.
    The thing with phpinfo() is interesting I think users should not make it public (except hosting sites) or at least use a .htaccess and allow only certain IPs.
    Another problem with not exposing PHP will be the statistics problem, we wouldn’t know what is the adoption of PHP5 and others but it will prevent exploits.

  5. Meta-settings like “production” seem like they would be confusing to users and allow security ignorance to persist. What if you set both production and production-affected settings in php.ini?
    Also, remember the definition of production would most definitely change at some point in PHPs future so that it would break some applications. Or if it didn’t change, it would simply become worthless because you’re not going to get everything on the first try.

    Instead why not default to ridiculously safe settings and not even allow dangerous/stupid settings like display_errors in php.ini? There’s no reason for even a development box to have that globally enabled. It should only be called conditionally within applications if they’re in some sort of debug/development mode. Of course the other settings you mention usually do have legitimate global uses…

Comments are closed.