HSTS et CSP qu'est ce que c'est ?
Je sais pas si vous êtes toujours là, c’est vrai que le blog a pris de looooongues vacances cette année. Donc pour les deux du fond qui restent je vais vous parler de trucs bizarres: HSTS et CSP des gros mots qui ne sont pas si gros, que l’on rencontre de plus en plus et qui concernent la sécurité de votre site ou appli web…
HSTS
HSTS signifie en fait HTTP Strict Transport Security. Là vous allez me dire « on est pas mieux avancés » et vous n’aurez pas tord. Il s’agit en fait d’une fonctionnalité très intéressante pour renforcer la sécurité de votre site ou appli web. Si l’on simplifie c’est ce qui va permettre à votre serveur web de dire au client qui se connecte: « Toi et moi on va se parler uniquement en https ». Cela va donc permettre d’ajouter une protection supplémentaire et d’être certain que les utilisateurs de votre site utilisent une connexion sécurisée par https lorsqu’ils naviguent chez vous.
Alors comment ça s’active ? En fait pour activer une protection de base avec Apache il suffit d’une ligne que vous déclarez dans un .htaccess ou dans un Virtualhost:
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
Si on décortique on voit que j’ajoute dans mon en-tête http qui va être transmis au client les directives qui vont lui dire d’utiliser HTTPS pour une durée d’un an en prenant en compte les sous domaines (dans le cas par exemple ou vous servez vos images à partir d’un sous domaines).
Bien sûr comme on modifie l’en tête envoyé aux clients il faut avoir pris soin d’activer le module headers d’Apache auparavant:
a2enmode headers
service apache reload
Avec cette petite directive vous allez protéger vos utilisateurs et votre site, pas mal ?
CSP
CSP ou Content Security Policy est là aussi une brique très intéressante pour renforcer la sécurité de votre site web. C’est en gros ce qui va dire au client que pour mon site il ne doit charger que ce qui vient des serveurs que j’ai spécifié. Par exemple lorsque que vous chargez le blog plusieurs fichiers sont appelés comme des scripts, des polices, etc… CSP va permettre d’être sûr que ces fichiers viennent bien de l’endroit décidé par l’éditeur du site et donc qu’ils sont fiables. Cela va éviter les attaques par injection (XSS)qui feraient charger des scripts malicieux au client. Là aussi ce sont des infos qui se transmettent via l’en tête vous pouvez donc les placer au même endroit que HSTS par exemple.
Un peu plus « dangereuse » pour l’administrer elle est à utiliser avec précaution
Pour Apache la configuration
Header set Content-Security-Policy "default-src 'self'" permet de gérer grossièrement la plupart des cas.
Elle signifie que toutes les ressources par défaut (Polices, images, scripts,etc…) doivent être chargée par « self » soit le serveur émetteur de l’en tête lui même.
Il existe beaucoup d’autres options qui permettent d’être plus fin. Elles sont détaillées sur le site dédié. Avec WordPress il faut aussi prendre ses précautions.
Deux directives pas très compliquées à mettre en place et qui permettent d’augmenter grandement la sécurité de vos utilisateurs et de votre site. N’ayant pas eu encore l’occasion de tester sur Nginx je vous invite à vous renseigner sur la configuration adéquate. J’ai conscience que j’ai pu être un peu approximatif dans les explications mais c’est uniquement par désir de simplification. Ce sont des sujets nouveaux pour moi et j’essaie de me les approprier afin de les utiliser correctement et de pouvoir vous les expliquer donc je suis preneur des commentaires constructifs de connaisseurs qui passeraient par là !