Pour activer (et forcer) facilement l’administration WordPress via SSL, il existe deux constantes que vous pouvez définir dans votre site wp-config.php Déposer. Il ne suffit pas de définir ces constantes dans un fichier de plug-in. Ils doivent être définis dans le vôtre wp-config.php Déposer. Vous devez également avoir déjà configuré SSL sur le serveur et un hôte (virtuel) pour le serveur sécurisé avant que votre site fonctionne correctement si ces constantes sont définies sur true.

Noter: FORCE_SSL_LOGIN était obsolète Version 4.0. Veuillez utiliser FORCE_SSL_ADMIN.

La constante FORCE_SSL_ADMIN peut être définie sur true dans le fichier wp-config.php pour forcer toutes les connexions et Toutes les réunions d’administration doivent avoir lieu via SSL.

Exemple Exemple

define('FORCE_SSL_ADMIN', true);

Au-dessus de ↑

Si WordPress est hébergé derrière un proxy inverse qui fournit SSL mais est hébergé sans SSL lui-même, ces options enverront d’abord toutes les demandes dans une boucle de redirection infinie. Pour éviter cela, vous pouvez configurer WordPress pour qu’il reconnaisse l’en-tête HTTP_X_FORWARDED_PROTO (en supposant que vous avez correctement configuré le proxy inverse pour définir cet en-tête).

Exemple Exemple

define('FORCE_SSL_ADMIN', true);
// in some setups HTTP_X_FORWARDED_PROTO might contain 
// a comma-separated list e.g. http,https
// so check for https existence
if (strpos($_SERVER['HTTP_X_FORWARDED_PROTO'], 'https') !== false)
$_SERVER['HTTPS']='on';

Au-dessus de ↑

Le reste de cet article est fourni à titre d’information au cas où vous utiliseriez une ancienne version de WordPress (ce que vous ne devriez idéalement pas!) Ou votre configuration SSL est légèrement différente (c’est-à-dire que votre certificat SSL est pour un domaine différent).

Parfois, vous voulez que tout votre wp-admin s’exécute sur une connexion sécurisée en utilisant le protocole https. Conceptuellement, le processus fonctionne comme suit:

  1. Configurez deux hôtes virtuels avec la même URL (l’URL du blog), l’un sûr et l’autre non.
  2. Configurez une règle de réécriture sur l’hôte virtuel sécurisé qui transportera tout le trafic administrateur non WP vers le site non sécurisé.
  3. Configurez une règle de réécriture sur l’hôte virtuel non sécurisé qui transfère tout le trafic vers wp-admin vers l’hôte sécurisé.
  4. Incluez un filtre (via un plugin) qui filtrera les liens dans wp-admin afin qu’une fois activés, les liens administratifs soient réécrits pour utiliser https et éditer les cookies afin qu’ils ne fonctionnent que sur des connexions cryptées.

Les instructions ci-dessous s’appliquent à WordPress 1.5 et Apache exécutant mod_rewrite en utilisant les règles de réécriture dans httpd.conf (par opposition aux fichiers .htaccess). Cependant, il peut facilement être adapté à d’autres scénarios d’hébergement.

Au-dessus de ↑

Hôtes virtuels Hôtes virtuels

En plus du site non sécurisé, vous avez besoin d’un hôte (virtuel) configuré pour le serveur sécurisé. Dans cet exemple, l’hôte virtuel sécurisé utilise la même chose DocumentRoot en tant qu’hôte non sécurisé. En théorie, vous pouvez utiliser un hôte avec un nom différent, par exemple B. wpadmin.mysite.com et liez le répertoire racine du document au répertoire wpadmin.

Demandez à votre FAI de configurer un hôte virtuel sécurisé pour vous ou si vous disposez de votre propre accès administratif. Noter que Vous ne pouvez pas utiliser l’hébergement virtuel basé sur le nom pour identifier différents serveurs SSL.

