Ce paramètre de sécurité .htaccess fonctionne-t-il vraiment?
Que fait ce .htaccess?
Ai-je raison de penser que tout ce qu'il fait est d'empêcher les attaques automatiques par force brute?
Donc, pour accéder au fichier wp-login.php, vous devez taper manuellement l'URL du domaine de sorte que tous les robots recherchant le fichier wp-login.php soient annulés.
Ai-je raison?
Voici la règle .htaccess:
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{HTTP_REFERER} !^https://(.*)?my-domain.com [NC]
RewriteCond %{REQUEST_URI} ^(.*)?wp-login\.php(.*)$ [OR]
RewriteCond %{REQUEST_URI} ^(.*)?wp-admin$
RewriteRule ^(.*)$ - [F]
</IfModule>
Cela semble empêcher toute demande de POST à wp-login.php qui ne provient pas d'une page de my-domain.com.
Lorsque le navigateur envoie une demande POST, par exemple, après avoir soumis un formulaire, il inclut un en-tête HTTP Referrer indiquant au serveur l'origine de la demande.
Ceci empêche théoriquement les robots de soumettre des requêtes POST directement à wp-login.php dans le cadre d'une attaque par force brute, mais le référent HTTP est simple à simuler, de sorte que ce n'est pas vraiment utile.
Ce que cela n'empêche pas: Brute Force
tout ce qu'il fait est d'empêcher les attaques automatiques par force brute?
Non, cela n'empêche pas les attaques par force brute.
Dans une attaque par force brute, un attaquant contrôle tous les paramètres de la requête HTTP. Cela inclut le référant. L'attaquant pouvant envoyer des référents arbitraires, cela n'empêche pas les attaques par force brute. (Presque) tous les outils de force brute permettront de définir un référent, et définir le site lui-même en tant que référent est assez standard.
Les mécanismes qui protègent contre la force brutale seraient l'interdiction ou la limitation sur la base d'une adresse IP ou d'un nom d'utilisateur, ainsi que des captchas.
Ce que cela pourrait être destiné à empêcher: CSRF
Ce code a peut-être été mis en retrait pour ajouter une vérification de référent à toutes les demandes POST de la zone d'administration. Si le référant n'est pas valide, la demande est rejetée.
Dans une attaque CSRF, un attaquant force une victime à exécuter une demande de changement d'étatPOST. Cela peut par exemple se produire en publiant du code HTML et Javascript sur le site attacker.com, qui envoie ensuite automatiquement une demande à victim.com dès qu'une victime authentifiée visite le site.
Les vérifications par référent sont un mécanisme de protection contre la CSRF. Seule victim.com étant acceptée comme référent valide, un attaquant ne peut forcer la victime à envoyer une requête à partir de son propre domaine.
Bien entendu, WordPress dispose de sa propre protection CSRF (via des nonces CSRF). Mais il est possible que tous les cas ne soient pas pris en compte, et la sécurité des plugins dépend beaucoup du développeur de plugins.
Une vérification de référent supplémentaire peut aider à empêcher que les vulnérabilités CSRF dans WP core, et en particulier dans les plugins, ne soient exploitables.
Bien entendu, si telle était l'intention, le code est mis à jour. Le $ dans RewriteCond %{REQUEST_URI} ^(.*)?wp-admin$ empêche la vérification de la plupart des demandes.
Le chèque peut également être facilement ignoré. Les référents suivants seraient acceptés:
Referer: http://example.com.org
Referer: http://not-example.com
Referer: http://notexample.com
Referer: http://attacker.com/example.com
[...]
Pour ajouter quoi que ce soit à la sécurité du site, il faudrait d’abord régler ces deux problèmes. Le code pourrait également être encore amélioré en ne se limitant pas à POST requêtes (dans les applications mal écrites, les requêtes GET peuvent également changer l'état du serveur ou les POST requêtes peuvent être transformées en Demandes GET). Comme le chèque s’applique uniquement aux administrateurs, cela ne devrait pas limiter la convivialité.
Vous êtes partiellement correct
Votre code ci-dessus aide protège votre site WordPress en n'autorisant que les demandes de connexion provenant directement de votre domaine.
La plupart des attaques par force brute envoient des demandes POST directement à votre script wp-login.php. Ainsi, le fait de requérir une demande POST d'avoir votre domaine en tant que référent aide à arrêter ces robots.
Vous pouvez aller plus loin si vous avez une adresse IP statique en utilisant le code suivant:
RewriteEngine on
RewriteCond %{REQUEST_URI} ^(.*)?wp-login\.php(.*)$ [OR]
RewriteCond %{REQUEST_URI} ^(.*)?wp-admin$
RewriteCond %{REMOTE_ADDR}!^111\.111\.111\.111$
RewriteRule ^(.*)$ - [R=403,L]
* Remplacez avec votre adresse IP statique.
* Peut ne pas fonctionner si votre site est derrière un service DNS tel que CloudFlare.