Steps to a Drupal Security Review

As we developed our security review offering we came up with this outline. We don't follow all the steps on every site because sites sometimes have specific concerns that we want to address before the general set. But this is our exhaustive list of steps. Note that this is only about the Drupal portion of the stack. There is an array of things you could also analyze at the webserver, database server, operating system, network and even data center levels of the stack.

The first are relatively simple to perform. The last three (manual review, and putting it all in a report) are the hardest.

Steps to review a Drupal site's security

Automated or semi-automated steps:

• Santize the database, remove all e-mail addresses, remove passwords, etc.
• Install one or more of mail_logger, reroute_email, advanced_mail_reroute, maillog so that your testing won't accidentally send mails.
• Is core modified anywhere? Are their contribs modified anywhere? check with Hacked!
• Are those modifications documented somewhere or just modified? Ideally patch files should exist somewhere like /sites/example.com/patches/ or in the module directory itself with a Drupal.org issue number and comment number as part of the patch name).
• Install Security Review module on the live site and local site and make sure it passes
• Use a stronger than normal rainbow table to find anyone who has an advanced role and a weak password (See this issue for some related work).
• Run Coder Security on all contributed modules and custom code
• Run Secure Code Review on contributed modules and all custom code

Manual steps:

• Install vuln and browse the site as a human
• Interview the client: What does the site do? What can users do on the site? What content can they post, what fields can they edit? Based on those interviews
• Probe the site, entering fuzz content and/or Javascript
• Manually review the custom theme
• Manually review custom code

The manual review is based on knowledge of secure coding practices. That can be gained from reading the handbook and reading Cracking Drupal.

Suggestions and report:

• Suggest SSL, especially for logins and admins, if they run a site where that is worth it
• Suggest OpenID (part of core), Janrain Engage, etc. so that credentials like username/password can be remembered once and used on multiple sites.
• Prepare report for issues including
  • a narrative describing the above process
  • prioritized vulnerability list with severity and estimated difficulty to fix
  • reference material describing vulnerabilities found (e.g. what is XSS?)
  • screenshots of vulnerabilities where applicable
  • a general assessment of the site

Originally posted on drupalscout.com