web-dev-qa-db-fra.com

htaccess réécrit la chaîne de requête de l'auteur lorsque WP est dans le sous-dossier

J'ai réussi à interdire l'accès à tout type de page d'auteur, que ce soit par /author/username/ ou par la chaîne de requête ?author={#id}.

Je l'ai fait avec ceci ajouté au début de mon fichier htaccess:

<IfModule mod_rewrite.c>
    RewriteCond %{REQUEST_URI} ^/author/
    RewriteRule .* - [F]
    RewriteCond %{QUERY_STRING} ^author=([0-9]*)
    RewriteRule .* - [F]
</IfModule>

Mais la même chose ne fonctionne pas quand wordpress est physiquement dans un sous-répertoire.

La première partie fonctionne:

RewriteCond %{REQUEST_URI} ^/subdir/author/
RewriteRule .* - [F]

Mais peu importe la façon dont j'essaie de modifier la deuxième partie, le /subdir/?author=1 m'emmène au /subdir/usernumber1/ et c'est tout à fait interdit, mais cela va à l'encontre du but recherché.

Des idées?

Modifier:

Oui, j'essayais d'empêcher l'affichage des noms d'utilisateur.

Au dernier moment hier, j'ai pu trouver une solution:

<IfModule mod_rewrite.c>
    RewriteCond %{REQUEST_URI} ^/subdir/author/
    RewriteRule .* - [F]
    RewriteCond %{REQUEST_URI} ^/subdir/
    RewriteCond %{QUERY_STRING} ^author=([0-9]*)
    RewriteRule .* - [F]
</IfModule>

Je pourrais peut-être le raccourcir en fonction des réponses ci-dessous (pour lesquelles je suis très reconnaissant).

Et oui, cela est placé dans le sous-répertoire.

Le premier extrait a été placé dans le répertoire racine, ce qui n'a pas fonctionné (ou peut-être que certaines des solutions que j'ai essayées tout au long du processus ont fonctionné mais que la redirection vers la page de l'auteur était déjà mise en cache, je ne sais pas avec certitude).

htaccessauthormod-rewrite
2
D. Dan

La question est de faire cela avec .htaccess, mais pourquoi ne pas désactiver les pages auteur à partir de WordPress?

Cela donnerait le même résultat tout en rendant le sous-répertoire sans aucune pertinence (et fonctionnant également indépendamment des paramètres de structure en permalien)

Exemple de code qui définit toutes les URL pour créer des pages avec une erreur 404:

add_action( 'template_redirect',
        function() {
                if ( isset( $_GET['author'] ) || is_author() ) {
                        global $wp_query;
                        $wp_query->set_404();
                        status_header( 404 );
                        nocache_headers();
                }
        }, 1 );
add_filter( 'author_link', function() { return '#'; }, 99 );
add_filter( 'the_author_posts_link', '__return_empty_string', 99 );

(code tiré de ce plugin: Disable Author Archives )

1
Iceable

Je suppose que vous essayez d'empêcher les scanneurs d'obtenir les noms d'utilisateur de votre site. Et pour la sécurité, je crois qu'il est possible de bloquer à la première porte de périmètre, c'est-à-dire .htaccess not PHP.

Aucune idée pourquoi les subdirs causent un problème; vous pouvez essayer d'ajouter votre condition aux fichiers htaccess à la fois dans root et votre sous-répertoire WP ne fera certainement aucun mal. J'utilise une condition de réécriture assez similaire à la vôtre et cela fonctionne pour moi sur les sites avec WP dans subdir ou non:

RewriteCond %{QUERY_STRING} author=
# redirect away from site
RewriteRule (.*) https://www.fbi.gov/investigate/cyber/%1 [R=302,L]

J'utilise également une version modifiée de "pare-feu" 6G de Jeff Starr pour vérifier en plus l'agent utilisateur WPScan. Ce scanner est très utilisé par les pirates et également utilisé par certains scanners de sécurité en ligne "entrez une URL" pour identifier les utilisateurs administrateurs, utilisation de plugins vulnérables, etc. etc. Évidemment, les utilisateurs peuvent changer d'UA, mais les scanners en ligne légitimes et les scripts pour enfants ne semblent pas déranger:

