Implications des en-têtes de réponse HTTP en matière de sécurité

Lorsqu’un serveur web reçoit une requête HTTP, il la traite puis renvoie une réponse contenant la ressource demandée et des informations complémentaires sous forme d’en-têtes de réponse HTTP. Ces en-têtes fournissent des données importantes, comme les dates de dernière modification, les types de contenu et les paramètres de contrôle du cache. Le navigateur utilise ensuite ces informations pour déterminer comment afficher ou stocker la ressource en question. Ce processus contribue à assurer une communication efficace entre les serveurs web et les navigateurs.

Du point de vue de la cybersécurité, les en-têtes de réponse HTTP constituent des vecteurs d’attaque potentiels, mais aussi des occasions de renforcer la défense. Ils peuvent contenir des données sensibles, comme des jetons d’authentification, des cookies et des identifiants de session qui, une fois récupérés, permettent aux attaquants de contourner les contrôles d’autorisation ou de détourner des comptes utilisateur. Mais nous pouvons aussi les utiliser pour contrôler la mise en cache, préciser le type de contenu renvoyé et empêcher des attaques comme le cross-site scripting (XSS) et le clickjacking.

Les en-têtes de réponse HTTP offrent plusieurs fonctionnalités de sécurité, notamment l’authentification, le suivi de l’agent utilisateur, la prévention du XSS et l’application de l’utilisation de HTTPS. Certains en-têtes HTTP, comme Etag, Last-Modified et Content-Type, ne sont pas utiles à des fins de sécurité. En revanche, les en-têtes Content Security Policy (CSP), HTTP Strict Transport Security (HSTS) et X-Frame-Options permettent de renforcer la sécurité de nos serveurs.

Cet article met en lumière plusieurs en-têtes HTTP qui ont un impact sur la sécurité et présente les bonnes pratiques pour utiliser les en-têtes de réponse HTTP afin de sécuriser les applications web.

Utiliser les en-têtes de réponse HTTP pour renforcer la sécurité

Nous pouvons utiliser les en-têtes de réponse HTTP pour atténuer plusieurs types de vulnérabilités exploitables.

Vulnérabilités à prendre en compte concernant les en-têtes de réponse HTTP

Les en-têtes de réponse HTTP adaptés permettent d’atténuer les exploits directs et de remédier à des vulnérabilités qui ne les concernent pas directement. Voici quelques exemples de différents types d’exploits et de vulnérabilités :

• Falsification de requête intersites (CSRF) : les attaquants peuvent utiliser CSRF, aussi appelée attaque en un clic, pour forcer le navigateur web d’un utilisateur à effectuer des actions indésirables en son nom.

• Détournement de session : les attaquants obtiennent un accès non autorisé en volant les identifiants de session d’utilisateurs authentifiés et en détournant leurs sessions existantes, sans avoir besoin d’identifiants comme une combinaison nom d’utilisateur et mot de passe. Ils contournent ainsi les systèmes d’authentification traditionnels.

• Fuite de données : les en-têtes de réponse HTTP peuvent contenir des mots de passe, des numéros de carte bancaire et d’autres informations sensibles qui risquent d’être divulgués s’ils ne sont pas correctement configurés.

• Attaques de l’homme du milieu (MITM) : les attaquants utilisent des attaques MITM pour intercepter, modifier ou bloquer les communications entre deux parties lors d’une transaction. Aucune des deux parties ne sait que l’autre communique avec un tiers non autorisé.

• Attaques par clickjacking : en exploitant les failles des jeux de cadres HTML d’un site web, les attaquants peuvent afficher aux utilisateurs un contenu usurpé. Lorsque ceux-ci cliquent dessus, ils effectuent des actions involontaires ou divulguent sans le savoir des informations confidentielles.

La sécurité des applications web est essentielle, surtout face aux nombreuses possibilités d’attaque. Ces dernières années, nous avons constaté une hausse des violations de sécurité très médiatisées et aux conséquences importantes. Par exemple :

• Lors d’une récente fuite de données impliquant TransUnion, une société d’évaluation du crédit, des attaquants ont retenu en otage les informations de plus de 50 millions de Sud-Africains en échange d’une rançon de 15 millions de dollars.

• Les extensions WordPress liées au RGPD peuvent être vulnérables aux attaques XSS et CSRF. L’une d’elles a touché 10 000 sites web en 2018, et une autre a exposé 700 000 sites web en 2020.

• Les grandes entreprises technologiques sont des cibles de choix. Heureusement pour Uber, la société de covoiturage, les vulnérabilités CSRF et de détournement de session ne lui ont coûté qu’environ 5 000 dollars en récompenses de bug bounty.

Face à la fréquence et à l’ampleur des attaques, il est évident qu’il est impératif de renforcer et de maintenir la sécurité, notamment grâce aux en-têtes HTTP.

En-têtes de réponse HTTP ayant un impact sur la sécurité

