Planet Drupal

Cross Site Scripting (XSS) is the number one vulnerability in Drupal code¹ and one of the scariest forms of exploits, because anything you can do XSS can do better².

More serious than <script>alert('xss')</script>

During XSS demos and vulnerability testing it's easy to use some code like <script>alert('xss')</script> to see Javascript executed where it shouldn't be. But an alert box isn't scary.

Recently Justin Klein Keane posted information about a vulnerability in the Context Module for Drupal.

Justin included information about mitigating factors:

In order to execute arbitrary script injection malicious users must have 'Administer blocks' permission.

Here are some more concrete steps for mitigation of this particular vulnerability.

1. Ensure only trusted roles have the "Administer Blocks" permission

People often want to create a backup copy of their site database and give it to someone else to create an environment similar to the live environment for testing or development. However, doing so exposes all of your site data being leaked if that backup copy is ever placed on a CD that gets lost or a harddrive which is not destroyed at the end of its life or a laptop which is stolen.

There are lots of great resources online about how to secure your Drupal site. The CrackingDrupal.com site is meant to be one of those resources, but there are also others available elsewhere. Here are some of the best resources available from around the internet with Drupal specific security information.

Drupal.org Handbooks

The Drupal.org handbooks are probably the most natural place to look and in fact they have three great areas of resources.

Cross Site Request Forgeries (CSRF) are the 3rd most common vulnerability in Drupal and yet they are quite easy to protect against. The precise solution depends on where the problem is, but is never too complex to implement. To start, of course, we need to understand what CSRF actually is.

What is Cross Site Request Forgery - CSRF

Rethink your roles

When discussing site security we often use words like "attacker", "malicious user" or "untrusted" to define site visitors who may be intent on abusing resources, stealing, or altering data. Within Drupal, visitors can achieve these goals using the permissions granted to their roles. This is the key component. We have to think of visitors in terms of what roles they have and what permissions we've granted those roles. Then instead of just thinking about trusted vs. untrusted users, we are thinking about trusted vs. untrusted roles.

This past Thursday several hundred folks joined me for a webinar about security in Drupal as part of the Acquia webinar series.

You can now download the Security in Drupal introduction slides which include the speaker's notes and watch the screencast itself:

This coming fall we'll be talking about security in Drupal so much I can barely believe it.

Acquia Webinar - October 8th online

First up is an Acquia Webinar, which will be a review of security in general and then we'll show two common mistakes that cause the majority of the problems in Drupal sites and modules. The talk will discuss the topic area broadly covering the perspectives of business users, technical users, and developers.

As a developer there is often a point in your career where you take a look at the number of client databases installed on your hard drive and start thinking "boy, I hope that data never falls into the wrong hands." And, if you're like most web developers and use a laptop, the chances of having a laptop lost or stolen are surprisingly high. It happens to the best of us.

Further, chances are quite good that you are using Windows or Mac for your working environment but want to run your sites in a Linux environment just like you have on your servers.

As Matt Cheney likes to say "Much like Scrabble, the S is an important letter on the internet." If you really care about the data you are sending across the internet you want to make sure you are using SFTP instead of FTP, SSH instead of Telnet, and HTTPS instead of HTTP. So, within a Drupal site how can you use HTTPS to secure the data sent to and from your site and prevent sessions from being hijacked?