Frequently asked questions

Questions and answers commonly asked of the Drupal Security Team.

Anonymous forms vulnerable to CSRF not considered a vulnerability

Drupal core provides CSRF protection to all forms for authenticated users. However, several forms are shown to anonymous users and are not protected with anti-CSRF tokens.

Drupal's anti-CSRF token works by combining information that is secret to the site, the action, and the individual user into a hashed value sent in the HTML of the page. That token must be sent back with the form POST to validate that it is not a CSRF-submission. Generating tokens for anonymous users would require running php code and generating sessions for anonymous users. Most Drupal sites use a page cache built into Drupal and many sites use an HTML cache (such as Varnish) which prevents the generation of a per-user token inside of forms.

The ability to submit a login or search form via CSRF is not itself a weakness. It can be leveraged to make certain kinds of attacks more effective (e.g. a phishing attack).

Fixing this problem could be done in a contributed module. The Seckit module for example offers HTTP Origin header checks on POST requests which is also listed as a measure in the OWASP CSRF prevention cheat sheet. There is also a Drupal core issue to potentially address anonymous form CSRF protection in a future version of Drupal.

Clickjacking is not considered a weakness in core

A vulnerability known as clickjacking allows a malicious user to target authenticated users of a site to trick them into taking actions they do not intend by placing the target site into an iframe. Fortunately, Drupal core protects against cross-domain clickjacking by default, by preventing the site from being embedded in an iframe on another domain. However, in certain situations, Drupal is intended to be placed in an iframe, so this behavior can be overridden if necessary, to either remove or expand the protection.

Drupal sites may need to be placed into iframes under certain circumstances, so the previous behavior of Drupal core (which did not enforce a particular stance on this issue) is not considered a vulnerability.

Additional solutions

If you care about clickjacking on your site the Security Kit module provides several forms of protection against several different kinds of attacks.

As always is the case, site builders are encouraged to evaluate contributed modules prior to deploying them to confirm they are helpful without introducing other security issues.

How do I know what a security issue or risk is?

Before understanding security risks on the web, it may help to first think about what makes a secure site.

From Cracking Drupal chapter 1, the Drupal security book by Greg Knaddison:

A site is secure if private data is kept private, the site cannot be forced offline or into a degraded mode by a remote visitor, the site resources are used only for their intended purposes, and the site content can be edited only by appropriate users.

A security issue allows someone to

• Abuse resources in ways they aren't suppose to
• Steal data from the site
• Alter data on the site

User accounts with un-verified e-mail addresses

There are at least two configurations of Drupal core that can lead to situations where the e-mail address of a user is not a valid nor confirmed address. Note that Drupal core does not allow these setups by default.

If another module outside of core allows for similar situations it is not considered a security vulnerability.

1. Immediate registration without validation of e-mail

Allowing site administrators to configure their site to allow access to users immediately after they register can lead to a security vulnerability; this setup doesn't require validation of the e-mail address so a malicious user could register on a site using the address of someone they wish to send unsolicited e-mails. They could register a second time and use that second user to send contact messages to the first user account. The could then use a second issue to send yet more mails.

2. Registered users can change their e-mail without verifying the new address

Allowing users to change their email address without verification can be used in a similar manner as the first issue. 

How do I protect my site against Brute Force Attacks?

A brute-force attack is an attempt to gain unauthorized access to a website by continually generating and inputting various combinations of a password. This task is usually done by automation software (a "bot") which looks for success or failure messages and keeps trying new passwords until it gets a success message.

Some brute force attacks are based on commonly used usernames. Others are based on identifying the username from one of several methods.

Drupal core includes flood control variables that limit logins by a single IP (default: 50 failed attempts allowed in one hour) and to a single account (default: 5 failed attempts every 6 hours). These variables are not editable through the Drupal core administration pages; the Flood control module adds an interface to change them.