La fuite de données est une vulnérabilité directement liée aux en-têtes de réponse HTTP. Les attaques CSRF, le détournement de session et les attaques MITM ne font pas nécessairement intervenir ces en-têtes. Nous pouvons toutefois les atténuer à l’aide d’en-têtes HTTP sécurisés, comme CSP et HTTP Strict Transport Security (HSTS), et en appliquant les bonnes pratiques d’utilisation des autres en-têtes ayant un impact sur la sécurité, comme ceux présentés ci-dessous.

En-tête HTTP Strict Transport Security

L’en-tête de réponse HSTS protège les applications contre les attaques MITM, les fuites de données et le clickjacking. Il oblige toutes les communications entre le navigateur et le serveur à passer par des connexions HTTPS plutôt que par HTTP en clair. Il empêche les attaquants de rediriger le trafic vers leurs serveurs proxy malveillants pour accéder aux données sensibles échangées ou les manipuler à l’insu des deux parties.

HSTS contient des informations sur les règles de sécurité d’un site web, notamment :

• La durée d’activité de la connexion (max-age).

• L’inclusion ou non des sous-domaines dans le périmètre de protection.

• Les types de certificats acceptés.

Pour utiliser au mieux l’en-tête de réponse HSTS, il est recommandé de toujours définir une durée maximale. Celle-ci doit correspondre à la période pendant laquelle nous souhaitons que les clients se souviennent de se connecter de manière sécurisée avant d’envoyer une nouvelle requête via le tunnel TLS/SSL.

En-tête Content-Security-Policy

CSP est essentiel pour se défendre contre différents types d’attaques. Il permet aux développeurs d’établir une liste d’autorisation de ressources et de leurs origines, de définir des directives, de décider si les scripts intégrés ou eval() sont autorisés et de déterminer si les attributs de style sont permis dans le HTML.

L’en-tête de réponse HTTP Content-Security-Policy permet de définir les domaines et les ressources autorisés ou bloqués dans le contenu d’un site web. Il protège contre le XSS et les vulnérabilités citées précédemment, ainsi que contre d’autres activités malveillantes comme le clickjacking, l’injection de données, l’injection de code, le CSRF et l’accès non autorisé à des informations sensibles. CSP comprend des directives qui indiquent aux navigateurs comment gérer les requêtes provenant de sources non fiables en dehors de notre domaine, notamment pour le chargement de scripts, d’images et d’autres ressources exploitables.

Voici quelques conseils pour configurer l’en-tête CSP et prévenir les vulnérabilités :

• Privilégiez, dans la mesure du possible, les règles qui bloquent les activités plutôt que celles qui les autorisent. Les requêtes provenant de sources non fiables en dehors de votre domaine seront ainsi bloquées par défaut.

• Utilisez des sous-domaines génériques (préfixe *.<your-domain-name> avant le nom de votre domaine principal).

• Limitez l’accès aux sources fiables connues au lieu d’autoriser largement les requêtes depuis n’importe quelle source. Incluez également des directives indiquant comment les navigateurs doivent gérer certaines requêtes provenant de sources non fiables en dehors de notre domaine, par exemple pour le chargement de scripts, d’images et d’autres ressources exploitables.

Une posture de sécurité stricte garantit que seuls les clients autorisés peuvent consulter les informations sensibles et empêche les fuites de données par des canaux en aval involontaires. Nous pouvons aussi utiliser des mécanismes de validation stricts, comme Subresource Integrity (SRI), qui permettent de vérifier l’intégrité des ressources d’un site web et de s’assurer qu’un attaquant ne les a pas altérées.

En combinant SRI et CSP, nous pouvons garantir que seules des ressources tierces fiables et intactes sont chargées dans nos pages web.

En-tête X-Content-Type-Options

Nous pouvons utiliser l’en-tête X-Content-Type-Options pour indiquer aux navigateurs de ne jamais tenter de détecter automatiquement le type de fichier ou de contenu servi. Il devient ainsi beaucoup plus difficile pour un attaquant d’injecter du code malveillant dans un site web, car le navigateur ne pourra pas analyser ni exécuter de fichiers de script arbitraires qui lui seraient transmis. L’en-tête X-Content-Type-Options constitue donc une première ligne de défense contre les contenus malveillants et les attaques XSS.

Lors de la configuration et de l’utilisation de cet en-tête, veillez à ce que tous les sites servent leur contenu avec des types MIME strictement définis. Évitez autant que possible d’utiliser des caractères génériques (*) dans ces valeurs. En indiquant les types de fichiers réels, vous précisez aux navigateurs les ressources auxquelles ils doivent s’attendre, sans qu’ils aient à les détecter automatiquement.

En-tête X-Frame-Options

X-Frame-Options protège les applications web contre les attaques par clickjacking. Il contient une directive qui indique au navigateur s’il peut afficher le contenu dans un élément <iframe> sur un site web tiers.

Deux directives sont couramment utilisées. DENY empêche toute tentative d’intégration de la ressource demandée dans d’autres sites. SAMEORIGIN n’autorise la requête que si les deux pages respectent la même politique d’origine. Cette configuration contribue à se défendre contre le clickjacking et d’autres vulnérabilités de sécurité liées au XSS.

