Problem/Motivation

When a contact form's auto-reply message is enabled, spammers can put their message in the "Subject" field, put a 3rd-party email address in the "Your email address" field, and thereby use your Drupal site to send spam to other people. This is a kind of backscatter attack vector.

Steps to reproduce

  • Create a new Drupal 9.2.2 site using the Standard installation profile
  • On Administration > Structure > Contact forms > Website feedback, fill in some "Auto-reply" text
  • Add a CAPTCHA, honeypot, or other abuse protection (which will block some but not all spam attempts)
  • Deploy the site to production
  • Over time, spammers will discover your contact form and start using your Drupal site to relay spam to 3rd parties. Because Drupal populates the auto-reply email subject with the user-submitted contact form content, spammers will use the subject field to send their message to 3rd parties.
  • 3rd party recipients of the auto-reply spam will then report your Drupal site's email address as spam, which will potentially add it to email blocklists, making it less likely that legitimate email from your site will get through to people who actually want to receive it.
Spammer fills out contact form with their message in the "Subject" field, and a 3rd-party email address in the "Your email address" field 3rd party receives unsolicited spam message

Proposed resolution

When the contact form auto-reply is enabled, Drupal should not include user-submitted content in the auto-reply email. Drupal could either use a predefined subject line (e.g. "[contact-form-name] site-name"), or provide a field into which the site maintainer can enter their own subject line. Then, when spammers attempt to use your Drupal site as a spam relay, 3rd parties would still receive unexpected emails, but those emails would not contain the spammer's message — thus removing the incentive for the spammer to exploit your site's contact forms.

Related: If #405338: Contact form: Add token functionaltiy is implemented, it should prevent using tokens containing user-submitted content, or (if tokens containing user-submitted content are permitted and used) show a warning stating that the contact form will potentially be used as a spam relay.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Comments

smokris created an issue. See original summary.

cilefen’s picture

larowlan’s picture

Should this be a private issue? Webform had an SA and private issue for a similar vulnerability

cilefen’s picture

https://www.drupal.org/sa-contrib-2021-004

Webform’s fix is probably the way to go. Lee, I’ve held opposing (with myself) views on spamming an obviously spammable form being public. Your call.

larowlan’s picture

The webform fix was to only mail logged in users.

Perhaps that's what we should do here too. Would require #601776: Remove the ability of registered users to change the sender name or email address in contact forms. too.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

poker10’s picture

Issue tags: +Security

Adding a missing tag.

quietone’s picture

Status: Active » Postponed

The Contact Module was approved for removal in #3476879: [Policy] Move Contact module to contrib.

This is Postponed. The status is set according to two policies. The Remove a core extension and move it to a contributed project and the Extensions approved for removal policies.

The deprecation work is in #3520460: [meta] Tasks to deprecate the Contact module and the removal work in #3520466: [meta] Tasks to remove Contact module.

Contact will be moved to a contributed project after the Drupal 12.x branch is open.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.

andypost’s picture

Project: Drupal core » Contact
Version: main » 1.x-dev
Component: contact.module » Code
Status: Postponed » Active