E-commerce security checklist

Question

I work with LAMP based web sites, particularly Drupal, and was wondering if anyone knew of a good security checklist to help audit new and existing commerce sites for security vulnerabilities?

Cheers.

Answer 1

The best resource for web application security is undoubtedly the OWASP Top 10 . OWASP is a not for profit, technology agnostic organisation dedicated to improving web application security. They produce a document titled "The ten most critical web application security risks" which is very easily consumable and should cover each of the angles you need to understand for an e-commerce app.

I suggest reading through each of the Top 10 carefully (the PDF version is very handy - 1 risk per page), understanding the risk and the impact and then ensuring you know how to mitigate this appropriately in PHP. Good luck!

Answer 2

Database logging row limit (admin/settings/logging/dblog)

I have found the default row limit of 1000 can wrap quickly, leave you without vital debugging information when you need it most. The average row length is generally around 1kB, so even boosting this to 100,000 rows will still leave you with a manageable watchdog table.

User registration settings (admin/user/settings)

The default value of Visitors can create accounts and no administrator approval is required is easily overlooked, and often undesired.

Disable devel modules admin/build/modules

Not only devel itself, but other other utilities (such as masquerade, trace, or coder) may have been installed that you wouldn't need on the production site. Leaving extra modules enabled can hinder the performance of your site, or even create security vulnerabilities if misconfigured.

Set a maintenance theme (settings.php)

By default Drupal's Site off-line page uses the Minnelli theme. Switching this is a nice enhancement, in case you ever need to use the maintenance mode, or in the unfortunate event you experience unplanned downtime. In most cases your site's theme will work fine; just add $conf['maintenance_theme'] = 'mytheme'; to settings.php. You may also need to add a maintenance-page.tpl.php to your theme; if you're using Zen this is already done for you.

Confirm email settings

Often, placeholder email addresses will be filled in during development, and should be updated before deployment. I try to start with the correct addresses from the beginning when possible, but sometimes you don't have this information until later in the project's life. In addition to Drupal's global site_mail, addresses can be stored in a variety of places: The admin user's account, contact forms, webforms, ubercart, triggers, or CiviCRM settings.

For Zen users – disable theme registry rebuilding (admin/build/themes)

If you developed your theme using Zen, don't forget to switch off Rebuild theme registry on every page. This is a huge performance penalty.

Error reporting (admin/settings/error-reporting)

On a production site, it's best to suppress on-screen error reporting by choosing Write errors to the log.

Performance settings (admin/settings/performance)

The best performance settings depends on your site. Also, don't change cache settings at the last moment without thoroughly testing your site's features. Ideally, I like to finalize the cache settings about 2/3 of the way through a project, so that the final stages of development and testing are performed with cache settings that will match production.

Redirect to/from 'www.*' (.htaccess)

Drupal's .htaccess file contains an example RewriteRule showing how to redirect from example.com to www.example.com or vice-versa. Enforcing a single domain name is essential if your site uses SSL, and even with plain HTTP I like the consistency of a single URL. Additionally, since the RewriteCond declaration is specific to a particular host, you can add multiple domains to the same .htaccess file, either for multi-site installs or for multiple testing / production host names.

Check proxy settings

If your production server uses a proxy or load balancer, Drupal needs some additional configuration to accurately record remote IPs. This impacts error logging and some modules such as Mollom.

$conf['reverse_proxy'] = TRUE; $conf['reverse_proxy_addresses'] = array( '10.10.20.100', '10.10.30.100', );