Aller au contenu principal

HSTS et CSP

Sécurisation des communications et protection contre les attaques Web

Notions théoriques​

Les sites Web modernes doivent protéger les utilisateurs contre diverses attaques.

3 mécanismes de sécurité HTTP permettent d'améliorer la protection des communications et des données :

  • HSTS (HTTP Strict Transport Security) : Oblige un navigateur à utiliser HTTPS pour éviter les attaques de type "downgrade" vers HTTP.
  • CSP (Content Security Policy) : Protège contre les attaques XSS (Cross-Site Scripting) en limitant les sources de contenu autorisées.
HPKP

Il existe un ancien mécanisme, le HPKP (HTTP Public Key Pinning)** qui permettait de lier un site Web à une clé publique spécifique pour prévenir les attaques par faux certificats.

HPKP a été abandonné car une mauvaise configuration pouvait bloquer l'accès à un site de manière irréversible.

HSTS : Protection contre les attaques downgrade​

HSTS est un en-tête HTTP qui force l'utilisation de HTTPS. Lorsqu'un navigateur visite un site avec HSTS activé, il enregistre cette règle et refusera toute connexion en HTTP.

Fonctionnement :

  1. Le serveur envoie l'en-tête Strict-Transport-Security avec une durée (max-age).
  2. Le navigateur applique cette règle pour toutes les connexions futures.
  3. Toute tentative de connexion en HTTP est automatiquement redirigée vers HTTPS.

Exemple d'en-tête HSTS :

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

CSP : Protection contre les attaques XSS​

CSP est un en-tête HTTP qui contrôle les sources de contenu autorisées sur une page Web.

L'en-tête HTTP CSP empêche l'exécution de scripts malveillants injectés par un attaquant.

Fonctionnement :

  1. Le serveur envoie une politique CSP définissant les sources autorisées.
  2. Le navigateur bloque tout contenu ne respectant pas cette politique.

Exemple d'en-tête CSP :

Content-Security-Policy: default-src 'self'; script-src 'self' https://apis.example.com

Cette règle autorise uniquement les scripts provenant du même domaine ('self') et de apis.example.com.

Exemple pratique​

Il est possible de tester HSTS et CSP en configurant un serveur Web et en observant le comportement du navigateur.

1) Configuration de HSTS​

  1. Modifier la configuration du serveur (Apache ou Nginx).
  2. Ajouter l'en-tête HSTS :

sous apache​

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

sous nginx​

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
  1. Redémarrer le serveur et tester avec Chrome en tapant chrome://net-internals/#hsts.

2) Test de HSTS​

  1. Accéder au site en HTTP (http://example.com).
  2. Vérifier que la redirection vers HTTPS est automatique.

3) Configuration de CSP​

  1. Ajouter l'en-tête CSP :

sous apache​

Header set Content-Security-Policy "default-src 'self'; script-src 'self' https://apis.example.com"

sous nginx​

add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://apis.example.com";
  1. Tester en insérant un script non autorisé dans la console du navigateur.

4) Observation des violations CSP​

  1. Ouvrir la console du navigateur (F12 > Console).
  2. Essayer d'exécuter un script inline :
alert("Test CSP");
  1. Observer si le navigateur bloque l'exécution.

Test de mémorisation/compréhension​


Quel est le rôle principal de HSTS ?


Pourquoi HPKP a-t-il été abandonné ?


Quel en-tête HTTP est utilisé pour activer CSP ?


Quelle directive CSP permet d'autoriser uniquement les scripts du même domaine ?


Que se passe-t-il si un site avec HSTS activé est accédé en HTTP ?


Quel est le problème principal de HPKP ?


Quelle directive CSP bloque tous les scripts externes ?


Comment tester si un site utilise HSTS ?


Que signifie 'preload' dans HSTS ?


Quelle attaque CSP aide à prévenir ?


TP pour réfléchir et résoudre des problèmes​

L'objectif de ce TP est d'analyser le comportement de HSTS et CSP sur un site Web en utilisant un navigateur et les outils de développement.

1) Vérification de la présence de HSTS sur un site​

  1. Ouvrir Google Chrome ou Mozilla Firefox.
  2. Accéder au site https://www.google.com.
  3. Ouvrir les outils de développement (F12) et aller dans l'onglet Network.
  4. Recharger la page (F5) et sélectionner la première requête vers www.google.com.
  5. Vérifier la présence de l'en-tête Strict-Transport-Security dans l'onglet Headers.
Une solution

2) Observation du comportement de HSTS​

  1. Ouvrir un terminal ou l'invite de commande.
  2. Tenter d'accéder à Google en HTTP avec la commande suivante :
curl -I http://www.google.com
  1. Observer la réponse du serveur.
Une solution

3) Test de l'effet de HSTS dans le navigateur​

  1. Ouvrir Chrome.
  2. Aller à chrome://net-internals/#hsts.
  3. Dans la section Query HSTS/PKP domain, entrer google.com et cliquer sur Query.
  4. Observer les informations affichées.
Une solution

4) Vérification de la politique CSP d'un site​

  1. Accéder au site https://www.wikipedia.org.
  2. Ouvrir les outils de développement (F12) et aller dans l'onglet Network.
  3. Sélectionner la requête principale vers www.wikipedia.org.
  4. Rechercher l'en-tête Content-Security-Policy dans l'onglet Headers.
Une solution

5) Test de la politique CSP en injectant un script​

  1. Ouvrir la console du navigateur (F12 > Console).
  2. Essayer d'exécuter un script inline :
alert("Test CSP");
  1. Observer si le navigateur bloque l'exécution.
Une solution

6) Tentative de chargement d'un script externe non autorisé​

  1. Dans la console du navigateur, tenter d'ajouter un script externe :
var script = document.createElement('script');
script.src = "http://example.com/malicious.js";
document.body.appendChild(script);
  1. Observer la réponse du navigateur.
Une solution

7) Analyse des violations CSP dans la console​

  1. Ouvrir les outils de développement (F12).
  2. Aller dans l'onglet Console.
  3. Observer les erreurs liées à CSP.
Une solution

8) Modification temporaire de CSP pour tester une exception​

  1. Ouvrir les outils de développement (F12).
  2. Aller dans l'onglet Network, puis Headers.
  3. Modifier temporairement l'en-tête Content-Security-Policy dans les requêtes (possible avec certaines extensions comme ModHeader).
  4. Ajouter unsafe-inline à la directive script-src.
  5. Retenter d'exécuter un script inline.
Une solution