Articles

Hiding the fact your site runs Drupal OR Fingerprinting a Drupal Site

I often see questions about how someone can "hide the fact that their site runs Drupal" or "remove the meta Generator header." People often want to do this because they feel it will make their site more secure: if the attacker doesn't know I'm running Drupal then they will have one less piece of data about what attack methods might work. People say that an automated attack script that detects Drupal sites might not find me and therefore might not attack me.

What are Full Disclosure and Responsible Disclosure

A debate has been going back basically as long as software: for security bugs is it better to follow Full Disclosure or Responsible Disclosure?

A great article on the topic comes form Bruce Schenier's Crypto-Gram way back in 2001.

Creating a "read only" Drupal front end with dynamic content management

While many Drupal sites and site-builders focus on creating interactive sites where anonymous and authenticated users can interact with the content to varying degrees, there are still some environments and sites where a "static" version makes more sense for most of the public.

The main benefits are:

  • more confidence that your site cannot be "hacked"
  • in some cases performance improvement (since Drupal's dynamic features are removed).

There are at least three strategies to achieve this, which can be mixed/matched as appropriate.

How to become a Drupal security expert

I use the term "expert" with some hesitancy. There are simply so many elements to becoming an expert in web application security that it's hard to list them all. However if someone does all these things then they are well on their way to becoming an expert in Drupal security.

Managing Patches & Getting your Drupal patch accepted

When creating complex Drupal sites it is often necessary to create patches to modules or Drupal core. Those patches should be managed locally in an organized fashion and contributed up stream. Once they are contributed to an issue queue on Drupal.org your job is not done: it needs to be committed before you can stop worrying about it.

Using the Vuln Module to identify cross site scripting in Drupal

One of the biggest security threats in Drupal is Cross Site Scripting (XSS). So it's no surprise that a lot of the tools built for analyzing security in Drupal sites look for XSS.

Jeff Miccolis created a module called "vuln" - hosted on github. The description in the info file lets us know it is a "XSS vulnerability detection feature" but how does it actually work?

Let's try out a module see what it can do.

Using Hacked! module to compare Drupal site code to standard code

One of the first things we do when supporting a site or reviewing it for security is look for modifications to the code.

We use the Hacked module to achieve this because it works quickly and automates a lot of the work in what is a normally very tedious process.

Here's some basic usage:

Contributed modules for Securing your Drupal Site

Among the thousands of modules on drupal.org there are over 100 in the security category. Unfortunately some of those are abandoned or inaccurately tagged. We've looked at every module and compiled this resource to help you understand the security-related community modules available. Not all modules provide security exactly, some are about hardening your site against weaknesses and others are about monitoring and reporting abuses.

Counting Lines of Code

When we get a new customer interested in the Drupal Scout Custom Security Review we will ask them for some metrics about their site to help us understand how much work we think it will be to review their site. We general ask:

Automated Security Reviews for Drupal

These are the slides for a presentation on Automated Security Reviews I'm doing at Drupalcamp Colorado. You may also be interested in Steps to a Drupal Security Review.

Pages