Oui, je suis très fortement en désaccord ici. Bien que votre cas d’usage spécifique puisse vous sembler assez simple, implémenter une simple substitution dans l’interface utilisateur pour cela introduirait un risque de sécurité significatif pour un gain de commodité très mineur.
La friction est une fonctionnalité de sécurité !
L’inconvénient d’avoir à utiliser la console Rails ou d’activer un paramètre au niveau du site est en fait une fonctionnalité de sécurité critique, car elle agit comme un « frein de sécurité » et force un administrateur à suivre un processus délibéré et à forte friction pour une opération très sensible.
Changer l’adresse e-mail d’un utilisateur revient à remettre les clés de son compte, car la nouvelle adresse e-mail peut être utilisée pour déclencher une réinitialisation de mot de passe, verrouillant efficacement l’utilisateur original et donnant au propriétaire du nouvel e-mail un contrôle total.
Quelques vecteurs d’attaque principaux que cette friction empêche :
-
Compromission des comptes administrateurs ! - C’est le risque le plus important. Si un attaquant obtient l’accès à un compte administrateur (via du hameçonnage, la réutilisation de mots de passe, etc.), un simple bouton ou bascule dans l’interface lui permettrait de prendre silencieusement et facilement le contrôle de n’importe quel autre compte utilisateur, y compris ceux d’autres membres du personnel ; l’exigence d’un accès shell via la console Rails fournit une couche de sécurité solide.
-
Ingénierie sociale ! - Cela ouvre la porte à l’ingénierie sociale. Un utilisateur malveillant pourrait se faire passer pour un utilisateur légitime et persuader un administrateur de lui changer son adresse e-mail ; là encore, le processus actuel à forte friction rend un administrateur beaucoup plus susceptible de vérifier ou de considérer l’authenticité de la demande.
-
Menace interne - Un administrateur malveillant pourrait abuser de cette fonctionnalité pour prendre le contrôle de comptes.
Pour ce type d’actions administratives rares et à haut risque, la console Rails est appropriée car elle garantit que la personne effectuant l’action a un accès serveur et non une session compromise. De plus, l’action est délibérée et nécessite des connaissances techniques spécifiques (et elle est enregistrée dans l’historique du shell).