Best Practices in Drupal Security

There has recently been a publication of a path disclosure issue in Drupal with the title "Drupal 7.14 <= Full Path Disclosure Vulnerability"

As a response to this and the entire class of issues (that our error messages are optimized for usability over security) I've posted this faq entry: Information disclosure in error messages not a weakness (Path disclosure, SQL error messages, etc.)

Please help improve that page to provide any additional, useful guidance.

SA 2006-006 makes it impossible to execute php inside the Drupal files directory on Apache servers. This is a defense in depth mechanism along with things like file_munge_filename and file extension limits in php.

Windows doesn't benefit from that change since the change was in .htaccess.

Is there a way to prevent IIS from executing files inside a specific directory? Is there some way we can bundle that up and ship it with Drupal like the web.config?

I manage numerous Drupal sites, and have run into a kink in my procedure that I'd imagine many others share. Many people have their sites notify them whenever a security update applies to them, and promptly install that security update. Generally that's a good practice, and leads to relatively stable and secure sites.

I just read this article on forbes: shopping for zero days which points out that bounties for bug reports are less valuable when the black market is willing to pay much more money for the issue.

Of course I hope that people will always report security issues to security@drupal.org and work with that process to fix issues it's an interesting read, nonetheless.

Several sources are publishing a supposed vulnerability in Drupal. One source is the security site Packet Storm Security and attached here. This post is a response to that issue.

Summary

The Drupal Security team has concluded that this does not constitute a valid vulnerability. The attack depends on a "Man In the Middle" attack or sniffing software, which is outside of Drupal and presents a much bigger risk.

http://drupal.org/project/tinyids

After several conceptual changes, I finally created a first dev release.

It's still under development but I would really appreciate deep code and functionality reviews on the current state.
Feel free to express your opinion and discuss about the general implementation in the issue queue.

regards.

The slides and videos from Appsec USA are now online: http://www.appsecusa.org/schedule.html#slides_video

Lots of them seem interesting. I'm currently watching the one on bounties (pdf and video).

Any others that seem interesting to you?

Hello,

My name is Manu Cuche. I am currently in my third (and last) year of computer science at Lessius Mechelen College. I have recently started working on my final project. For this project I have chosen the subject of security in Drupal, more specifically about separating administrator content from user content. I understand that this is a known issue in Drupal, and my first goal is to properly understand and define this issue. To do this I would like to ask for your help.

When a module maintainer is not communicating/fixing a security issue in a timely manner the security team needs to communicate about the problem in the module to site owners.

• We send an SA which gets picked up by rss readers and e-mail subscribers and twitter
• We unpublish the module releases so that the update.module will notify site owners that support for a module in use on their site has been revoked, this then notifies them to visit the project page for more information so...