Preventing execution of untrusted PHP

Last modified: November 19, 2009 - 18:09

It is important to understand the implications of allowing a Drupal user to execute PHP.

This usually happens when a user can type PHP code into a form, submit the form, and have that PHP run on the server.

Note, the Security Team security policy identifies a number of permissions which can allow full site takeover. "Administer Users" permission is discussed further down the page.

The damage

PHP can be used to modify a Drupal site. When it is executed on the server, PHP runs as the same user that the webserver runs as. This user (often www-data) will be able to delete or modify files in the websites "files" directory.

PHP can also be used to modify the Drupal database itself. In this way tables can be deleted, node content can be modified, and user details can be changed. There are a million ways to take control of a site when PHP can be executed.

Even with many secured servers, it may be possible to scan the server for additional files. If you can read the settings.php file of another Drupal installation, then you will be able to access it's database as well. (See Configuring Apache and PHP ... for suggestions on how to use the open_basedir directive to lock this down.)

A frequent goal of a hacker is to use your server to send spam. Gaining access to PHP will allow the user to send emails at will.

Ways PHP can be executed

Modules provide the ability to execute PHP. And those modules should always allow you to limit access to trusted roles (or even just to user/1). If you discover a module that allows PHP, without appropriate warnings and control, you should avoid using this module, or consider creating a bug report on this module.

Common modules that provide PHP:

  • Drupal core ships with the PHP filter module. Providing this filter will allow injection of PHP into a node body. The PHP will be executed when the node is viewed.
  • Devel module provides an execute PHP block
  • Various CCK fields and options
  • Various Views options, like argument handling
  • Webform

Gaining access to PHP

Be aware of the following ways that a user might gain access to PHP execution.

  1. Most obviously, user/1 can install PHP modules and then execute PHP - being unrestricted by permissions.
  2. Giving a user Administer Permissions will allow them to give themselves permission to install modules, and so on.
  3. Giving a user Administer Users will allow them to edit user/1, change the email or password, and hence log in as user/1.

A note about "Administer Users"

Many Drupal implementations need to allow a user, for example an office administrator, to be able to create accounts for other users. This is unavoidable for many real-world projects, and also problematic as we have seen it allows those users to become user/1.

You might consider these additional modules to lock down your site against these exploits:

  • User Protect will prevent deletion and editing of various fields.
  • Paranoia mainly blocks PHP filter module from being installed.
 
 

Drupal is a registered trademark of Dries Buytaert.