Remove the ability of registered users to change the sender name or email address in contact forms.

Created on 11 October 2009, over 15 years ago
Updated 1 October 2024, 5 months ago

Problem/Motivation

The contact form allows users to change the name and mail fields. This can be considered a security issue in that recipients of the message may be tricked into communicating with an impostor.

Proposed resolution

Remove the ability for logged in users to change name and email address on the contact form.

Remaining tasks

  • Minor cleanups.
  • Manually test the email sent for both the sitewide and personal contact forms for both anonymous and authenticated users.

User interface changes

Only anonymous users will be allowed to enter a name and email address on the contact form. Users with an account will be forced to use the settings from their user data. Text will alert recipients of the sent emails that the anonymous users are not verified.

Before patch

After patch

String addition

The string t('Unverified') is added to contact form emails sent by anonymous users.

API changes

The structures of contact_site_form() and contact_personal_formm() change for authenticated users (replacing text fields with read-only values).

Original report by Dave Reid

Currently, both the site-wide and personal contact forms allow registered users to change the values of the 'name' and 'mail' fields. So I could submit a user's personal contact form with the name 'Dries' and 'dries-not-valid-mail@drupal.org' and it would look to the user like this e-mail actually came from Dries, which is a bad thing.

These forms should both remove the fields when a non-anonymous user is using them, and instead use theme_username() to display that the e-mail will be 'sent' from the current user.

๐Ÿ“Œ Task
Status

Needs work

Version

7.0 โšฐ๏ธ

Component

contact.module

Created by

๐Ÿ‡บ๐Ÿ‡ธUnited States dave reid Nebraska USA

Live updates comments and jobs are added and updated live.
  • Needs backport to D6

    After being applied to the 7.x branch, it should be considered for backport to the 6.x branch. Note: This tag should generally remain even after the backport has been written, approved, and committed.

  • Security improvements

    It makes Drupal less vulnerable to abuse or misuse. Note, this is the preferred tag, though the Security tag has a large body of issues tagged to it. Do NOT publicly disclose security vulnerabilities; contact the security team instead. Anyone (whether security team or not) can apply this tag to security improvements that do not directly present a vulnerability e.g. hardening an API to add filtering to reduce a common mistake in contributed modules.

  • Needs backport to D7

    After being applied to the 8.x branch, it should be considered for backport to the 7.x branch. Note: This tag should generally remain even after the backport has been written, approved, and committed.

Sign in to follow issues

Merge Requests

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • First commit to issue fork.
  • ๐Ÿ‡บ๐Ÿ‡ธUnited States akalata

    akalata โ†’ changed the visibility of the branch 601776 to hidden.

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States akalata

    This got so close, but stalled at the finish line. I'm still getting used to gitlab but will hopefully have #134 available as an MR soon.

  • Merge request !9756Adding patch 134 to create MR โ†’ (Open) created by akalata
  • ๐Ÿ‡บ๐Ÿ‡ธUnited States akalata
  • Pipeline finished with Success
    5 months ago
    Total: 233s
    #301132
  • ๐Ÿ‡ธ๐Ÿ‡ฐSlovakia poker10

    Thanks for creating an MR for D7. It looks like a clean backport of the D8+ fixes.

    I am a bit concerned about changing the markup on the form for logged in users from "textfield" to "item" - for BC reasons (sites can have custom styling which can potentially break, ...). Yes, it is the cleanest way how to fix this in D7, but maybe we should consider something with lesser impact - for example to rewrite the email and name in the contact_personal_form_submit? According to the backport policy for D7 ( https://www.drupal.org/about/core/policies/core-change-policies/what-pat... โ†’ ), changes like these are allowed only if the issue is Critical.

    (not creating a separe D7 issue just yet, in case we decide to commit it in this form - otherwise we should create a separate issue as per current backport policy)

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States akalata

    I've added an update that changes from creating a separate read-only element to disabling the input fields. Existing test for the site-wide form was updated, and a test for the personal contact form was added.

  • Pipeline finished with Success
    3 months ago
    Total: 225s
    #340087
  • ๐Ÿ‡ธ๐Ÿ‡ฐSlovakia poker10

    Thanks for working on this. Added few comments to the MR.

    I was also curious, if the 'not verified' string will be saved in the cookie and then pre-filled later, but it is not for two reason (which seems correct). The first is that we are updating $values['sender']->name, not $values['name'] (the later one is saved to the cookie). The second reason is that although there is a Drupal.behaviors.fillUserInfoFromCookie in form.js, that javascript file is loaded only for forms with fieldsets or vertical tabs, so the values are not prefilled from the saved cookies in this form anyway.

  • ๐Ÿ‡ฎ๐Ÿ‡นItaly apaderno Brescia, ๐Ÿ‡ฎ๐Ÿ‡น

    avpaderno โ†’ made their first commit to this issueโ€™s fork.

  • ๐Ÿ‡ฎ๐Ÿ‡นItaly apaderno Brescia, ๐Ÿ‡ฎ๐Ÿ‡น
  • Pipeline finished with Success
    2 months ago
    Total: 238s
    #369197
Production build 0.71.5 2024