Contrib.social

Protect initial login link against abuse and username leaking

Open on Drupal.org →
Created on 27 November 2019, over 4 years ago
Updated 22 June 2024, 4 days ago

Copied from https://security.drupal.org/node/166626 which was reviewed and determined it was OK to make it public as the impact is minimal. The reporter was via email and did not provide details on their d.o account to be able to give them credit.

Problem/Motivation

The "initial login link" that a user gets in their email when registering for an account on a site that allows anonymous registration without approval has a few interesting elements:

  1. It never expires - while the password reset link expires in 24 hours.
  2. The default robots.txt allows crawling these links

That combination means that if the url gets "leaked" somehow it is very easy to use a search engine to find unused login links.

Note that this issue seems to primarily affect accounts created using disposable email services where the inbox contents become crawlable on the internet.

Proposed resolution

A simple change is to update robots.txt to disallow crawling of /user/reset/*

A behavior breaking change that is worthwhile would be to validate the initial login link is being used within a certain period of time, perhaps 2 days. (The current patch makes it have the same value as the 'password_reset_timeout' configuration value, which currently is 24 hours and has no UI in Core. Is there ar reason to differentiate them?)

Remaining tasks

Lots.

User interface changes

robots.txt disallows access to password reset links.
(maybe) the initial login link verifies a timestamp.

API changes

$expiration_date for UserPasswordResetForm is now effectively mandatory. (Is this an API change? I'm not sure. --roderik)

Data model changes

None.

Release notes snippet

Links in e-mails sent out to newly created users are now valid for a limited time only, like links in "password reset" e-mails already are.

✨ Feature request
Status

Needs work

Version

11.0 🔥

Component
User system  →

Last updated about 7 hours ago

Created by

🇺🇸United States greggles Denver, Colorado, USA

Live updates comments and jobs are added and updated live.
  • 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.

Sign in to follow issues

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.
  • Open in Jenkins → Open on Drupal.org →
    Environment: PHP 8.2 & MySQL 8
    last update 12 months ago
    29,565 pass
  • Status changed to Needs review 12 months ago
  • Comment 12 months ago →
    🇮🇳India Bhanu951

    Rebased MR against 11.x Branch , Setting NR.

  • Open in Jenkins → Open on Drupal.org →
    Environment: PHP 8.2 & MySQL 8
    last update 12 months ago
    29,566 pass
  • Comment 12 months ago →
    🇨🇦Canada Charlie ChX Negyesi 🍁Canada

    Serving as the Ghost of Drupal Past, as I am sure everyone remembers ;) José added this not long ago ;) in #18719: Request New Password Security → with a little dabbling from me but even I can't recall the reason for no timeout on first login. Re-reading the issue, it was introduced in #14 but there's no reasoning given. Considering some use cases here... for example you might be registering on an event website months ahead, get a link and never bother to go through with the actual account creation until the event comes. if we consider this a valid use case then maybe we should add instructions on how to obtain a fresh reset link -- AFAIK currently the only way in the web UI is to visit user/reset, enter the username and click... so maybe we should consider adding username prefill functionality to the user reset page and add instructions to the initial user mail?

  • Status changed to Needs work 12 months ago
  • Comment 12 months ago →
    🇺🇸United States smustgrave

    This seems like something that could use an issue summary update.

    Is the same approach from 3 years ago still desired?

  • Comment 10 months ago →
    🇺🇸United States daddison

    The issue summary still seems solid to me.

  • Comment 6 months ago →
    🇺🇸United States wxactly

    Reroll of #25 against Drupal 10.2.x

  • Open in Jenkins → Open on Drupal.org →
    Environment: PHP 8.1 & MariaDB 10.3.22
    last update 6 months ago
    25,746 pass, 1,791 fail
  • Comment 4 days ago →
    🇺🇸United States gcb

    Reroll of #34 against 10.3.x

contrib.social Blog FAQ Discussions
Production build 0.69.0 2024