Tester un WordPress en local (HSTS…)

Pour déboguer un site , il est parfois nécessaire de ramener en local la totalité des scripts, et la base de données. Surtout lorsque l’on souhaite éviter d’activer sur le site en question (ou pire, lorsque c’est impossible…).

Problème(s)…

Ramener tout ceci en local n’est pas sans conséquences, car le nom de domaine est présent dans la base de données, sous différentes formes, et parfois sous la forme d’informations sérialisées. En conséquence, pour migrer d’un domaine vers un autre (par exemple, vers localhost…), il est indispensable de jouer des scripts de . Les requêtes détaillées ici ne sont pas suffisantes, car la désérialisation des données échouera si on ne prend pas soin de recalculer plus profondément ces données sérialisées. Pour être plus concis, chercher et remplacer des occurences de chaînes de caractères en base ne suffit pas. Dans la sérialisation WordPress, la longueur de la chaîne de caractères réelle doit matcher la longueur indiquée dans le document sérialisé. Par exemple :

$arr["20041001103319"] = 'test';
$serialized = serialize($arr);
echo ($serialized);

La console renvoie :

a:1:{i:20041001103319;s:4:"test";}

Cela signifie que l’on vient de sérialiser un tableau (array, “a”…) de taille “1”, ayant une clé entière (integer, “i”…) de valeur “20041001103319”, et une valeur de type chaîne de caractères (string, “s”…) de taille “4”. Si l’on patche la valeur “test” dans ce document sans prendre soin de modifier sa longueur, à savoir “4”, le document ne pourra pas être désérialisé. Des plugins ou des scripts spécifiques permetttent de gérer cet aspect, comme ici.

Tout ceci est un peu pénible, et nous éloigne des conditions d’exploitation réelles. Pour se rapprocher des conditions réelles, il est préférable de faire passer son localhost pour le site en question, en jouant sur son fichier /etc/hosts. Toutefois, l’absence en local du certificat SSL/TLS conduit à quelques déroutes dans les navigateurs, lorsque l’on modifie son fichier /etc/hosts. Comme celle-ci pour Firefox :

Scandaleux, mais nécessaire ! D’après wikipedia :

Lorsque la politique HSTS est active pour un site web, l’agent utilisateur compatible opère comme suit :

  1. Remplace automatiquement tous les liens non sécurisés par des liens sécurisés. Par exemple, http://www.exemple.com/une/page/ est automatiquement remplacé par https://www.exemple.com/une/page/ avant d’accéder au serveur.
  2. Si la sécurité de la connexion ne peut être assurée (par exemple, le certificat TLS est auto-signé), celui-ci affiche un message d’erreur et interdit à l’utilisateur l’accès au site à cause de cette erreur.

La politique HSTS aide à protéger les utilisateurs de sites web contre quelques attaques réseau passives (écoute clandestine) et actives. Une attaque du type man-in-the-middle ne peut pas intercepter de requête tant que le HSTS est actif pour ce site.

Solution

Voici donc ci-dessous un petit script permettant de lever cette alerte dans Firefox, lorsqu’elle se produit : suppression des informations du domaine dans le fichier de stockage des super-cookies du navigateur. Ce fichier n’est pas éditable à partir du navigateur, et ne peut pas être désactivé. Concernant les super-cookies :

Like normal cookies, they allow him to fingerprint users who browse to his site in non-privacy mode, so if they return later, he will know what pages they looked at. There are two things that give his cookies super powers. The first is that once set and depending on the specific browser and platform it runs on, the cookies will be visible even if a user has switched to incognito browsing. The second is that the cookies can be read by websites from multiple domain names, not just the one that originally set the identifier. The result : unless users take special precautions, super cookies will persist in their browser even when private browsing is turned on and will allow multiple websites to track user movements across the Web.

Le script en question est le suivant :

domain="www.business-rules.fr"
file=`find $HOME/.mozilla/firefox/ -name 'SiteSecurityServiceState.txt'`
sed "/$domain/d" $file > /tmp/SiteSecurityServiceState.clean
mv /tmp/SiteSecurityServiceState.clean $file

Dans ce script, la variable $domain contient le nom de domaine que l’on souhaite réinitialiser. Un bémol de taille cependant, toutes les instances de Firefox doivent être fermées avant d’exécuter ce script, car elles remettront à jour ce fichier au fur et à mesure que vous le modifierez, à partir de leur état. Pour Chrome, vous trouverez plus de détails ici.

Conclusion

Le script est pratique mais la solution n’est pas idéale. Changer d’environnement prend du temps et il est nécessaire de fermer tous les navigateurs.

Une petite virtualisation autour du navigateur et des noms d’hôtes devrait pouvoir nous aider à alléger tout ceci…

Il est peut-être temps de regarder ce que Docker a à nous offrir… il devrait être notamment possible d’embarquer le navigateur, ainsi que les noms d’hôtes, dans un conteneur Docker. Cela permettrait, entre autres choses, de ne pas modifier le système local. La suite… ici.

Add a Comment

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

26 − = 16