PHP, Python et d'autres applications de sites Web exposent une vulnérabilité de proxy distant : httpoxy

[Shenzhen] Yuanchuanghui : 17h26, la salle des fêtes vous attend.

Il s'agit d'une vulnérabilité ciblant les applications CGI en PHP, Go, Python et d'autres langages.

httpoxy est le nom d'une famille de vulnérabilités qui affectent les applications qui s'exécutent de manière CGI ou de type CGI. Pour faire simple, il s’agit d’un problème de conflit d’espace de noms.

La RFC 3875 (CGI) définit comment Proxyrenseigner directement les variables d'environnement à partir de l'en-tête de la requête HTTP.HTTP_PROXY
HTTP_PROXYEst une variable d'environnement couramment utilisée pour configurer les agents sortants

Cette faille permet des attaques à distance. Si vous exécutez un programme PHP ou CGI, vous devez bloquer immédiatement l'en-tête Proxy ! immédiatement! Voir ci-dessous pour des instructions spécifiques. httpoxy est une vulnérabilité d'application Web côté serveur. Si vous ne déployez pas ce code côté serveur, vous n'avez pas à vous inquiéter.

Que se passe-t-il si mon application Web présente cette vulnérabilité ?

Lorsqu'un client HTTP qui exploite cette vulnérabilité fait une requête, il peut :

Demandes de proxy vers d'autres URL via votre application Web
Demandez directement à votre serveur d'ouvrir l'adresse distante et le port spécifiés
Gaspiller les ressources du serveur et accéder aux ressources spécifiées pour les attaquants

La vulnérabilité httpoxy est très simple à exploiter. Espérons que le personnel de sécurité analysera cette vulnérabilité dès que possible et la corrigera rapidement.

Lesquels sont concernés ?

Des failles de sécurité peuvent exister dans les situations suivantes :

Le code s'exécute dans un contexte CGI, qui HTTP_PROXYdevient une variable d'environnement réelle ou simulée
Un HTTP_PROXYclient HTTP de confiance qui prend en charge la fonctionnalité proxy
Le client lancera une requête HTTP (ou HTTPS) dans la requête

Les situations suivantes sont des environnements dans lesquels cette faille a été trouvée :

langue	environnement	Client HTTP
PHP	php-fpm mod_php	Engloutir 4+ Artax
Python	wsgiref.handlers.CGIHandler twisted.web.twcgi.CGIScript	demandes
Aller	net/http/cgi	net/http

Il existe certainement de nombreux langages et environnements pour lesquels nous n'avons pas identifié de défauts.

PHP

L'existence de la faille dépend du code de votre application et de votre bibliothèque PHP, mais l'impact semble être très répandu.
Tant qu'une bibliothèque présentant cette faille est utilisée dans le processus de traitement des requêtes des utilisateurs, elle peut être exploitée
Si vous utilisez une bibliothèque avec cette faille, la faille affecte n'importe quelle version de PHP
- Cela peut même affecter d'autres environnements d'exécution PHP, tels que HHVM déployé en mode FastCGI.
Il est confirmé que des bibliothèques telles que Guzzle et Artax sont concernées, et de nombreuses autres bibliothèques pourraient également être affectées.
- Guzzle 4.0.0rc2 et les versions ultérieures sont concernés, Guzzle 3 et les versions inférieures ne sont pas concernés
- D'autres exemples incluent la classe utilitaire StreamContextBuilder de Composer.

Par exemple, si vous utilisez le module Guzzle 6 dans Drupal pour lancer des requêtes sortantes (comme demander une API météo), les requêtes initiées par le module auront cette faille httpoxy.

Python

Le code Python n'est défectueux que lorsqu'il est déployé en mode CGI. De manière générale, le code défectueux utilise wsgiref.handlers.CGIHandlerun contrôleur de type CGI .
- Les applications Web Python déployées normalement ne sont pas affectées (la plupart des gens utilisent WSGI ou FastCGI, ces deux-là ne sont pas affectés), il y a donc beaucoup moins d'applications Python affectées que PHP.
- wsgi n'est pas affecté car os.environ n'est pas contaminé par les données CGI
La bibliothèque de requêtes défectueuses doit être fiable et utilisée os.environ['HTTP_PROXY'], et ne vérifie pas le contenu

Aller

Le code Go doit être déployé sous CGI pour être affecté. Le code généralement concerné utilisera net/http/cgile package
- Comme Python, ce n'est pas la manière habituelle de déployer Go en tant qu'application Web. Il y a donc très peu de cas d'être touché
- En comparaison, le package Go net/http/fcgine définit pas de variables d'environnement réelles, il n'est donc pas affecté
La version défectueuse net/httpdoit être fiable et utilisée dans les requêtes sortantes HTTP_PROXY, sans vérification du contenu

Répare le maintenant

ProxyLa meilleure solution consiste à bloquer les en-têtes de requête avant qu'ils n'attaquent votre application . C'est facile et sûr.

On dit qu'il est sûr car Proxyl'en-tête de la requête n'est pas défini par l'IETF et n'est pas répertorié dans le registre des en-têtes de message de l'IANA . Cela indique que l'utilisation de cet en-tête n'est pas standard et n'est même pas utilisée de manière ad hoc.
Les clients et serveurs HTTP conformes aux normes ne doivent jamais lire ou envoyer cet en-tête
Vous pouvez supprimer cet en-tête de la requête ou bloquer entièrement les requêtes en l'utilisant.
Vous pouvez résoudre ce problème vous-même si l'amont ne publie pas de correctif
- Vérifier les requêtes HTTP au fur et à mesure de leur arrivée peut corriger de nombreuses applications défectueuses à la fois
- Sélection d'applications derrière des proxys inverses et des pare-feu d'application. ProxyLes en-têtes de requête sont sécurisés.

