Security

My company hosts & operates a Drupal 6 instance that's used to host landing pages for a state government authority, and as such it's required to undergo periodic security scans.

At the Boston Drupal meetup that was at Acquia this month, several presentations were focused on "what's new in Drupal 8" from the view of several people who now work at Acquia. I loved it. There were other presentations, as well (including one of my own!), and I really enjoyed seeing the Boston Drupal group again after many months.

During the questions and answers part of the meetup, I asked Dries if he was considering naming a security maintainer for Drupal 6 when Drupal 8 is released. (In case you didn't know, support for Drupal 6 will be discontinued by the Drupal core and security teams. See the handbook page on backwards compatibility at https://drupal.org/node/65922 for more, including Dries' original statement on the subject in 2006.)

So, the fundamental problem: For a site using standard caching (in the database), it's very easy to cause the cache system to write huge numbers of cache entries, being duplicates of cached pages or other cache objects, so rapidly filling disk space. As far as I know there is no protection available against such an attack, other than table size limits in mysql (which is hardly an ideal solution).

In this paper it is reported many PHP applications make false assumption about the true randomeness of the core PHP random funcions and it might lead to attacks, for example using the password reset features. Drupal may also be affected by this e.g. 6 session cookie generation.

If anyone researches this and find Drupal to be actually vulnerable, please report to the security team.

I have a number of smaller clients on Drupal. Since Drupal gets updated more frequently than Wordpress, and since (for 7 anyway; maybe 8 will be different) someone with a certain skill level with Drupal and FTP has to still do core updates, it is an extra running cost that Wordpress, for all intents and purposes, does not have (all updates can be done via the GUI and by the site owner).

Hi Folks,

On a client site, spam comments are being posted. In Watchdog, the IP address of the spammer is: the site's dedicated IP address. How is that possible?

Also note that there is a ReCaptcha challenge on all the comment forms.

Can anyone explain how this could happen?

Thanks,

Shai Gluskin

The discussion here
http://groups.drupal.org/node/9719 consists of a great idea to encrypt RSS feeds of private posts. But the discussion there has been dead and not updated for quite some time.
This says that "
Overview: With Encrypted RSS/Atom feeds, buddylist-like features become possible cross-site. The project would be to develop a module which generates and consumes syndicated feeds, where reading them in only possible behind a login.

Hi,

As part of an effort to expand Drupal-specific static code analysis tests for vulnerabilities underway in Coder 7.x-2.x (http://drupal.org/node/1844870) I am curious of common errors made by developers that open up exploits. What problems are easy to make (and discover) that we can 1) write automated checks for and 2) get those corrected for newer major versions of Drupal core.

Right now, comments are specific to nodes and respect node permissions on overview pages, recent comments block and so on, so that you can't see comments if you can't see the node.

http://drupal.org/node/731724 is making comments entity-type agnostic, so that you can attach comments to any fieldable entity.