Planet Drupal

We've talked about Cross Site Scripting (XSS) before, and for good reason, it's a risk far too many sites are vulnerable to. XSS is scary because it runs in the context of the trusted relationship between your browser and a website; XSS can do everything you can do.

XSS cookie theft

Let's look at another example of an XSS exploit: stealing administrative access to a site.

• An attacker will enter Javascript that steals the visitor's browser cookie

First things first, please take this survey about Security in Drupal.

Much like at last year's Drupalcon in San Francisco, Ben Jeavons and I will be giving a training about Drupal and Security. When we gave this course at Drupalcon San Francisco, 88% of survey respondents said they would take the class again! We took all the feedback from last time and are working to make the experience even better.

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.