# HTTPoxy : la vulnérabilité qui menace les applications CGI

Pour des raisons de performance et de sécurité, de nombreux projets Web s’appuient sur des **serveurs proxy**. Ces programmes pratiques servent en effet d’interface de communication entre le client et le site Web et soulagent donc le serveur Web puisqu’ils reçoivent, éditent, traitent et répondent aux requêtes HTTP. Cependant, en raison d’une **faille de sécurité** connue sous le nom de HTTPoxy, cette technologie peut être utilisée par les hackers afin de pirater et de voler des données. Les applications qui sont basées sur le **standard CGI** ([Common Gateway Interface](https://www.ionos.fr/digitalguide/sites-internet/developpement-web/quest-ce-que-la-cgi/ "Qu’est-ce que la CGI")) et configurées sur les variables d’environnement sont notamment affectées. Certains programmes peuvent lire par exemple les configurations de votre proxy à partir des variables, ce qui devient rapidement un problème lorsque les pirates manipulent ces paramètres.

## Qu’est-ce que HTTPoxy ?

Quand un serveur Web veut communiquer avec le client via une Common Gateway Interface (CGI), la norme **RFC 3875** prévoit que les en-têtes de toutes requêtes HTTP envoyées soient stockées comme variables d’environnement. Le nom de cette variable est composé du préfixe « HTTP\_ » et du nom de l’en-tête en majuscules. Le cas décrit ici est l’en-tête « Proxy », qui génère automatiquement la variable HTTP\_PROXY. C’est prévu par défaut comme **configuration des paramètres du proxy**. En d’autres termes, si l’application CGI atteint ou exécute une requête qui comporte HTTP\_PROXY, elle est redirigée via le serveur proxy approprié. Les circonstances décrites permettent à un hacker de mettre son propre serveur proxy en jeu, de l’utiliser et d’obtenir ainsi des **informations sensibles**. Pour cela, il envoie une requête HTTP avec l’en-tête Proxy et une valeur correspondante (par exemple l’adresse IP du proxy), après quoi les requêtes utilisateurs futures, entrantes ou sortantes, seront redirigées vers lui. Selon le scénario choisi, l’attaquant peut alors renvoyer librement ses propres données ou **lire** directement les données d’entrée de l’utilisateur.

## Une faille de sécurité inévitable ?

Cette vulnérabilité, dont le nom n’a pas de signification particulière, est remarquée pour la première fois en mars 2001. Le programmeur Randal L. Schwartz avait découvert HTTPoxy dans la bibliothèque de Perl **libwww-perl** et l’a transmis à Gisle Aas qui est le développeur de celle-ci. Le comblement de cette faille est intervenu avec la mise à jour 5.51 en modifiant le nom de la variable par laquelle la configuration du proxy peut être contrôlée dans CGI\_HTTP\_PROXY. La même année la vulnérabilité a également été détectée dans le programme de transfert de données curl. C’est pourquoi le développeur Daniel Stenberg a adapté en conséquence le logiciel, de sorte que désormais seule **la variante minuscule http-proxy** puisse déterminer le serveur proxy, tout en avertissant que cela était fondamentalement insuffisant pour les systèmes Microsoft. Mais dans les versions actuelles de Windows, le problème n’existe plus désormais. Environ une décennie plus tard : en juillet 2012, l’équipe Ruby a buté sur le problème HTTPoxy qui était alors depuis longtemps oublié, en implémentant la classe NET::HTTP, **un client HTTP API pour les applications Ruby**. Pour contourner le problème, HTTT\_PROXY et d’autres ont été configurés sous le statut d’une norme variable. Dans les années suivantes, les applications de serveur Web NGINX (2013) et Apache (2015) sont les cas les plus importants dans lesquels des utilisateurs attentifs ont alors informés les développeurs d’un danger potentiel. En 2016, l’équipe de sécurité de la société de développement Vend a finalement constaté que la vulnérabilité HTTPoxy était, 15 ans après sa première découverte, toujours une faille. PHP et d’autres langages de programmation et les bibliothèques, peuvent être exploités à condition d’être combinés **avec CGI ou un environnement d’exécution comparable à des variables**. De nombreuses applications affectées qui permettent l’utilisation de HTTPoxy ont été répertoriées dans le dictionnaire des informations publiques relatives aux vulnérabilités de sécurité, les CVE (*Common Vulnerabilites and Exposures*) :

- CVE-2016-5385: PHP
- CVE-2016-5386: Go CVE-2016-5387: Apache HTTP Server
- CVE-2016-5388: Apache Tomcat
- CVE-2016-6286: spiffy-cgi-handlers for CHICKEN
- CVE-2016-6287: CHICKEN’s http-client
- CVE-2016-1000104: mod\_fcgi
- CVE-2016-1000105: Nginx cgi script
- CVE-2016-1000107: Erlang inets
- CVE-2016-1000108: YAWS
- CVE-2016-1000109: HHVM FastCGI
- CVE-2016-1000110: Python CGIHandler
- CVE-2016-1000111: Python Twisted
- CVE-2016-1000212: lighttpd

## Comment se protéger ainsi que votre serveur de HTTPoxy ?

Peu importe si vous exécutez votre propre serveur Web ou non. HTTPoxy représente un risque lorsque vous êtes sur le World Wide Web. Si le service Web appelé peut être détourné de manière indésirable par **des requêtes HTTP externes**, vos données ne sont donc pas protégées. Pour minimiser le risque de détournement de données, vous devez donc préférer les sites qui sont **protégés par un certificat TLS/SSL** et transférer toutes les informations de manière cryptée. De cette façon, il est encore possible de détourner les données en utilisant un proxy incorrect, mais les hackers peuvent bien moins utiliser ces dernières, voire même ne rien en tirer. En tant qu’opérateur de site Web, la [conversion en HTTP](https://www.ionos.fr/digitalguide/sites-internet/creation-de-sites-internet/comment-passer-un-site-web-en-ssl-et-https/) est de toute façon obligatoire aujourd’hui. Cependant, vous avez toujours la possibilité d’éviter HTTPoxy en supprimant en général simplement la faille de sécurité. Comme **l’en-tête proxy** n’est pas tenu à une norme IETF (*Internet Engineering Task Force*) ou enregistré via l’IANA (*Internet Assigned Numbers Authority*) comme en-tête officiel, vous pouvez l’intercepter sans hésiter avant qu’il n’atteigne votre application Web. **Les serveurs et clients HTTP standards** n’émettent de toute façon pas de paquets de données avec cet en-tête. Fondamentalement, vous avez deux options en plus du cryptage de l’échange de données HTTP pour empêcher les requêtes dangereuses d’atteindre votre projet Web :

1. Filtrer l’en-tête proxy sur tous les paquets entrants.
2. Bloquer automatiquement tous les paquets entrants qui contiennent un en-tête proxy

La première option est beaucoup plus fréquente et peut se faire à l’aide de n’importe quel **serveur Web ordinaire, proxy ou logiciel de répartition de charges** (*Load Balancing*). Les sections suivantes fournissent des informations sur la façon **de supprimer l’en-tête potentiellement dangereux du trafic de données sur diverses distributions Linux** à l’aide des applications serveur Web Apache Nging et du logiciel serveur proxy HAProxy.

### Contourner HTTPoxy avec Apache

Le logiciel libre Apache est depuis longtemps installé par défaut sur toutes les distributions majeures de Linux et reste encore aujourd’hui le premier choix quand il s’agit d’exécuter son propre serveur Web. Un composant du programme est le module **mod\_headers**, qui vous permet de filtrer l’en-tête proxy de toutes les requêtes HTTP entrantes. La procédure diffère légèrement de chaque distribution.

**Ubuntu et** [Debian](https://www.ionos.fr/digitalguide/serveur/know-how/debian-le-logiciel-systeme-universel/ "Debian, le logiciel système universel") :

La première étape consiste à activer le module, ce que vous pouvez faire via la commande suivante :

```none
sudo a2enmod headers
```

Ouvrez ensuite le fichier de configuration principal d’Apache avec un éditeur. L’outil en ligne de commande **nano** qui est utilisé dans l’exemple est recommandé :

```none
sudo nano /etc/apache2/apache2.conf
```

Développez maintenant le fichier avec l’entrée suivante :

```none
<IfModule mod_headers.c>
    RequestHeader unset Proxy early
</IfModule>
```

Après avoir enregistré le fichier, vous pouvez activer la protection HTTPoxy en chargeant le fichier de configuration spécifique avec le scripte **a2enconf,** puis redémarrer le serveur :

```none
sudo a2enconf httpoxy
sudo service apache2 restart
```

**CentOS et Fedora :** Si vous utilisez une version de la distribution Linux CentOS ou Fedora, le module mod\_headers est **déjà activé par défaut**, vous pouvez donc sauter cette étape et il suffit d’ouvrir le fichier de configuration :

```none
sudo nano /etc/httpd/conf/httpd.conf
```

Insérez à la fin la nouvelle entrée :

```none
RequestHeader unset Proxy early
```

Sauvegardez ensuite les changements et [redémarrez le serveur Apache](https://www.ionos.fr/digitalguide/serveur/configuration/redemarrage-dapache/) :

```none
sudo service httpd restart
```

### Modifier l’en-tête HTTP Proxy avec NGINX

NGINX est une application de serveur Web qui jouit d’une popularité grandissante. Le logiciel open-source ne nécessite que quelques étapes pour protéger les applications CGI qui s’exécutent **sur le serveur** ou bien **entre le client et le serveur** à partir de la faille de sécurité HTTPoxy. **Ubuntu et Debian** : En règle générale, les paramètres FastCGI (FastCGi est une optimisation de la norme CGI) sont inclus dans Ubuntu et Debian dans les fichiers *fastcgi\_params* ou *fastcgi.conf*, lorsque vous configurez un **Proxy NGINX FastCGI**. Dans les deux fichiers, vous pouvez couper l’en-tête proxy dans les requêtes HTTP. Pour cela il suffit d’utiliser les lignes de commande suivantes :

```none
echo 'fastcgi_param HTTP_PROXY "";' | sudo tee -a /etc/nginx/fastcgi.conf
echo 'fastcgi_param HTTP_PROXY "";' | sudo tee -a /etc/nginx/fastcgi_params
```

Si vous utilisez NGINX comme un **proxy HTTP conventionnel**, vous pouvez également filtrer l’en-tête. Pour ce faire, insérez la règle correspondante dans le fichier *proxy\_params* qui répertorie les paramètres du serveur proxy :

```none
echo 'proxy_set_header Proxy "";' | sudo tee -a /etc/nginx/proxy_params
```

Dans la dernière étape, redémarrer NGINC avec cette commande :

```none
sudo service nginx restart
```

**CentOS et Fedora**: La procédure pour **éviter les dangers de HTTPoxy** pour les proxys FastCGI sur CentOS ou Fedorane ne diffère pas beaucoup des procédures pour les systèmes Ubutun et Debian. Puisque les configurations NGINX sur ces distributions sont définies dans les fichiers *fastcgi\_params* ou dans le fichier *fastcgi.conf*. Vous pouvez aussi désactiver l’en-tête du proxy ici avec les commandes déjà répertoriées :

```none
echo 'fastcgi_param HTTP_PROXY "";' | sudo tee -a /etc/nginx/fastcgi.conf
echo 'fastcgi_param HTTP_PROXY "";' | sudo tee -a /etc/nginx/fastcgi_params
```

Pour protéger les proxys conventionnels sous Fedora et CentOS, assurez-vous que l’en-tête est bloqué de partout où NGINX exécute la **directive proxy\_pass**. Pour savoir où elles sont utilisées, vous pouvez compter sur les services de la commande de recherche *grep* :

```none
sudo grep -r "proxy_pass" /etc/nginx
```

Cela contient une liste des fichiers texte dans laquelle **la directive** est répertoriée, ou les sorties ressemblent à l’exemple suivant :

```none
/etc/nginx/nginx.conf.default:        #    proxy_pass http://127.0.0.1;
```

Dans ce cas, proxy\_pass pourrait être ainsi dans le fichier de configuration NGINX. L’entrée correspondante dans *nginx.conf* doit être ajoutée comme ci-dessous :

```none
proxy_pass http://127.0.0.1;
proxy_set_header Proxy "";
```

Dans les deux cas, pour terminer le processus, vous devez redémarrer le serveur :

```none
sudo service nginx restart
```

### Protéger votre serveur HAProxy contre HTTPoxy

Lorsque vous redirigez les requêtes HTTP à votre projet Web via un serveur HAProxy, vous pouvez supprimer l’en-tête proxy, **avant même que le proxy n’envoie les demandes**. Pour les différentes distributions Linux mentionnées, la procédure ne diffère pas. Tout d’abord, il est nécessaire d’ouvrir le fichier de configuration principal de l’application proxy, ce que vous pouvez réaliser avec la commande suivante :

```none
sudo nano /etc/haproxy/haproxy.cfg
```

De cette façon, vous ouvrez le fichier *haproxy.cfg* avec l’éditeur de ligne de commande nano, utilisé précédemment. Si vous avez spécifié un autre **répertoire** pour HAProxy pendant l’installation, vous devrez ajuster la commande en conséquence. Dans le fichier ouvert, vous pouvez maintenant insérer une directive requête HTTP pour enlever les en-têtes non désirés dans les trois sections « frontend », « backend », et « listen ». Le résultat ressemble à ceci :

```none
frontend name
    http-request del-header Proxy
…
backend name
    http-request del-header Proxy
…
listen name
    http-request del-header Proxy
```

Enregistrez les modifications et redémarrez le service HAProxy :

```none
sudo service haproxy restart
```

### Contrôle de sécurité avec HTTPoxy Vulnerability Checking Tool

Après avoir effectué la configuration de votre proxy à l’aide des options de protections énumérées contre HTTPoxy, vous devriez vérifier si elles sont correctement utilisées. Pour cela, il existe des applications comme [HTTPOXY Vulnerability Checking Tool](https://httpoxy.rehmann.co "vérifier votre projet Web contre la faille HTTPoxy avec Vulnerability Checking Tool") de Luke Rehmann. Ce service Web gratuit vérifie les URL et recherche les vulnérabilités HTTPoxy en envoyant une requête HTTP avec les en-têtes proxy à l’URL qui redirige vers un autre serveur. Si l’outil ne reçoit pas de réponse du serveur, l’en-tête a été bloqué avec succès.

[![Image: l’outil Web HTTPOXY Vulnerability Checking Tool](https://www.ionos.fr/digitalguide/fileadmin/_processed_/3/5/csm_httpoxy-vulnerability-checking-tool_b065944e1e.webp "l’outil Web HTTPOXY Vulnerability Checking Tool")](https://www.ionos.fr/digitalguide/fileadmin/DigitalGuide/Screenshots/httpoxy-vulnerability-checking-tool.jpg) l’outil Web HTTPOXY Vulnerability Checking Tool Pour utiliser le service, il suffit d’insérer l’URL de l’application Web à tester dans le champ de saisie, et de cliquer sur « Test ».


This is a markdown version of: [https://www.ionos.fr/digitalguide/serveur/configuration/httpoxy-quest-ce-que-la-vulnerabilite-cgi/](https://www.ionos.fr/digitalguide/serveur/configuration/httpoxy-quest-ce-que-la-vulnerabilite-cgi/) for AI/LLM consumption.