Contrib.social

Require password confirmation to install new code

Open on Drupal.org →
Created on 18 April 2025, 25 days ago

Problem/Motivation

There is an inherent risk with installing code via the UI, that an XSS attack on a site admin can be leveraged into remote code execution.

If you gain control of an account that has access to project browser, and if project browser is able to install modules on production, then you could then install a module like devel, or one with an undisclosed RCE vulnerability, and then use that module to execute code on the server.

I think we can significantly mitigate this by requiring re-authentication before executing composer commands.

e.g. you would choose a recipe or module(s) to install, and then when you apply updates, you'd get prompted to enter your password. The same pattern that currently happens for changing your password, which is for much the same reasons (so an XSS attack can't result in account takeover).

This will add friction to installing modules via project browser, but I think we can add two mitigations for the UX issue:

1. This could be toggled on/off by the development mode toggle in core (once it exists, issue is ✨ Add a Production/Development Toggle To Core Needs work ), so that the friction can be completely removed in sandbox environments. e.g. the Drupal CMS desktop app could enable development mode.

(I realised while writing this that the development mode toggle combined with this only prevents the attack if we don't add a UI toggle for development mode (or put it behind password auth too), because then you'd be able to go to that page, enabled development mode, and go from there if not, making this issue self-defeating. I'll add a comment over on that issue.)

2. We could add flood control to the re-authentication, so that it only requires re-authentication after a certain period of time (one hour, one day), either with or without a 'don't prompt me for a while' checkbox - that would significantly reduce the likelihood of an XSS attack coinciding with the ability to install modules on production.

Steps to reproduce

Proposed resolution

Add a re-authentication step just before composer changes are applied, possibly with flood control so that the re-authentication is rate-limited and doesn't happen constantly during a short window of time.

📌 Task
Status

Active

Version

2.0

Component

Code

Created by

🇬🇧United Kingdom catch

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @catch
  • Comment 25 days ago →
    🇬🇧United Kingdom catch
  • Comment 24 days ago →
    🇬🇧United Kingdom catch
  • Comment 14 days ago →
    🇺🇸United States benjifisher Boston area

    I agree it is a good idea to have an extra level of authentication before making changes to the codebase, but I think that "password authentication" is too restrictive.

    Some sites use single sign-on (SSO) or other methods of authentication, so requiring a password would not be appropriate. On the other hand, it may be that sites using SSO also have dev, stage, and prod versions of the site, so they could use the proposed dev/prod toggle.

    It is out of scope for this issue, but I think that Drupal core should provide an authentication API. That would make it possible, in this issue, to let the site owner choose the method of authentication. It would also simplify the tfa (Two Factor Authentication) module.

  • Comment 14 days ago →
    🇬🇧United Kingdom mcdruid 🇬🇧🇪🇺

    Very definitely +1 to the idea of requiring an additional authentication step to install a module via Project Browser to defend against XSS/CSRF attacks.

    Benji makes good points about SSO and TFA, and whether requiring the password to be supplied is overly prescriptive; having an API for (re-)authentication would be great.

    I can think of other use cases for this too (I'll link to issues I plan to file).

    As for being able to toggle the extra protection on/off (e.g. development mode), would it make sense to have this as setting that cannot be altered via the UI?

  • Comment 14 days ago →
    🇬🇧United Kingdom catch

    As for being able to toggle the extra protection on/off (e.g. development mode), would it make sense to have this as setting that cannot be altered via the UI?

    I thought about this a bit. If we require re-authentication in project browser, but not when toggling dev mode, then you'd be able to bypass the project browser protection by going to the dev mode UI, which would... not be great. So this either means re-auth before toggling dev mode, or make it CLI-only, or a settings.php flag that determines the behaviour. But I think that is more of a consideration for ✨ Add a Production/Development Toggle To Core Needs work to worry about.

  • Comment about 15 hours ago →
    🇺🇸United States chrisfromredfin Portland, Maine

    We're not opposed to adding this - but we (a) need to think around SSO/TFA issues that Benji brings up, and (b) I think we need to think through the UI / user flow for this. I would imagine a modal might make the most sense, "interrupting" the process if we're not within the flood limit.

    Agree to keep the dev mode settings CLI-only or in settings.php. I think a 'dev mode' UI would be a poor choice. If it's a dev, it's a dev - and you can count on them to modify settings.php, (even an Ambitious Site Builder could do this, IMO) etc.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024