Réécrire les règles pour l’hôte non sécurisé Réécrire les règles pour l’hôte non sécurisé

Ajoutez cette règle de réécriture à la strophe .htaccess ou Virtual Host dans httpd.conf pour que votre hôte non sécurisé passe automatiquement à l’hôte sécurisé lorsque vous accédez à http://monsite.com/wp-admin/ ou http: // Naviguer sur mon site .com / wp-login.php

Cela devrait aller au-delà du bloc de réécriture WordPress principal.

  RewriteCond %{THE_REQUEST} ^[A-Z]{3,9} /(.*) HTTP/ [NC]
  RewriteCond %{HTTPS} !=on [NC]
  RewriteRule ^/?(wp-admin/|wp-login.php) https://mysite.com%{REQUEST_URI}%{QUERY_STRING} [R=301,QSA,L]

Si vous utilisez des règles de réécriture de permalien, cette ligne doit être ajoutée au début RewriteRule ^.*$ - [S=40].

Une idée importante dans ce bloc est l’utilisation de THE_REQUEST, qui garantit que seules les requêtes http réelles sont réécrites et non les requêtes de fichiers directes locales telles qu’une inclusion ou une fopen.

Au-dessus de ↑

Réécrire les règles d’hôte sécurisé (facultatif) Réécrire les règles d’hôte sécurisé (facultatif)

Ces règles de réécriture sont facultatives. Vous désactivez l’accès au site public via une connexion sécurisée. Si vous souhaitez rester connecté à la zone publique de votre site Web avec le plugin suivant, vous devez le faire Pas Ajoutez ces règles lorsque le plugin désactive le cookie sur les connexions non chiffrées.

L’hôte virtuel sécurisé doit avoir deux règles de réécriture dans un fichier .htaccess ou dans la déclaration de l’hôte virtuel (voir Utiliser des permaliens pour en savoir plus sur la réécriture):

   RewriteRule !^/wp-admin/(.*) - [C]
   RewriteRule ^/(.*) http://www.mysite.com/$1 [QSA,L]

La première règle exclut le répertoire wp-admin de la règle suivante, qui mélange le trafic vers le site sécurisé avec le site dangereux pour que les choses restent agréables et transparentes pour votre public.

Au-dessus de ↑

Définir l’URI WordPress Définir l’URI WordPress

Pour que certains plugins fonctionnent, et pour d’autres raisons, vous pouvez définir votre URI WordPress dans des options qui reflètent le protocole https en définissant cela sur https://monsite.com. Votre adresse de blog ne doit pas changer.

Au-dessus de ↑

Exemple de lignes de configuration Exemple de lignes de configuration

REMARQUE: la configuration suivante n’est pas compatible à 100% avec WordPress 2.8+. WordPress 2.8 utilise certains fichiers du dossier wp-includes. La redirection introduite par le premier ensemble de règles de réécriture peut provoquer des avertissements de sécurité pour certains utilisateurs. Voir https://core.trac.wordpress.org/ticket/10079 pour plus d’informations.

<VirtualHost nnn.nnn.nnn.nnn:443>
        ServerName www.mysite.com

        SSLEngine On
        SSLCertificateFile    /etc/apache2/ssl/thissite.crt
        SSLCertificateKeyFile /etc/apache2/ssl/thissite.pem
        SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown

        DocumentRoot /var/www/mysite

        <IfModule mod_rewrite.c>
                RewriteEngine On
                RewriteRule !^/wp-(admin|includes)/(.*) - [C]
                RewriteRule ^/(.*) http://www.mysite.com/$1 [QSA,L]
        </IfModule>
        ...
</VirtualHost>

