Grav-plugin-admin: Page de connexion vulnérable aux attaques par force brute

Créé le 3 nov. 2016  ·  14Commentaires  ·  Source: getgrav/grav-plugin-admin

Le panneau d'administration est vulnérable aux attaques par force brute. La page de connexion (/admin) renvoie un code si l'utilisateur existe et un autre code si l'utilisateur n'existe pas et qu'il n'y a pas de barrière empêchant les systèmes automatisés d'essayer cela. Je n'aime pas vraiment cette idée, mais je pense que le moyen le plus simple de résoudre ce problème immédiatement pourrait être d'insérer un Captcha. Une autre alternative (dont l'efficacité n'est pas certaine) pourrait être de limiter le nombre de tentatives à partir de la même adresse IP par jour.

La page de mot de passe oublié est également vulnérable... Lorsque vous essayez de demander un lien de mot de passe oublié, le système confirme si l'e-mail est enregistré ou non. Je suggérerais de le remplacer par un message plus générique tel que "S'il s'agit d'un e-mail enregistré, le lien de récupération lui a été envoyé. Si vous ne recevez pas le lien, contactez l'administrateur de votre site" ou quelque chose comme ça. .. mais je ne sais pas si cela suffirait. Peut-être que quelqu'un avec plus d'expertise pourrait vouloir se pencher là-dessus.

enhancement

Commentaire le plus utile

Les délais entre les tentatives de connexion - augmentant de préférence, peut-être de façon exponentielle, à chaque tentative jusqu'à une certaine limite - bloquent efficacement les attaques par force brute. Les retards et les limites peuvent être définis comme paramètres.

Tous les 14 commentaires

J'utiliserais simplement un seul message d'erreur indiquant quelque chose comme : Incorrect username or password. Ces changements (changement de chaîne de mot de passe oublié inclus) rendraient impossible de deviner les noms d'utilisateur dans l'un ou l'autre des formulaires.

Je ne limiterais pas l'accès par IP, mais ajouter captcha en option n'est pas une mauvaise idée.

Je n'aime pas vraiment l'option captcha, mais si elle doit être ajoutée, pourrions-nous au moins l'activer uniquement après quelques tentatives infructueuses (comme 3, ou quelque chose comme ça) ?

Les délais entre les tentatives de connexion - augmentant de préférence, peut-être de façon exponentielle, à chaque tentative jusqu'à une certaine limite - bloquent efficacement les attaques par force brute. Les retards et les limites peuvent être définis comme paramètres.

La fonctionnalité de mot de passe oublié a été modifiée dans la version bêta du plugin de connexion. Il ne prend que les adresses e-mail maintenant.

Également, édité pour imprimer le même message, que l'e-mail existe ou non, dans https://github.com/getgrav/grav-plugin-login/commit/3e7c20fd66639123cfb2894d9298d4ccfb861af9

La journalisation des tentatives échouées serait bien aussi pour fail2ban etc :)

Qu'en est-il d'un moyen de limiter le nombre de tentatives de connexion incorrectes sur une certaine période ?

Le plugin Login a maintenant une section de sécurité dans sa configuration pour contrôler cela : https://github.com/getgrav/grav-plugin-login/commit/590f188189c8453afb5992e7ec385795336ee711

Ce serait toujours bien d'avoir même l'OPTION pour un captcha. De plus, la protection contre les inondations ne semble pas fonctionner du tout.
Grav ne vous empêche jamais d'entrer d'autres mots de passe, même avec les fonctions de sécurité activées. Cela ne prolonge pas non plus le délai entre les tentatives de connexion.

Est-ce que je fais quelque chose de mal ou est-ce que le plugin est simplement cassé ?

En fait, la protection contre la force brute du plug-in de connexion ne s'applique pas à l'administrateur (ma faute en écrivant le contraire ici). Dans Admin, vous avez la possibilité d'ajouter une protection au niveau du serveur Web (par exemple, htaccess/htpasswd dans Apache) et également de limiter par plage d'adresses IP, jusqu'à ce que cette fonctionnalité atterrisse également dans Admin.

Je vois. Oui, je suppose que c'est la chose sensée à faire jusque-là.
Actuellement, cela semble être une faille de sécurité flagrante, si les utilisateurs ne reçoivent pas au moins un avertissement indiquant qu'ils doivent sécuriser la page d'administration.

De plus, comme déjà suggéré : un avertissement pour les tentatives de connexion infructueuses dans le tableau de bord serait très bien.

En espérant une mise à jour à ce sujet bientôt :)

EDIT : la solution .htaccess tue à peu près tous les CSS sur la page d'administration. Ce qui le rend plus ou moins inutilisable.

Actuellement, le mieux que vous puissiez faire pour améliorer la sécurité de l'administration est de masquer la page d'administration en la renommant, comme ceci :
https://learn.getgrav.org/admin-panel/faq#custom-admin-url
J'espère vraiment qu'une protection de connexion pour l'administrateur arrivera bientôt, car cela m'empêche de l'utiliser sur un site d'entreprise.

En fait, la protection contre la force brute du plug-in de connexion ne s'applique pas à l'administrateur (ma faute en écrivant le contraire ici). Dans Admin, vous avez la possibilité d'ajouter une protection au niveau du serveur Web (par exemple, htaccess/htpasswd dans Apache) et également de limiter par plage d'adresses IP, jusqu'à ce que cette fonctionnalité atterrisse également dans Admin.

La protection contre la force brute semble fonctionner sur ma page de connexion d'administrateur. C'est aussi dans la doc . Ce commentaire est-il obsolète ou ai-je mal compris?

Est-ce que quelqu'un sait aussi comment faire fonctionner Grav avec fail2ban?

Ma solution alternative ne fonctionne que si vous avez un accès FTP à tous vos serveurs/hébergements.

Vous pouvez modifier le .htaccess pour autoriser uniquement votre adresse IP spécifique à lire le dossier /admin/. Toute autre IP (et les robots suivants) ne pourront pas charger le contenu du dossier.

J'avais l'habitude d'utiliser cette méthode pour interdire tout, sauf ma propre adresse IP... pour vérifier si un site Web de construction fonctionnait, avant de le lancer. C'était avant que vous puissiez exécuter un serveur Web local. Peut-être que cela fonctionne toujours pour les quelques utilisateurs qui ont peur et veulent un contrôle total uniquement à partir de leur adresse IP.

Cette page vous a été utile?
0 / 5 - 0 notes