Pourquoi WordPress masque-il la clé de réinitialisation du mot de passe de l'URL?

Question

Je travaille actuellement sur un plugin WordPress qui comporte une interface de connexion personnalisée. Je me demande pourquoi il se peut que, lorsque vous réinitialisez votre mot de passe sur WP-Admin, WordPress enregistre la clé de réinitialisation du mot de passe dans un cookie plutôt que de le récupérer à partir de l'URL via $_GET.

Par exemple, si votre lien de réinitialisation est https://example.com/wp-admin/?action=rp&key=123123213213213123&login=admin, le lien stockera $_GET['key'] et $_GET['login'] dans un cookie et vous servira cette page à l'aide du cookie: https://example.com/wp-admin/?action=rp.

Y a-t-il des raisons de sécurité pour cela?

Answer 1

Pour être honnête? C'est un peu difficile à dire ...

Ce comportement a été introduit dans 3.9.2 (qui est une mise à jour de sécurité). Voici le bogue dans Trac: 29060: Ne transmettez pas la clé resetpass , mais il n’ya pas beaucoup d’informations sur les raisons de son introduction dans le rapport de bogue.

Est-ce pour des raisons de sécurité? Le plus probable. Mais cela rend-il vraiment le processus plus sécurisé? C'est un peu difficile à dire ...

Les paramètres et les cookies GET sont envoyés dans chaque demande - ainsi, l'attaquant peut toujours les intercepter. Cela rend juste ces tentatives un peu plus difficiles (puisqu'il faut obtenir pass_key et sa valeur hachée).

Answer 2

Il existe quelques sécurité avantages auxquels je peux penser quand vous le faites de cette façon:

1. Si vous accédez à l'URL de réinitialisation à partir de votre courrier électronique, mais oubliez de procéder à la réinitialisation réelle, une personne disposant du accès visuel à votre écran (directement de derrière vous ou d'une caméra de sécurité devant votre écran) a augmentation des chances d'obtenir l'URL de réinitialisation à partir de la barre d'adresse de votre navigateur avec la valeur de l'attribut key. Donc, le paramétrer sur Cookie puis rediriger vers https://example.com/wp-login.php?action=rp aide à cet égard.

2. Il conserve l'historique du navigateur plus propre . En raison de la redirection,key n'apparaîtra pas dans l'historique du navigateur . Par exemple, vous utilisez un paramètre de navigateur légèrement plus sûr dans lequel Cookie est nettoyé après la fermeture de la fenêtre du navigateur. Avec key dans l'URL du navigateur, l'historique peut toujours le conserver et quelqu'un peut l'utiliser plus tard sans que vous le sachiez (au cas où vous avez visité le lien mais ne l'avez pas utilisé). Donc, garder la key dans le cookie et rediriger ensuite aide également dans ce cas.

Certes, ce n’est pas l’amélioration de sécurité la plus extraordinaire, mais c’est toujours une amélioration (même si ce sont les seuls avantages de cette mise à jour).

Remarque: Je ne pense pas que cela présente un avantage sérieux en termes de sécurité, comme la défense contre les attaques MITM. MITM est identique pour GET & Cookie. Utiliser HTTPS résout les deux.

Answer 3

Je me demandais exactement la même chose. La meilleure explication que j'ai pu trouver était ici:

https://robots.thoughtbot.com/is-votre-site-leaking-password-reset-links

Si un utilisateur clique sur le lien de réinitialisation du mot de passe dans un e-mail et que l’URL complète est laissée dans le navigateur, s’il ne réinitialise pas son mot de passe et ne clique pas sur un lien de sortie de la page de réinitialisation du mot de passe, le lien de réinitialisation du mot de passe complet sera partagé dans la page. Référent HTTP.

Certes, Wordpress n'a pas de liens sortants sur wp-login.php, mais beaucoup de personnes personnalisent cette page et il est relativement facile de voir le problème de sécurité potentiel.