Security

This topic has come up in the past at some events, within the security team and on drupal.org. Symfony project founder Fabien Potencier posted a proposal for dealing with downstream projects (such as Drupal) at
https://github.com/symfony/symfony-docs/pull/2639/files

This agreement will have an impact on how efficiently and how quickly the Drupal security team can work with the Symfony security team to coordinate security releases in a timely manner. Let's discuss this on github so Symfony and the other projects can be kept in the loop.

A number of WordPress sites are currently suffering from a brute force attack, which appears to be driven by a botnet. The attack tries to brute force the username "admin" by trying different passwords from different IP addresses. This renders IP blacklisting ineffective.

Drupal 7 has a feature known as flood control. The user module uses flood control to monitor login attempts, and will block both an IP address and the account after a number of failed login attempts.

Several hosting companies and WAF (web applicaiton firewall)/IDS (Intrusion Detection System) vendors have asked the security team to provide more details around how to exploit the security vulnerabilities published as advisories. Some of these vendors have agreed to an NDA or other form of quiet period. Our response to the first of these requests is the basis for this post.

The Security Team's basic response is "probably not" but we are open to some variants on this idea. I'm posting this here to see what others think, so please post your perspective below on how to handle it.

Problem: I could not find any documentation about whether Drupal developers should sanitize email bodies and subjects to prevent XSS when the mail is read on a mail client.

I ran into this problem a couple of times, but never found the time to fully explore it. From my understanding it is the responsibility of the displaying email client to make sure that no evil JavaScript is executed in HTML mails. Which means that Drupal should not run filter_xss(), check_plain() and friends before passing data to the message transfer agent.

I think there is sort of a usability issue with the name of this group:

"Best Practices in Drupal Security."

I couldn't find this group in my list of groups in the right sidebar, even though I'm only a member of about 10 groups. I used my browser to search on "Security" to find it.

I've read that people scan the left side of lists.

How about renaming this group, "Security Best Practices." I think we could dump the "Drupal" part to make the name shorter. I think it is understood that at drupal.org the issues relate to Drupal.

What do you think?

Shai

Normally, in Drupal, when a user clicks on a password reset link that they requested from a Drupal site, they are taken to a landing page that has nothing but a "Log In" button that logs them in. The system then expects the user to update their password on their own.

But for infrequent or non-technical users, that last step often never happens. They fail to set their password, and then ask to reset password again the next time they need to access the site.

MY SOLUTION: