Problem/Motivation
Project browser allows installing new functionality to a site. This could be used by a malicious person who has taken over someone’s account, either by social engineering, or exploiting an XSS or other vulnerability which allows account takeover. The new functionality could chain to widen the initial vulnerability scope. For example, installing PHP module or adding backup & migrate to exfiltrate data.
This isn’t unique to project browser installing a module, there are other important actions which could be used by attackers to escalate security problem. For example, maybe setting an admin user’s password. These places could use an extra confirmation that the person is indeed who they say they are.
Examples from other systems:
- MacOS system settings requires unlocking some settings
- GitHub requires 2-factor-authentication for setting up webhooks
Proposed resolution
A common way to confirm a person would be good to have in core.
Asking for someone’s password to confirm would be a good first step. There might be a way to disable this in settings.php
for development and environments where Drupal isn’t doing password authentication. A system to extend/override the confirmation would be ideal, but might be able to wait for a followup issue.
To avoid password fatigue, unlocking should persist for some time period, like an hour or two.
Remaining tasks
- Figure out some details
- Implement
- Keep track of followups that aren’t needed for the initial feature
User interface changes
Yes, there is new UI for this.
Introduced terminology
Something along the lines of “unlock to make changes”
API changes
Should be usable by modules
Data model changes
Release notes snippet