CHAPTER 21 ■ WRITING SECURE CODE

$items['insecure'] = array( 'title' => 'Insecure Module',

'description' => 'Example of how not to do things.', 'page callback' => 'insecure_code',

'access arguments' => array('access content'),

);

return $items;

}

It’s important to question who is allowed to access this callback. The “access content” permission is a very general permission. You probably want to define your own permissions, using hook_permission(), and use those to protect your menu callbacks. Permissions are unique strings describing the permission being granted (see the section “Access Control” in Chapter 4 for more details).

Because your implementation of the menu hook is the gatekeeper that allows or denies a user the ability to reach the code behind it (through the callback), it’s especially important to give some thought to the permissions you use here.

Cross-Site Request Forgeries (CSRF)

Suppose that you have logged into drupal.org and are browsing the forums there. Then you get off on a tangent and end up browsing at another web site. Someone evil at that web site has crafted an image tag like this:

<img src="http://drupal.org/some/path">

When your web browser loads the image, it will request that path from drupal.org. Because you are currently logged in to drupal.org, your browser will send your cookie along with the request. Here’s a question to ponder: when drupal.org receives the request, will it consider you a logged-in user with all the access privileges you’ve been given? You bet it will! The evil person’s image tag has essentially made your user click a link on drupal.org.

The first defense against this type of attack is to never use GET requests to actually change things on the server; that way, any requests generated this way will be harmless. The Drupal form API follows the HTTP/1.1 convention that the GET method should not take any action other than data retrieval. Drupal uses POST exclusively for actions that make changes to the server (see www.w3.org/Protocols/ rfc2616/rfc2616-sec9.html#sec9.1).

Second, the form API uses tokens and unique IDs to make sure that submitted form values from POST requests are coming from a form that Drupal sent out (for more on this, see Chapter 11). When you are writing modules, be sure to use the form API for your forms and you will gain this protection automatically. Any action that your module takes as a result of form input should happen in the submit function for the form. That way, you are assured that the form API has protected you.

Finally, you can also protect GET requests if necessary by using a token (generated by drupal_get_token()) in the URL and verifying the token with drupal_valid_token().

File Security

The dangers faced by Drupal when handling files and file paths are the same as with other web applications.

478

CHAPTER 21 ■ WRITING SECURE CODE

File Permissions

File permissions should be set in such a way that the user cannot manipulate (add, rename, or delete) files. The web server should have read-only access to Drupal files and directories. The exception is the file system paths. Clearly, the web server must have access to those directories so it can write uploaded files.

Protected Files

The .htaccess file that ships with Drupal has the following lines:

# Protect files and directories from prying eyes.

<FilesMatch "\.(engine|inc|info|install|make|module|profile|test|po|sh|

.*sql|theme|tpl(\.php)?|xtmpl)$|^(\..*|Entries.*|Repository|Root|Tag|Template)$"> Order allow,deny

</FilesMatch>

The Order directive is set to allow,deny, but no Allow or Deny directives are included. This means that the implicit behavior is to deny. In other words, reject all requests for the files shown in Table 21-2.

Table 21-2. Files Rejected by the FilesMatch Directive’s Regular Expression in Drupal’s .htaccess File

479

480