Drupal spam/security meeting (May 14, 2014)

Date: 
Wednesday, May 14, 2014

Security and Spam Mitigation in Drupal-land  - Margrit McIntosh

1. Let's start with spam.

You can't get spam if you don't allow anonymous users to create content or accounts on your site. However, in many cases, you DO want anon to make stuff:

  • comments
  • webforms
  • contact us form
  • under certain circumstances you might for a limited time allow users to create their own accounts.

If you allow users to create their own accounts, you should require email verification. Also consider LoginToboggan, which allows immediate login and assignment of a role (such as: pre-validation) that does not have any permissions. Following email verification, use a Rule to assign a different role.

https://drupal.org/project/logintoboggan

https://drupal.org/project/rules

You'll still get spam accounts, but not as many as if you don't require email verification.

Also, you can protect the /user/register form with a spam-mitigation module, such as:

  • CAPTCHA and reCAPTCHA - the squiggly letters we all know and loathe
  • Mollom - a web service that analyzes content posted to your website
  • Honeypot - hidden form field attracts bots


CAPTCHA and reCAPTCHA
https://drupal.org/project/captcha
https://drupal.org/project/recaptcha

  • fairly effective
  • you're contributing to the digitization of books and other documents
  • extremely annoying to your users
  • not accessible to impaired users

Mollom -- https://drupal.org/project/mollom

Honeypot -- https://drupal.org/project/honeypot

  • seems to be quite effective
  • unobtrusive

2. OK, now more generally about security.

Let's look at a typical log, shall we?


This is mainly just to demonstrate that your site is constantly under attack. Any Drupal site with some traffic will get a constant stream of attempts at user/register and node/add. Woe unto you if these are allowed on your site! Unskilled probes -- such as those looking for a wordpress admin login -- aren't terribly worrisome, and of course what you see in the log are the probes that were successfully repelled. It's the ones that DON'T results in a page-not-found or a access-denied, and that you don't see in the log, that you have to worry about.

What's wrong with letting users create their own accounts? Nothing -- if those accounts don't have any permissions that Anonymous doesn't have. But then why do they need an account?

Content author - what happens to the "authored by" bit if you delete the account? D6, content then became owned by user 0 - anonymous. D7 offers various other options.
See: https://drupal.org/node/1732920

How to read a Drupal security release:
some samples:
https://drupal.org/node/2254853
https://drupal.org/node/2254925
core:
https://drupal.org/SA-CORE-2014-001
https://drupal.org/SA-CORE-2013-001

Drupal Security Levels explained: https://drupal.org/security-team/risk-levels

Other security notes:

  • Drupal documentation page: Securing your site
    https://drupal.org/security/secure-configuration
  • a helper module: Security Review https://drupal.org/project/security_review (but this module isn't currently correctly handling the recent security changes to the .htaccess files)
  • server-level file permissions
  • the permissions table
  • if you custom program your own forms, make sure you understand the security issues
  • DON'T ALLOW ANONYMOUS USERS TO CREATE NODES. PERIOD.
  • if you use CAS, keep your CAS library up to date.
  • Other libraries: be sure to remove the /demo/ or /docs/ folders within these libraries if you don't absolutely need them.
  • if you don't use CAS, get an SSL certificate to encrypt your login page
  • Don't store sensitive information or personally identifiable data on your Drupal site.

Most Drupal sites are not terribly vulnerable, unless:

  • you never apply security patches
  • you don't keep libraries pruned and up to date
  • no oversight: no one looks at the site or checks how it's doing on a regular basis
  • you do stupid things like allowing anonymous users to create nodes

Tangent: We had a question about what the various PCI levels are. From Gil @ ISO:

  • SAQ A is the level where it involves hosted order pages that link to third party vendors (cybersource). This level does not collect, transfer or process any credit card data. That is done on the vendor page., all cardholder data functions outsourced.
  • SAQ B does not use webpages.
  • SAQ C is the unit that process credit card data via web, Point of sales, etc (Bookstore, Student Union) but they do not store the Credit card data. It is deleted immediately after processing to third party vendors. 
  • SAQ D (UA has none) is full PCI vendor, stores the data and processes it.