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.

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).

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.

Six tips for getting help with your code, because efficient use of volunteer time is key in getting good and timely support. While this is somewhat geared towards Drupal support on the Drupal.org forum and in the #drupal IRC channel, the tips apply to nearly all code you need help with.

1. Post code.
2. State the goal and the problem.
3. Post actual code.
4. Make it short, make it matter.
5. Make it complete.
6. Make it readable.

To more efficiently review code changes in Drupal I've decided to write a little bot that regularly reads the RSS feed of Drupal core commits. It then downloads the referenced patches and creates new content on this site (example) under the category Drupal Core.

As this is a taxonomy term, it comes with the Drupal benefit (tm) of an RSS feed, I now use to quickly review commits to core.

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.

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

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.

Should time permit I hope to work on MyCaptcha 5.2 this weekend.

Planned features:

• Support for recaptcha.
• Configurable location in forms.
• Configurable description on the CAPTCHA.
• A minimal API necessary for recaptcha and to silence the voice in my head screaming for a more flexible API.

I promise MyCaptcha won't be about 'APIs'; I will focus on the "Just Works" principle.

A 1.0 version of the alternative CAPTCHA module, MyCaptcha, has been released for Drupal 5.x.

Features:

• Math CAPTCHA
• Image CAPTCHA
• Can be added to nearly any form, without changing PHP code.

» Download MyCaptcha

For additional information, please see the MyCaptcha manual.

While browsing Drupal Planet as part of my morning 'wake-up' ritual, I wanted to contact the authors of one of those sites about a problem. I wanted to, until my eye fell on the travesty that they call contact form.

Update: MyCaptcha 1.0 has been released.

I've been adding some settings to the math captcha module I created earlier. An important setting is on which forms you want to have a captcha. While it is possible to hardcode the possible forms a captcha can appear on, I've opted for another approach.

I've created two helper modules called Form store and Form collect. If you enable Form collect, it will collect forms on your site while you visit them. You can view the collected forms on the Form store page. In the image below, you can see that I limited the collection to forms I thought useful for Captcha and that I've given most a more readable description. While I intend to include and add a description to all core forms, this has to be done manually for now.

This morning I broke down and wrote a simple math captcha module (for Drupal) to use with user registration and anonymous commenting on this site.

Because this site uses caching for anonymous users, the module needs to make sure that whenever a captcha is displayed, the page is not added to the cache.

I've a few extra scripts in the webroot of several sites to provide me with server information when I need it. These scripts tend to provide too much information to just anyone. Here's how you can quickly limit access to the Drupal admin user (the first user created on the site).

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.

Why, please tell! What are the advantages of illegal software?

Seriously, I feel sorry for them; all the effort spend to 'explain' (market) WGA in the previous screens, only to be undone by a translation error.