Le 18 juillet 2016, une vulnérabilité baptisée « HTTPoxy » a été annoncée. Elle affecte certaines applications web côté serveur qui s’exécutent dans des environnements CGI ou similaires, notamment certaines configurations FastCGI. À ce jour, les langages connus pour être concernés comprennent PHP, Python et Go.
Plusieurs CVE ont été attribuées, couvrant des langages et des implémentations CGI spécifiques :
- Serveur HTTP Apache (CVE-2016-5387)
- Apache Tomcat (CVE-2016-5388)
- Go (CVE-2016-5386)
- PHP (CVE-2016-5385)
Il existe un nouveau site web décrivant la vulnérabilité, une note de vulnérabilité du CERT, ainsi qu’une description de la découverte de la vulnérabilité. Des informations complémentaires sont disponibles sur le site personnel de Dominic Scheirlinck, développeur web open source chez Vend.
Cet article décrit la vulnérabilité et explique comment utiliser NGINX ou NGINX Plus pour empêcher toute tentative de l’exploiter sur vos serveurs.
La vulnérabilité est due à un conflit d’espaces de noms. Une interface de type CGI ou FastCGI définit des variables d’environnement à partir des paramètres de la requête HTTP, lesquelles peuvent remplacer les variables internes utilisées pour configurer l’application.
À l’heure actuelle, la seule exploitation connue de cette vulnérabilité concerne les applications web exécutées dans des environnements CGI ou similaires qui utilisent certaines bibliothèques clientes HTTP pour envoyer des requêtes HTTP à d’autres services. Dans ce cas, les attaquants peuvent potentiellement rediriger les requêtes internes générées par l’application vers un serveur de leur choix et ainsi intercepter toutes les données confidentielles contenues dans ces requêtes, comme illustré ci-dessous.
HTTPoxy exploite un chevauchement d’espaces de noms pour accéder au trafic interne du serveur
Vous pouvez utiliser NGINX ou NGINX Plus pour détecter et contrer les tentatives d’exploitation de cette vulnérabilité. Vous disposez ainsi d’un moyen efficace de prévenir toute attaque, ce qui vous laisse le temps d’auditer et de mettre à jour le code concerné.
Comment la vulnérabilité HTTPoxy est exploitée
Pour comprendre le fonctionnement de cette vulnérabilité – et savoir comment protéger votre site contre celle-ci –, il est nécessaire de comprendre comment les interfaces CGI et similaires définissent les variables d’environnement et comment certaines bibliothèques d’applications sont configurées par ces variables.
1 – Les interfaces CGI et similaires définissent des variables d’environnement nommées HTTP_*
De nombreuses plateformes d’applications web utilisent des interfaces CGI ou similaires pour connecter les applications à un serveur web. Ces interfaces convertissent les en-têtes d’une requête HTTP en variables d’environnement précédées de HTTP_. Une application peut alors retrouver la valeur des en-têtes de la requête (tels que User-Agent) en consultant son environnement.
Un client peut créer des variables d’environnement arbitraires (commençant par « HTTP_ ») dans l’environnement de l’application en envoyant des requêtes contenant l’en-tête approprié. Par exemple, l’en-tête de requête « Foo: bar » devient la variable d’environnement HTTP_FOO=bar.
Certaines plateformes fournissent une couche d’abstraction qui masque les variables d’environnement, comme la variable globale $_SERVER de PHP. Néanmoins, ces abstractions reposent sur la pratique standard de CGI et FastCGI consistant à définir des variables d’environnement.
Par exemple, lorsqu’elle s’exécute en mode FastCGI, une application PHP peut déterminer l’en-tête User-Agent d’une requête comme suit :
// both methods return the same result$useragent = getenv( 'HTTP_USER_AGENT' );
$useragent = $_SERVER['HTTP_USER_AGENT'];2 – Certaines bibliothèques d’applications sont configurées à partir de variables d’environnement
Une application web complexe intègre des fonctionnalités provenant de bibliothèques externes. Par exemple, les applications doivent parfois envoyer des requêtes HTTP à d’autres services (selon une architecture de type microservices) et peuvent pour cela utiliser l’une des bibliothèques tierces courantes. Ces bibliothèques prennent souvent en charge une fonctionnalité appelée « proxy HTTP », qui est un serveur intermédiaire utilisé pour relayer la requête HTTP.
Un moyen simple de configurer une telle bibliothèque consiste à définir sa configuration au moyen de variables d’environnement. La bibliothèque PHP Guzzle, largement utilisée, est configurée en partie par une variable d’environnement nommée HTTP_PROXY, dont la valeur correspond à l’adresse d’un serveur proxy. Lorsque HTTP_PROXY est définie de cette manière, la bibliothèque transmet toutes les requêtes HTTP qu’elle génère à l’adresse du serveur proxy. Le paquet net/http de Go et le module Requests de Python font également confiance à la variable d’environnement HTTP_PROXY et l’interprètent de la même manière.
3 – La nature de la vulnérabilité
Les bibliothèques décrites au point 2 n’ont pas été conçues pour les interfaces CGI ou similaires, et la variable d’environnement HTTP_PROXY à laquelle elles font confiance empiète sur l’espace de noms HTTP_ utilisé par les interfaces CGI et FastCGI, comme indiqué au point 1.
En définissant la valeur de la variable d’environnement « HTTP_PROXY » sur une adresse de leur choix, les attaquants peuvent rediriger et intercepter les requêtes HTTP internes générées par l’application. Ces requêtes peuvent contenir des informations sensibles, telles que des clés d’authentification et des données privées, et révéler des informations sur d’autres API et points de terminaison susceptibles d’être exploités.
Un attaquant peut procéder ainsi en envoyant une requête avec un en-tête « Proxy ». L’interface CGI ou FastCGI crée alors automatiquement une variable d’environnement nommée HTTP_PROXY pour cette exécution de l’application. Notez que seules les requêtes contenant l’en-tête « Proxy » frauduleux sont directement affectées.
Contrer l’attaque à l’aide de NGINX et NGINX Plus
La vulnérabilité HTTPoxy n’affecte pas directement NGINX, mais NGINX et NGINX Plus peuvent être utilisés pour bloquer les attaques qui exploitent cette vulnérabilité.
Communication avec une application FastCGI en amont
Vous pouvez utiliser NGINX pour « assainir » les données transmises à l’application en définissant le paramètre FastCGI HTTP_PROXY sur une chaîne vide. Le paramètre est ainsi entièrement supprimé de la requête FastCGI :
fastcgi_param HTTP_PROXY "";Répartition de charge et mise en proxy du trafic HTTP
Lors de la transmission de requêtes HTTP à une application en amont via un proxy, il est prudent de définir tout en-tête « Proxy » sur une chaîne vide, au cas où l’application en amont s’exécuterait sur une plateforme vulnérable :
proxy_set_header Proxy "";Détection des tentatives d’exploitation de la vulnérabilité
Proxy n’est pas un en-tête HTTP standard, de sorte que toute requête contenant cet en-tête peut être considérée comme suspecte. Vous pouvez utiliser NGINX ou NGINX Plus pour consigner ces requêtes suspectes dans un journal d’accès dédié, nommé ici badactor.log :
# define 'proxylog' format in the http{} context:log_format proxylog '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent" '
'"$http_proxy"';
# log requests with a Proxy header using the 'proxylog' format
access_log /var/log/nginx/badactor.log proxylog if=$http_proxy;Remarque: dans le contexte de configuration où vous placez cette directive « access_log », celle-ci remplace toute journalisation des accès définie à un niveau supérieur dans la configuration NGINX.
Restez en sécurité
NGINX et NGINX Plus permettent de surveiller et de contrer efficacement l’attaque HTTPoxy. Utilisez les techniques décrites ci-dessus pour protéger votre application pendant que vous auditez, mettez à jour et testez votre code afin d’éliminer la vulnérabilité.
Si vous avez des questions, veuillez laisser un commentaire sur cet article – ou, si vous êtes abonné à NGINX Plus, n’hésitez pas à contacter notre équipe d’assistance pour obtenir de l’aide.
À propos de l’auteur
Articles de blog associés
Tendances actuelles des technologies cloud natives, de l’ingénierie de plateforme et de l’IA
Découvrez les principaux enseignements tirés des réponses à l’enquête annuelle F5 NGINX sur les dernières tendances en matière de technologies cloud natives, de sécurité, d’ingénierie de plateforme et d’IA.
Quels contrôleurs Ingress NGINX sont affectés par les vulnérabilités CVE-2022-4886, CVE-2023-5043 et CVE-2023-5044 ?
Lorsque de nouvelles CVE sont signalées, il est facile de ne plus savoir si elles concernent un outil de contrôleur Ingress NGINX particulier, car il existe plusieurs projets. Cet article présente les CVE et explique comment distinguer les différents projets de contrôleurs Ingress afin de dissiper toute confusion.
Votre API est-elle en temps réel ? Testez sa latence avec l’outil rtapi de NGINX
Votre API répond-elle aux requêtes en moins de 30 ms ? Si ce n’est pas le cas, il ne s’agit pas d’une API en temps réel offrant la faible latence exigée par la grande majorité des organisations. Mesurez la latence de votre API avec l’outil rtapi de NGINX et découvrez comment NGINX peut l’aider à offrir une réactivité en temps réel.
Un testeur d’expressions régulières pour NGINX et NGINX Plus
Le testeur d’expressions régulières (regex) pour NGINX et NGINX Plus vous évite de tâtonner en vous indiquant si une expression régulière utilisée dans un bloc location ou map correspond aux valeurs comme prévu. Il génère la configuration appropriée et affiche les valeurs des groupes de capture.
Caches partagés avec les clusters de cache NGINX Plus, partie 1
Optimisez la capacité de votre cache web en le répartissant entre plusieurs serveurs de cache web NGINX ou NGINX Plus. Découvrez comment procéder dans cet article.
Introduction aux microservices
Les microservices suscitent actuellement beaucoup d’intérêt. Cet article de blog est le premier d’une série de sept consacrée à la conception, au développement et au déploiement de microservices.