Les risques liés à l'exécution de HTTP augmentent mais restent gérables

Que cela nous plaise ou non, HTTP est le protocole de transport application de facto de l’ère moderne. Nous l'utilisons partout. Il est aussi omniprésent que l’IP et le TCP et remplit à peu près le même objectif. Son seul objectif est de transporter l’or numérique des entreprises d’aujourd’hui : les données.

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

Contrairement à IP et TCP, HTTP est un protocole basé sur du texte. Il est très flexible et peut transporter une grande variété de données, du binaire au texte. Nous l'utilisons pour diffuser des données, pour récupérer des données et pour collecter des données.

Les attaquants l’utilisent généreusement car, comme mentionné, il s’agit d’un protocole basé sur du texte avec des règles assez laxistes concernant les extensions des en-têtes qui spécifient tout, depuis l’action que le client attend du serveur (la « méthode » HTTP) jusqu’à la ressource demandée (l’URI) jusqu’au type de contenu qui peut être accepté (les en-têtes « Accepter »). Ces règles sont laxistes pour permettre l’extensibilité.

Par exemple, l' en-tête X-Forwarded-For a été introduit comme moyen de garantir que les développeurs pouvaient « voir » l'adresse IP du client d'origine. Dans certaines architectures – notamment celles dans lesquelles les intermédiaires agissent comme des proxys complets – ces informations peuvent être perdues. Certaines applications ont besoin de ces données, et donc les développeurs (et les fournisseurs de réseaux) ont étendu le protocole HTTP en introduisant un en-tête personnalisé. Cela fait partie de la spécification HTTP ; elle permet l’innovation et l’introduction de nouveaux comportements et fonctionnalités sans nécessiter de modifications du protocole. C'est une bonne chose.

Sauf quand ce n’est pas le cas.

Ce n’est pas une bonne chose que cette flexibilité ne soit pas prise en compte par les développeurs des serveurs prenant en charge HTTP ou par ceux responsables de la sécurisation des applications qui s’appuient sur HTTP.

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

Honnêtement, une recherche dans les CVE connus pour les vulnérabilités HTTP renvoie une liste excessivement longue (et comprend une grande variété de fournisseurs et de logiciels) que je ne vais pas dupliquer ici. Une partie importante d’entre eux sont généralement déclenchés par l’utilisation abusive d’un en-tête HTTP.

Une note sur Optionsbleed 

Optionsbleed est l’une des vulnérabilités les plus récentes. Je l'appelle parce qu'il existe dans Apache HTTP lui-même. Étant donné que Netcraft estime actuellement qu'Apache fonctionne sur « plus de 2,8 millions d'ordinateurs connectés au Web qui exécutent actuellement diverses versions et dérivés d' Apache httpd , ce qui lui donne une part de 42,8 % de tous les ordinateurs connectés au Web », les vulnérabilités de ce dernier deviennent un risque important. Heureusement, cette vulnérabilité particulière est déclenchée via un en-tête HTTP mais nécessite également l'existence d'une directive Limits mal configurée dans le fichier .htaccess . Cet article de Sophos fournit un excellent aperçu des détails techniques sanglants si vous le souhaitez. En résumé, si la mauvaise configuration existe, un attaquant peut exploiter une vulnérabilité dans Apache via l'en-tête de la méthode HTTP et (semble-t-il) forcer le serveur à « purger » des données appartenant à, eh bien, quelqu'un d'autre.

Maintenant, j’ai dit tout cela, donc je peux dire ceci : la sécurité des applications est une pile. Cette pile comprend les plateformes (et donc les protocoles) sur lesquelles s’appuient les applications . Comme HTTP.

Nous devons faire un meilleur travail pour protéger HTTP contre les abus visant à compromettre la sécurité. Qu'il s'agisse d'une fuite de données, d'un déni de service ou d'un accès à distance n'est pas le problème. Ce sont tous des impacts négatifs. Nous devons mieux reconnaître que HTTP est une surface d’attaque de plus en plus populaire. Le fait qu'il soit basé sur du texte signifie que l'ensemble de l'interaction entre un client et le service HTTP doit être classé comme une entrée utilisateur .

Cela devrait, à son tour, encourager une stratégie de sécurité qui inclut la désinfection de cette entrée. Oui, cela implique l’application du protocole et le nettoyage en amont (avant qu’il n’atteigne un serveur HTTP potentiellement vulnérable).

Cela signifie qu'un pare-feu application Web ou un proxy programmable doit se trouver devant tout service HTTP public et s'engager activement dans le nettoyage des requêtes HTTP entrantes.

La raison en est 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 pointer du doigt les développeurs et blâmer les pratiques de codage non sécurisées pour les vulnérabilités au niveau de la plateforme.

Le patching est bien sûr la solution ultime. À condition que (1) vous entendiez parler de la vulnérabilité dès le jour zéro, (2) qu'un correctif soit mis à disposition dès le jour zéro et (3) que vous soyez à l'aise pour déployer un correctif potentiellement non testé sur les systèmes de production.

Vous devez appliquer les correctifs, ne vous méprenez pas, mais il existe un écart entre la divulgation, la découverte, la disponibilité et application. C’est dans cette lacune que réside le risque : le risque qu’une vulnérabilité très facile à exploiter soit utilisée contre vous.

L'avant-dernière solution consiste à s'assurer qu'il existe un système (une plate-forme) sur lequel vous pouvez déployer des solutions de correction immédiates telles que des scripts ou une analyse basée sur les signatures pour empêcher l'exploitation pendant que vous vous préparez à appliquer le correctif.

Le nettoyage des données entrantes et l’application de l’exactitude du protocole doivent faire partie intégrante de toute politique de sécurité d’entreprise.

HTTP est de plus en plus risqué, mais il est également gérable si vous vous rappelez que la sécurité des applications est une pile et que vous passez ensuite à la mise en place de protections à chaque couche de cette pile.