Heine

On March 2^nd 2012, security researcher Ivano Binetti published an advisory on Drupal 7 anti-CSRF measures. He/She rightly identified the long standing Logout CSRF annoyance (#144538), but the rest of his/her advisory is not helpful.

De Opinie in de Arts & Auto (Feb 2012) —een uitgave van de Vereniging voor Arts, Kwakzalver & Auto (VvAA)— verwijst naar een publicatie van Dewey over het homeopatisch behandelen van Influenza in 1918.

Na enig speurwerk heb ik een kopie gevonden en bijgevoegd voor geïnteresseerden.

Specifications should be a major part of the foundation we built on. Unfortunately, we're a bit loose with our adherence to specs. (Writer is guilty too).

While this was written before, I've decided to use it as a short illustration to #1109854 - Overly aggressive transliteration in drupal_clean_css_identifier on the difference between HTML and CSS with regards to 'allowed' characters.

Best to skip if you don't care about specifications ;)

Today we released a security announcement about a Webform SQL Injection vulnerability outside of the normal release schedule on Wednesday.

I chose to release today with a minimal fix instead of waiting until January 12th for a combination of reasons:

1. The vulnerability was made public.
2. The injection requires no permissions at all.
3. High impact; easy uid 1 access.
4. No other user interaction required.
5. Webform was under high scrutiny last week due to the Geenstijl shockblog.
6. We received news today that the hole was being actively exploited.

This combination could turn out to be very damaging for a lot of Drupal sites should we have waited longer.

Versions

To clear up any confusion regarding the affected supported branches; only Webform 6.x-3.x is affected. Users of Webform 6.x.3.x should upgrade to Webform 6.x-3.5.

The Webform 6.x-2.x versions are not affected by this vulnerability. As long as you use 6.x-2.8, 6.x-2.9 or 6.x-2.10 you're good. Older versions of the Webform 6.x-2.x branch have different vulnerabilities that were already announced.

Webform for Drupal 5.x and the 7.x betas are not supported by the security team.

Apart from PHP bugs and Denial of Service attacks, there's another reason why calling unserialize on user-supplied data (cookies, hidden form fields) is a bad idea.

We recently received a report by "ZeroDayScan", about a "Full path disclosure bug in Drupal 6.16".

You can read the story @ http://blog.zerodayscan.com/2010/04/full-path-disclosure-bug-in-drupal-616.html. As my short comment was removed from the post, I have to resort to a blogpost. My apologies for polluting the Planet.

Summary of the issue: If you set error reporting to the default value "Write errors to the log and to the screen", the installation path is displayed on the ...*drumroll*... screen.

Which is of course the point.