# Insecure site
<VirtualHost *>
        ServerName www.mysite.com

        DocumentRoot /var/www/ii/mysite

        <Directory /var/www/ii/mysite >
                <IfModule mod_rewrite.c>
                        RewriteEngine On
                        RewriteBase /
                        RewriteCond %{REQUEST_FILENAME} -f [OR]
                        RewriteCond %{REQUEST_FILENAME} -d
                        RewriteRule ^wp-admin/(.*) https://www.mysite.com/wp-admin/$1 [C]
                        RewriteRule ^.*$ - [S=40]
                        RewriteRule ^feed/(feed|rdf|rss|rss2|atom)/?$ /index.php?&feed=$1 [QSA,L]
                        ...
                </IfModule>
         </Directory>
         ...
</VirtualHost>

Au-dessus de ↑

Réécrire pour la connexion et l’enregistrement Réécrire pour la connexion et l’enregistrement

Utiliser SSL pour les connexions et les inscriptions des utilisateurs est probablement une bonne idée. Considérez les RewriteRules de remplacement suivantes.

Incertain
RewriteRule ^/wp-(admin|login|register)(.*) https://www.mysite.com/wp-$1$2 [C]
Pour sauvegarder
RewriteRule !^/wp-(admin|login|register)(.*) - [C]

Au-dessus de ↑

Réécriture pour les sites exécutés sur le port 443 ou le port 80 Réécriture pour les sites exécutés sur le port 443 ou le port 80

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /

# For a site running on port 443 or else (http over ssl)
RewriteCond %{SERVER_PORT}  !^80$
RewriteRule !^wp-(admin|login|register)(.*) - [C]
RewriteRule ^(.*)$ http://%{SERVER_NAME}/$1 [L]

# For a site running on port 80 (http)
RewriteCond %{SERVER_PORT}  ^80$
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^wp-(admin|login|register)(.*) https://%{SERVER_NAME}:10001/wp-$1$2 [L]

RewriteCond %{SERVER_PORT}  ^80$
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

</IfModule>

Au-dessus de ↑

Résumé Résumé

Cette méthode fonctionne Pas réparer certains risques de sécurité inhérents dans WordPress, il ne vous protège pas non plus des attaques de type «  man-in-the-middle  » ou d’autres risques qui peuvent paralyser les connexions sécurisées.

Cependant, c’est le cas devrait Rendez beaucoup plus difficile pour une personne malveillante de voler vos cookies et / ou vos en-têtes d’authentification et de les utiliser pour vous faire passer pour vous et accéder à wp-admin. Cela obscurcit également la possibilité de renifler votre contenu, ce qui peut être important pour les blogs juridiques qui peuvent avoir des brouillons de documents nécessitant une protection rigoureuse.

Au-dessus de ↑

Vérification Vérification

Sur le serveur de l’auteur, les journaux indiquent que les requêtes GET et POST sont effectuées via SSL et que tout le trafic vers wp-admin sur l’hôte non sécurisé est transféré vers l’hôte sécurisé.

Exemple de ligne de journal POST:

[Thu Apr 28 09:34:33 2005] [info] Subsequent (No.5) HTTPS request received for child 6 (server foo.com:443)
xx.xxx.xxx.xxx - - [28/Apr/2005:09:34:33 -0500] "POST /wp-admin/post.php HTTP/1.1" 302 - "https://foo.com/wp-admin/post.php?acti
on=edit&post=71" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3"

Des tests supplémentaires, de préférence avec un renifleur de paquets et des outils d’analyse de réseau hardcore, aideraient à le confirmer.

Au-dessus de ↑

restrictions restrictions

L’auteur suppose (mais ne l’a pas vérifié) que l’utilisateur a enregistré des cookies / demandé à son navigateur de se souvenir des mots de passe (pas en fonction des champs de formulaire, mais en utilisant un certain mécanisme d’authentification externe) et sur http: // www .mysite.com / Cliquez sur. wp-admin /, ces paquets sont envoyés en texte clair et les en-têtes Cookie / Auth peuvent être interceptés. Pour assurer une sécurité maximale, l’utilisateur doit donc explicitement utiliser l’hôte https ou toujours se connecter au début des nouvelles sessions.



Source link

Recent Posts