L’envoi d’un identifiant accompagné de son mot de passe est toujours un moment critique lorsqu’on se connecte à un site Web. Même si la plupart des utilisateurs ne sont pas forcément conscients de ce risque, il est du devoir d’un webmestre digne de ce titre de protéger les utilisateurs contre les risques d’interception de données. Parmi ces utilisateurs, les administrateurs appartiennent à une catégorie encore plus sensible aux interceptions. Pas trop difficile d’imaginer ce qu’un pirate peut faire s’il est capable de devenir administrateur d’un site Web !

Cette problématique concerne par exemple WordPress. Par défaut, la célèbre page wp-login.php qui permet de s’identifier utilise simplement une URL HTTP. A titre d’illustration, voici un extrait du code source de la page de connexion par défaut de ce site :

<form name="loginform" id="loginform" action="http://ecroze.fr/manu/wp-login.php" method="post">

Comme on le voit, lorsque l’utilisateur aura rempli les champs « Identifiant » et « Mot de passe », ces informations seront envoyer à l’URL « http://ecroze.fr/manu/wp-login.php » sans aucun cryptage. Si votre ordinateur se trouve connecté sur un hub, alors tout matériel branché sur ce hub verra passer ces informations.

Il existe une solution toute simple pour rendre ces informations illisibles : utiliser HTTPS (c’est-à-dire HTTP au-dessus du protocole SSL).

Pour cela, il faut modifier le fichier wp-config.php situé à la racine de votre blog et insérer une ligne

define(‘FORCE_SSL_LOGIN’, true);

avant la ligne

require_once(ABSPATH . 'wp-settings.php');

Pour vérifier le fonctionnement, déconnectez-vous de WordPress et revenez sur la page de connexion wp-login.php de votre blog. L’examen du code source de la page HTML montre que cette fois l’URL est « https://ecroze.fr/manu/wp-login.php ». C’est le petit ‘s’ qui fait toute la différence : maintenant, l’envoi se fait en établissant d’abord une connexion SSL, ce qui prend un peu plus de temps qu’une connexion standard TCP, mais finalement les informations d’identifiant et de mot de passe ne sont plus lisibles.

Pour vérifier le bon comportement, rien de tel qu’un enregistrement des échanges de données avec Wireshark et voici le début de l’enregistrement des échanges après l’appui sur le bouton « Se connecter » :

De manière amusante, on voit que l’appui sur le bouton provoque d’abord le chargement d’une image PNG (j’avoue ne pas avoir cherché ce qui provoque ce chargement). Puis on voit l’établissement de la connexion SSL avec « Client Hello », « Server Hello », l’envoi d’un certificat par le serveur, la négociation des conditions de cryptage et enfin l’envoi des données par le client. On voit également des données cryptées envoyées par le serveur, suivies par la demande de l’URL wp-admin de la part du client. On peut supposer que les données renvoyées par le serveur contenait un ordre de redirection vers cette URL.

Voila tout ce que Wireshark peut indiquer sur la nature des données envoyées par le client :

Les données sont indéchiffrables (et la réponse aussi).

Par acquit de conscience, regardons la demande pour l’URL /manu/wp-admin.

Et là, nous trouvons une nouvelle faille. Les cookies sont envoyés en clair, donc il est possible se subir un vol de session.

Pour un utilisateur aussi critique que l’administrateur, la solution la plus simple consiste à ajouter dans le fichier wp-config.php une seconde ligne :

define('FORCE_SSL_ADMIN', true);

De cette manière, tous les échanges avec la partie administrative de WordPress se fera également en HTPPS.

Bien évidemment, il y aurait beaucoup d’autres choses à dire sur la sécurité avec WordPress, mais cet article est déjà un début.