Les risques liés à l’utilisation du protocole HTTP augmentent, mais restent maîtrisables

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

Qu’on le veuille ou non, HTTP est de fait le protocole de transport applicatif de notre époque. Nous l’utilisons partout. Il est aussi omniprésent qu’IP et TCP, et remplit sensiblement la même fonction. Son seul objectif est de transporter l’or numérique des entreprises d’aujourd’hui : les données.

Que ces données soient au format JSON, XML ou encodées dans une URL n’a aucune importance. C’est le protocole HTTP que les applications et les appareils utilisent pour communiquer avec les serveurs et les services dans le cloud et sur site, au sein du centre de données.

Cependant, contrairement à IP et TCP, HTTP est un protocole textuel. Il est extrêmement flexible et peut transporter différents types de données, qu’elles soient binaires ou textuelles. Nous l’utilisons pour diffuser, récupérer et collecter des données.

Les attaquants l’utilisent abondamment car, comme indiqué précédemment, il s’agit d’un protocole textuel dont les règles relatives aux extensions des en-têtes sont assez souples. Ces en-têtes précisent aussi bien l’action que le client attend du serveur (la « méthode » HTTP), que la ressource demandée (l’URI) ou encore le type de contenu pouvant être accepté (les en-têtes « Accept »). Cette souplesse vise à permettre l’extensibilité.

Par exemple, l’en-tête X-Forwarded-For a été introduit afin que les développeurs puissent « voir » l’adresse IP d’origine du client. Dans certaines architectures, notamment celles où les intermédiaires agissent comme des proxys complets, cette information peut être perdue. Certaines applications ont besoin de ces données ; les développeurs (et les fournisseurs d’équipements réseau) ont donc étendu le protocole HTTP en introduisant un en-tête personnalisé. Cette possibilité fait partie de la spécification HTTP : elle permet d’innover et d’introduire de nouveaux comportements et de nouvelles fonctionnalités sans avoir à modifier le protocole. C’est une bonne chose.

Sauf quand ce n’est pas le cas.

Cette flexibilité peut poser problème lorsqu’elle n’est pas prise en compte par les développeurs des serveurs prenant en charge HTTP ou par les personnes chargées de sécuriser les applications qui reposent sur HTTP.

Voici un petit échantillon de CVE liées à HTTP qui exploitent une vulnérabilité dans les en-têtes HTTP :

Honnêtement, une recherche parmi les CVE connues concernant les vulnérabilités HTTP renvoie une liste beaucoup trop longue (qui couvre en outre une grande variété de fournisseurs et de logiciels), que je ne vais pas reproduire ici. Une part importante de ces vulnérabilités est généralement déclenchée par l’exploitation abusive d’un en-tête HTTP.

Remarque sur Optionsbleed

Optionsbleed est l’une des vulnérabilités les plus récentes. Je la mentionne parce qu’elle touche directement Apache HTTP. Sachant que, selon les estimations actuelles de Netcraft, « plus de 2,8 millions d’ordinateurs accessibles sur le Web exécutent actuellement différentes versions et variantes d’Apache httpd, ce qui représente 42,8 % de l’ensemble des ordinateurs accessibles sur le Web », les vulnérabilités qui l’affectent constituent un risque important. Heureusement, cette vulnérabilité particulière est déclenchée par un en-tête HTTP, mais nécessite également la présence d’une directive Limits mal configurée dans le fichier .htaccess . Cet article de Sophos offre un excellent aperçu des détails techniques peu reluisants, si cela vous intéresse. En bref, si cette mauvaise configuration est présente, un attaquant peut exploiter une vulnérabilité d’Apache par l’intermédiaire de l’en-tête de méthode HTTP et, semble-t-il, forcer le serveur à divulguer des données appartenant à quelqu’un d’autre.

Si j’ai dit tout cela, c’était pour en arriver là : la sécurité des applications repose sur un ensemble de couches. Cet ensemble comprend les plateformes (et donc les protocoles) dont dépendent les applications. Comme HTTP.

Nous devons mieux protéger HTTP contre les utilisations abusives susceptibles de compromettre la sécurité. Qu’il s’agisse d’une fuite de données, d’une attaque par déni de service ou d’un accès à distance, là n’est pas la question. Les conséquences sont toujours néfastes. Nous devons mieux prendre en compte le fait que HTTP constitue une surface d’attaque de plus en plus prisée. Comme il repose sur du texte, l’intégralité des échanges entre un client et le service HTTP doit être considérée comme une entrée utilisateur.

Cela devrait, à son tour, favoriser une stratégie de sécurité prévoyant l’assainissement de ces données d’entrée. Oui, cela implique de faire respecter le protocole et de filtrer les données en amont (avant qu’elles n’atteignent un serveur HTTP potentiellement vulnérable).

Cela signifie qu’un pare-feu d’application web ou un proxy programmable doit être placé devant tout service HTTP accessible au public et filtrer activement les requêtes HTTP entrantes.

Cela s’explique par la manière dont les plateformes web traitent les en-têtes HTTP, c’est-à-dire avant même que la requête ne soit vue par un développeur. Nous ne pouvons donc pas nécessairement montrer les développeurs du doigt et imputer les vulnérabilités au niveau de la plateforme à des pratiques de codage non sécurisées.

L’application d’un correctif est bien sûr la solution ultime. À condition que (1) vous soyez informé de la vulnérabilité dès le jour zéro, (2) un correctif soit disponible dès le jour zéro et (3) vous soyez prêt à déployer sur des systèmes de production un correctif qui n’a peut-être pas été testé.

Vous devez appliquer les correctifs, ne vous méprenez pas, mais il existe un délai entre la divulgation d’une vulnérabilité, sa découverte, la mise à disposition d’un correctif et son application. Ce délai comporte un risque : celui qu’une vulnérabilité très facile à exploiter soit utilisée contre vous.

L’avant-dernière solution consiste à s’assurer de disposer d’un système (une plateforme) sur lequel vous pouvez déployer des solutions correctives immédiates telles que des scripts ou une analyse basée sur les signatures afin d’empêcher toute exploitation pendant que vous préparez l’application du correctif.

Le filtrage des données entrantes et le respect strict des protocoles doivent faire partie intégrante de toute politique de sécurité d’entreprise.

HTTP présente des risques croissants, mais ceux-ci restent maîtrisables si vous gardez à l’esprit que la sécurité des applications repose sur un ensemble de couches et que vous mettez en place des protections à chaque niveau.

À propos de l’auteur

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.

Autres articles de Lori Mac Vittie