- Issue created by @catch
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.
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.
Active
2.0
Code