3.2. Know Your Attack Surface

The attack surface of a web application is like a guide map for an attacker. It comprises all of the features on your site. Every additional feature, module, permission granted, and configuration you make can add more area to the attack surface, increasing the chances for a vulnerability. In particular, if you change a configuration or add a module without knowing precisely what is happening, it is easy to introduce security weaknesses into your site.

Drupal's core gets reviewed constantly by a range of experts and is one of the major focuses of the Drupal security team. This isn't to say that it's flawless, but at least you can be sure that any weaknesses in core will be fixed quickly. It also has a small total code footprint, and while it handles the most important aspects of functionality, it is less likely to contain problems than contributed modules. Therefore it is important to carefully monitor the contributed modules on your site.

3.2.1. Best Practices for Contributed Modules

Given that you must know your attack surface and that the larger the attack surface, the more area an attacker has to break, it is a best practice to install only contributed modules that you believe to be safe. There are several indicators you can use to determine quickly whether a module is safe:

Is the Module Popular?

The more people using a module, the more certain you can be that one of them has reviewed the code and reported any vulnerabilities to the security team to be fixed. This can also give you comfort that the code will be reviewed on an ongoing basis. You can get a sense of the popularity in conversation by reading the forums and blog posts in the Drupal Planet. You can also use the newly released Project Usage Overview page (see Figure 3-2) at http://drupal.org/project/usage.

Figure 3.2. Excerpt of the project usage list

Is the Module Maintainer Well Regarded?

Even the most experienced coders can introduce weaknesses into their modules, but there is less chance of this happening if the module maintainer is experienced with Drupal. You can learn a lot about maintainers by looking at their drupal.org profile pages and the tracker of issues they are involved in. The length of time they've been members and the more modules and issues they are involved in are all clues that they are more likely to write a safe module.

Has the Module had Security Holes in the Past?

This is somewhat counterintuitive, but if a module has had a security announcement in the past, it confirms that other people are reviewing it and that the module maintainer is at least aware of the need to keep the code secure. Of course, the other side of this is that it shows that the module has had some weaknesses and the maintainer may not know the Drupal API as well as he should.

Does it Pass a Quick Security Analysis?

There are certain functions that are likely to be found in all modules, like db_query(), t(), and l(). If a module uses these at least once, then you can be fairly sure that the maintainer is using the Drupal API and knows what he is doing. In the next section I'll provide rules for this quick check. If the module does not pass, you should dig a little deeper.

Does it Pass a More Complete Security Analysis?

While it can take a large amount of time, the best way to know the status of a module is to review it line by line and try to find holes in it from within the browser using both manual and automated scanning tools.

3.2.2. Performing a Quick Security Scan

After reading this book you'll be well equipped to make a line-by-line security scan of a module, but that can be time consuming. You can do a quick scan to see if a module is safe or not by looking for a few key characteristics. Look for the proper use of common Drupal API components like t(), l(), check_plain(), filter_xss_admin(), and db_query(). For t() and db_query() make sure that the module uses placeholders like %user-name instead of simply concatenating a variable into the string.

By simply limiting the number of contributed modules and choosing those modules wisely, you can greatly reduce the attack surface and be confident in the security of the attack surface that remains.