Web Application Security Guide/PHP-specific issues

When using the PHP language, several issues need to be considered.

When using PHP...

• Do not use the short form “<?”, always use the full form “<?php”
• When using the nginx web server, make sure to correctly follow the official installation instructions and pay attention to the "Pitfalls" page. Beware of tutorials that often contain working but insecure configuration examples.
• preg_replace can act as eval() in certain cases. Avoid passing user input to it. If you must, correctly filter and escape it.
• Use the Suhosin (including the patch, if possible) and configure it with strict rules
  • Enable suhosin.executor.disable_emodifier
  • Enable suhosin.executor.disable_eval if possible
  • Set suhosin.mail.protect to 2 if possible
• When updating PHP to PHP 5.4 from an older version, ensure legacy applications do not rely on magic quotes for security.

Rationale

PHP can support shortened PHP code start tags. If the option is enabled, both "<?php" and "<?" alone can start a PHP code block. However, if the option is disabled, "<?" will not be detected and the code will be delivered to the browser instead. This can lead to code disclosure. Using the full form ensures that the code will work correctly and won’t disclose the code if the server does not support short tags.

When using the nginx server, it is very easy to make critical configuration mistakes that allow users to pass image files to the PHP interpreter. See the "Pitfalls" page for mor information. It also provides valuable tips that will probably save you some time hunting down phantom issues, so you should read it if you use nginx.

preg_replace evaluates the replacement text as PHP code if the non-standard "e" modifier is given in the search RegExp. If an attacker can influence the RegExp to add this modifier and provide a custom replacement text, preg_replace allows arbitrary code execution. Be extremely careful when using this function, use preg_quote with a correctly set delimiter parameter for escaping when possible. If you must accept RegExp code from the user, ensure it cannot contain the delimiter (also consider attacks using malformed UTF-8, null bytes etc.) - but if possible, avoid it completely.

Suhosin can prevent certain attacks on web applications and disable insecure functions. The patch also protects internal memory structures against certain memory corruption attacks. (Also see the feature list for a complete list of features and the official explanation why Suhosin is useful.) Suhosin improves your security, but like Web Application Firewalls, it does not magically make all applications secure.

Disabling the e modifier prevents the above-mentioned vulnerabilities in preg_replace from being used by an attacker even if an application is vulnerable. The e modifier should never be used, an application that does not work with the e modifier disabled is broken. Banning eval may break legitimate applications. Consider running Suhosin in simulation mode first to discover (badly coded) applications that use it. Setting suhosin.mail.protect can prevent attacks that use your mail forms to send spam. (Again, use simulation mode first to determine if your applications are compatible with it.)

Magic quotes have been removed in PHP 5.4. An application that relies on them for security will become vulnerable if the update is installed. Note that this does not mean you should not update; instead, you should fix (i.e. rewrite or delete) the application. Magic quotes are not a suitable way to escape input and in most cases will not protect against all attack vectors. An application that relies on magic quotes is probably ancient and/or written without security in mind. Simply adding code that will emulate magic quotes is a bad idea.