View source for LII:Web Application Security Guide/PHP-specific issues

{{TOC right}}
==PHP-specific issues==
When using the PHP language, several issues need to be considered.

===When using PHP...===
* Do not use the short form “<code><nowiki><?</nowiki></code>”, always use the full form “<code><nowiki><?php</nowiki></code>” 
* When using the nginx web server, make sure to correctly follow the '''official''' installation instructions and pay attention to the [http://wiki.nginx.org/Pitfalls#Passing_Uncontrolled_Requests_to_PHP "Pitfalls" page]. Beware of tutorials that often contain working but insecure configuration examples.
* <code><nowiki>preg_replace</nowiki></code> can act as <code><nowiki>eval()</nowiki></code> in certain cases. Avoid passing user input to it. If you must, correctly filter and escape it.
* Use the [http://www.hardened-php.net/suhosin/ Suhosin] (including the patch, if possible) and configure it with strict rules
** Enable <code><nowiki>suhosin.executor.disable_emodifier</nowiki></code>
** Enable <code><nowiki>suhosin.executor.disable_eval</nowiki></code> if possible
** Set <code><nowiki>suhosin.mail.protect</nowiki></code> 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 "<code><nowiki><?php</nowiki></code>" and "<code><nowiki><?</nowiki></code>" alone can start a PHP code block. However, if the option is disabled, "<code><nowiki><?</nowiki></code>" 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 [http://wiki.nginx.org/Pitfalls#Passing_Uncontrolled_Requests_to_PHP "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.

<code><nowiki>preg_replace</nowiki></code> 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, <code><nowiki>preg_replace</nowiki></code> allows arbitrary code execution. Be extremely careful when using this function, use <code><nowiki>preg_quote</nowiki></code> ''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.

[http://www.hardened-php.net/suhosin/ 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 [https://suhosin.org/stories/feature-list.html feature list] for a complete list of features and the [https://suhosin.org/stories/index.html 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 [https://suhosin.org/stories/configuration.html#suhosin-simulation simulation mode] first to discover (badly coded) applications that use it. Setting <code><nowiki>suhosin.mail.protect</nowiki></code> can prevent attacks that use your mail forms to send spam. (Again, use [https://suhosin.org/stories/configuration.html#suhosin-simulation simulation mode] first to determine if your applications are compatible with it.)

Magic quotes have been removed in PHP 5.4. An appliction 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.

==Notes==
The original source for this page is [https://en.wikibooks.org/wiki/Web_Application_Security_Guide/PHP-specific_issues the associated Wikibooks article] and is shared here under the [https://creativecommons.org/licenses/by-sa/3.0/ CC BY-SA 3.0] license.