La manière de bloquer Proxyles en-têtes de requête dépend de votre configuration. Le plus simple est de bloquer cet en-tête sur votre pare-feu d'application web, ou directement sur Apache et Nginx. Voici quelques conseils sur la façon de procéder :

Nginx/FastCGI

Utilisez l'instruction suivante pour bloquer les en-têtes de requête transmis à PHP-FPM et PHP-PM. Cette instruction peut être placée dans fastcgi.conf ou fastcgi_param (selon le fichier de configuration que vous utilisez) :

fastcgi_param HTTP_PROXY "";

PHP est défectueux en mode FastCGI (mais la plupart des autres langages utilisant Nginx FastCGI ne sont pas concernés).

Apache

Pour connaître l'étendue précise de l'impact sur Apache, ainsi que sur d'autres projets logiciels Apache, tels que Tomcat, il est recommandé de se référer à l'annonce officielle de l'Apache Software Foundation . Voici quelques messages clés :

Si vous utilisez le serveur HTTP Apache mod_cgipour exécuter des scripts écrits en Go ou Python, alors ils seront affectés (là où HTTP_PROXYles variables d'environnement sont "réelles"). Puisqu’elle mod_phpest utilisée dans les scripts PHP, cette faille existe également.

Si vous utilisez le module mod_headers , vous pouvez supprimer Proxyles en-têtes de requête avant de poursuivre le traitement de la requête avec la configuration suivante :

RequestHeader unset Proxy early

Si vous utilisez le module mod_security , vous pouvez utiliser une SecRulerègle pour refuser Proxyles requêtes avec des en-têtes de requête. Voici un exemple, assurez-vous SecRuleEnginequ'il est activé. Vous pouvez l'ajuster en fonction de votre propre situation.

SecRule &REQUEST_HEADERS:Proxy "@gt 0" "id:1000005,log,deny,msg:'httpoxy denied'"

Enfin, si vous utilisez Apache Traffic Server, celui-ci n'est pas affecté. Cependant, vous pouvez l'utiliser pour supprimer l'en-tête de requête proxy afin de protéger les autres services derrière celui-ci. Veuillez vous référer aux directives de l'ASF pour plus de détails .

HAProxy

Supprimez l'en-tête de requête via la configuration suivante :

http-request del-header Proxy

Vernis

Pour annuler cet en-tête, veuillez le placer dans la section vcl_recv existante :

sub vcl_recv {
    [...]
    unset req.http.proxy;
    [...]
}

OpenBSD relayé

Utilisez l'instruction suivante pour supprimer cet en-tête. Placez-le dans un filtre existant :

http protocol httpfilter {
    match request header remove "Proxy"
}

lighttpd（<= 1.4.40）

Renvoie Proxyles requêtes contenant des en-têtes.

Créez un /path/to/deny-proxy.luafichier et rendez-le en lecture seule pour lighttpd avec le contenu suivant :

if (lighty.request["Proxy"] == nil) then return 0 else return 403 end

Modifiez lighttpd.confpour charger mod_magnetle module et exécutez le code Lua ci-dessus :

server.modules += ( "mod_magnet" )
magnet.attract-raw-url-to = ( "/path/to/deny-proxy.lua" )

lighttpd2 (en cours de développement)

ProxySupprimez les en-têtes des requêtes . Ajoutez-y la déclaration suivantelighttpd.conf :

req_header.remove "Proxy";

Le correctif PHP côté client n'a aucun effet

Il n'existe aucun correctif côté utilisateur pour résoudre la faille, alors ne vous embêtez pas :

L'utilisation unset($_SERVER['HTTP_PROXY'])n'affectera pas getenv()la valeur renvoyée, elle est donc inutile
L'utilisation putenv('HTTP_PROXY=')n'a aucun effet (putenv ne peut affecter que les valeurs des variables d'environnement réelles, pas des en-têtes de requête)

Histoire de httpoxy

La vulnérabilité a été découverte pour la première fois il y a 15 ans.

En mars 2001, Randal L. Schwartz a découvert ce défaut dans libwww-perl et l'a corrigé.

En avril 2001, Cris Bailiff a découvert cette faille dans curl et l'a corrigée.

La faille a été découverte par Akira Tanaka de l'équipe Ruby en juillet 2012 lors de l'implémentation Net::HTTPdeHTTP_PROXY

La faille a été mentionnée sur la liste de diffusion nginx en novembre 2013. Le découvreur Jonathan Matthews n’en était pas si sûr, mais il s’avère qu’il avait raison.

Stefan Fritsch l'a mentionné en février 2015 sur la liste de diffusion Apache httpd-dev.

La faille a été découverte par Scott Geary de l'équipe de sécurité Vend en juillet 2016 et affecte de nombreux langages de programmation et bibliothèques modernes tels que PHP.

Ainsi, cette faille est dormante depuis de nombreuses années, et de nombreuses personnes ont découvert son existence sous différents aspects, mais n’ont pas considéré son impact sur d’autres langages et bibliothèques. Les chercheurs en sécurité ont créé un site Internet spécialement à cet effet : https://httpoxy.org/ où vous pourrez en savoir plus.