<IfModule mod_setenvif.c>
  # numerous 6G UA Checks (OMITTED)
  #check for WPScan
  SetEnvIfNoCase User-Agent "WPScan" bad_bot
  # Apache >= 2.3
  <IfModule mod_authz_core.c>
    <RequireAll>
    Require all Granted
    Require not env bad_bot
    </RequireAll>
  </IfModule>
</IfModule>

Commentaire de M Kaplun sur OP:

Je n'étais pas au courant de le plugin de Mark ; et malgré mes commentaires sur PHP, il s'agit évidemment d'une excellente solution unique prête à l'emploi. J'adopte une approche différente (qui "résout" le problème nom d'utilisateur fuite par thèmes également mentionné par Mark).

Modifiez le nom d'affichage (via WP Tableau de bord) et l'auteur slug (modifiez "user_nicename" dans le tableau des utilisateurs; ou utilisez modifiez le plugin Author Slug ) pour qu'il soit complètement différent de nom d'utilisateur.

Alors:

  1. les requêtes avec querystring auteur (hackers) sont redirigées (2 lignes de htaccess ci-dessus).

  2. les liens d’auteurs ajoutés aux messages par thèmes restent amicaux et efficaces. Ils vous mènent à la "page de l'auteur" pertinente - mais l'auteur ne reconnaît plus le nom d'utilisateur. par exemple. sur mon site, le lien auteur (valide) (nom complet "AW") vous conduit à https://wptest.means.us.com/author/not-for-scanners/ pour obtenir une liste de mes publications.

Ce n'est pas pratique pour les sites avec beaucoup d'auteurs. Peut-être que le plugin (@Mark Kaplun @ mark-kaplun) pourrait être étendu pour automatiser les modifications de slug (hachage de tous les noms d'utilisateurs dans la base de données?)?

Les noms d'utilisateur pouvant être visualisés publiquement constituent-ils un risque?

Le consensus Wordpress.org est que le nom d'utilisateur "leakage" est pas un risque pour la sécurité . Pourtant, il fournit le potentiel pour que certains utilisateurs soient piratés à la première tentative (aucune force brute n'est requise) .

Vous n'avez pas besoin d'être un génie pour comprendre que l'URL amical slug /author/hclintongmailcom signifie qu'il est un auteur avec un email et un nom d'utilisateur (insensible à la casse) de [email protected].

Il existe des listes de mots de passe de hackers pour 1 milliard d’adresses e-mail (rappelez-vous) (essayez la vôtre contre un petit sous-ensemble https://haveibeenpwned.com/ ); de nombreux utilisateurs utilisent le même mot de passe, qui ne change jamais. Un auteur avec un nom d’utilisateur et un mot de passe de messagerie compromis sur un autre site pourrait donc être "piraté" à la première tentative sur votre site.

1
scytale

Ceci est probablement mieux géré "à la manière de WordPress" comme le suggère @Iceable, plutôt que d'utiliser .htaccess, cependant, pour répondre à vos questions spécifiques ...

Mais peu importe comment j'essaie d'éditer la deuxième partie ...

Vous n'avez pas besoin de modifier la "deuxième partie". La "deuxième partie" vérifie simplement la chaîne de requête, et non le chemin d'URL, qui ne change pas lorsque WordPress est installé dans un sous-répertoire.

De plus, en supposant que le fichier .htaccess se trouve dans le sous-répertoire dans lequel WordPress est installé, vos directives peuvent être simplifiées. Il n'est pas nécessaire de référencer le sous-répertoire:

RewriteRule ^author/ - [F]
RewriteCond %{QUERY_STRING} ^author=([0-9]*)
RewriteRule .* - [F]

Ces directives fonctionneront quel que soit l'emplacement où WP est installé, à condition que le fichier .htaccess se trouve à la racine de l'installation WP.

Il est plus efficace de vérifier le chemin d’URL à l’aide de RewriteRule pattern (lorsque cela est possible), plutôt que de vérifier la variable de serveur REQUEST_URI. De même, la variable RewriteRule pattern correspond au chemin URL moins le préfixe de répertoire (ce qui fonctionne naturellement pour tout sous-répertoire sans travail supplémentaire). Alors que la variable serveur REQUEST_URI contient le chemin d’URL complet, tous les sous-répertoires doivent être explicitement pris en compte.

De plus, le conteneur <IfModule mod_rewrite.c> n'est pas nécessaire, à moins que ces directives ne soient censées être facultatives.

1
MrWhite