Il est préférable de veiller à ce que toutes les ressources servies par l’application web incluent toujours X-Frame-Options, avec DENY plutôt que SAMEORIGIN. Nous devrions également appliquer par défaut le niveau de protection maximal, car nous ne pouvons jamais savoir avec certitude quand ni comment du contenu peut sortir du cadre de notre politique d’origine.

En-tête Referrer-Policy

L’en-tête Referrer-Policy contrôle la transmission des informations de provenance d’une application ou d’un site web à un autre. Il comporte quatre directives principales — none, no-referrer, no-referrer-when-downgrade et origin — qui déterminent comment un navigateur partage l’URL de provenance avec d’autres sites ou applications lors de la navigation.

Nous pouvons configurer cet en-tête selon nos besoins afin d’éviter toute exposition accidentelle de données sensibles lorsque les utilisateurs naviguent entre plusieurs sites ou domaines.

Il est préférable de définir Referrer-Policy sur no-referrer afin que les en-têtes de requête ne contiennent pas d’informations de provenance lorsque les utilisateurs cliquent sur des liens externes. Ce paramètre protège leur vie privée en empêchant toute fuite de données personnelles par des canaux non souhaités.

Définir des en-têtes de sécurité en JavaScript

La section suivante présente trois outils permettant de définir des en-têtes de sécurité lors du développement en JavaScript. Notez que vous pouvez également les utiliser avec d’autres langages de programmation et écosystèmes.

Après avoir passé en revue chaque outil, nous vous proposerons un exemple pratique de configuration des en-têtes de sécurité.

Helmet pour Express.js

Helmet est une collection d’en-têtes de réponse HTTP liés à la sécurité, qui contribuent à protéger les applications web contre les attaques et les vulnérabilités. Helmet pour Express.js est une extension du package Helmet conçue spécifiquement pour fonctionner avec le framework Express.js. Elle fournit neuf fonctions middleware plus petites qui définissent des en-têtes de réponse HTTP spécifiques liés à la sécurité des applications.

La configuration de Helmet pour Express.js est simple. Commencez par installer Helmet à l’aide de cette commande :

1npm install helmet

Utilisez ensuite le code suivant pour importer le framework Express et le package Helmet afin d’utiliser leurs fonctions middleware. Vous pourrez ainsi définir les en-têtes de réponse :

1const express = require("express");
2const helmet = require("helmet");

Utilisez ensuite ce code pour créer une instance d’application Express, l’assigner à une variable et commencer à utiliser les fonctions middleware de Helmet :

1const app = express();
2app.use(helmet());

L’initialisation de Helmet définit plusieurs en-têtes de sécurité, dont les cinq présentés ci-dessus. Vous pouvez personnaliser les options de chaque en-tête dans Helmet pour Express.js en les ajoutant au middleware helmet() à l’aide du code suivant :

1app.use(
2  helmet({
3    X-Frame-Options: { policy: "DENY" },
4  })
5);

Helmet pour Fastify

Helmet for Fastify est un package middleware qui permet d’ajouter des en-têtes de sécurité importants au framework web Fastify. Il s’agit essentiellement d’un wrapper autour de Helmet, qui accepte les mêmes options.

Installez Helmet pour Fastify en exécutant la commande suivante :

1npm i @fastify/helmet.

Importez ensuite le framework Fastify et Helmet pour Fastify à l’aide de ce code :

1const fastify = require('fastify');
2const helmet = require('@fastify/helmet');

Enregistrez ensuite le plugin Helmet auprès de votre application en exécutant ce code :

1fastify.register(helmet);

Cette commande définira automatiquement les en-têtes de sécurité de base.

check-my-headers

Check-my-headers est un outil CLI gratuit qui permet de tester rapidement les en-têtes HTTP de notre site web afin d’y détecter d’éventuelles vulnérabilités. Il est gratuit et indépendant de tout framework : il vérifie nos en-têtes sans se soucier de la méthode utilisée pour les définir.

Nous pouvons l’installer globalement avec npm install -g check-my-headers, puis lancer une analyse ponctuelle en saisissant npx check-my-headers https://yourwebsite.com dans le CLI.

Conclusion 

Plusieurs en-têtes de réponse HTTP essentiels ont un impact sur la sécurité web. Les utiliser conformément aux bonnes pratiques ajoute une couche de protection aux applications web. Les cinq en-têtes présentés ici contribuent à se protéger contre diverses vulnérabilités, comme les attaques CSRF, le détournement de session, les fuites de données, les attaques de type MITM et le clickjacking — qui peuvent causer des dommages considérables, souvent irréparables. Comprendre comment les en-têtes de réponse HTTP peuvent affaiblir la sécurité ou y contribuer est une étape importante pour atténuer ces vecteurs d’attaque courants.

Des en-têtes de réponse correctement utilisés et configurés sont essentiels à la sécurité web. Ils protègent la vie privée des utilisateurs et offrent davantage de flexibilité pour sécuriser les communications entre les serveurs web et les clients.