Retour au blog

Qu’est-ce qu’un web proxy ? Comprendre les proxies de navigateur dans les logs

proxysécurité weblogsIP intelligencefraude

Un décryptage technique pour les ingénieurs : fonctionnement des web proxies, cas des proxies intégrés au navigateur et signaux à repérer dans les journaux système.

Les web proxies utilisés depuis le navigateur restent un angle mort tenace en sécurité réseau. On associe souvent les proxies à de grandes infrastructures dédiées, mais une part non négligeable du trafic proxy provient en réalité d’extensions de navigateur, de services web grand public ou de configurations locales. Pour les équipes chargées de la détection de fraude, de la prévention des abus ou du threat intelligence, savoir comment ces usages apparaissent dans les logs est indispensable.

Cet article se concentre sur l’identification concrète des proxies de navigateur à partir des données de journalisation, avec une attention particulière portée aux signaux exploitables et à leurs limites.

What is a Web Proxy?

Un web proxy joue le rôle d’intermédiaire entre un client et les serveurs auxquels celui-ci souhaite accéder. Plutôt que de se connecter directement à un site cible, le client envoie sa requête au serveur proxy, qui la relaie ensuite vers le site pour son compte. La réponse du site repasse par le proxy avant d’être renvoyée au client.

Ce mécanisme peut répondre à plusieurs objectifs :

  • Anonymat/confidentialité : masquer l’adresse IP d’origine du client.
  • Contrôle d’accès : contourner des restrictions géographiques ou des pare-feu d’entreprise.
  • Mise en cache : améliorer les performances en servant des contenus déjà stockés.
  • Journalisation/supervision : intercepter et enregistrer le trafic à des fins d’analyse.
  • Sécurité : filtrer les contenus malveillants ou appliquer des politiques internes.

Browser-Based vs. Dedicated Proxies

La fonction de base reste la même, mais les proxies de navigateur se distinguent des infrastructures proxy dédiées par leur mode de déploiement et leur empreinte opérationnelle. Les proxies dédiés reposent souvent sur des logiciels spécifiques installés sur des serveurs identifiés, administrés par une personne ou une organisation pour un usage relativement stable : proxy sortant d’entreprise, service VPN, plateforme de scraping, etc. Ils s’appuient généralement sur des protocoles connus comme SOCKS ou HTTP/HTTPS et proviennent fréquemment de grands hébergeurs.

Les proxies de navigateur, eux, prennent le plus souvent l’une des formes suivantes :

  • Extensions/add-ons : petits composants installés directement dans Chrome, Firefox, Edge ou d’autres navigateurs. Ils modifient les requêtes côté client afin de les faire transiter par un serveur proxy opéré par l’éditeur de l’extension.
  • Services web : sites proposant une fonction proxy directement dans le navigateur, par exemple en saisissant une URL dans une page prévue pour naviguer anonymement. Dans ce cas, le serveur proxy est généralement le serveur web qui héberge le service.
  • Logiciels proxy locaux : applications installées sur la machine de l’utilisateur qui redirigent le trafic du navigateur vers un proxy local, puis vers un proxy amont. On en trouve dans certains bloqueurs de publicité, outils de confidentialité ou solutions de test spécialisées.

Pour la détection, la différence essentielle tient au fait que les proxies de navigateur s’appuient souvent sur des infrastructures variées, parfois éphémères, avec des schémas d’usage moins réguliers que ceux des services dédiés.

Surfacing Browser Proxies in Logs

Repérer l’usage d’un proxy de navigateur suppose d’analyser plusieurs champs dans les logs de vos serveurs web, de votre CDN et de vos applications. Aucun champ ne suffit à lui seul. C’est la corrélation de plusieurs signaux faibles qui permet de conclure à une activité proxy probable.

1. IP Address Anomalies

Le signal le plus direct reste l’adresse IP de connexion. Si une requête provient d’une IP déjà associée à des services proxy, l’indice est fort. Dans le cas des proxies de navigateur, cela se traduit souvent par :

  • IP d’hébergeur ou de datacenter : de nombreux services proxy gratuits ou peu coûteux fonctionnent depuis des hébergeurs généralistes. Une IP appartenant à un grand fournisseur cloud (AWS, GCP, Azure, DigitalOcean, OVH, etc.) ou à un datacenter moins connu devient suspecte si elle ne correspond pas aux usages attendus de vos utilisateurs. Par exemple, une IP issue d’une plage d’hébergement qui se connecte à un site retail depuis une région où vous n’avez aucune activité commerciale mérite attention.
  • Nœud de sortie TOR : l’adresse IP figure dans la liste des nœuds de sortie Tor connus. Des outils accessibles depuis le navigateur peuvent facilement faire transiter le trafic par Tor.
  • IP VPN : même si le VPN est souvent traité comme une catégorie distincte, de nombreuses extensions de navigateur proposent des fonctions proches d’un VPN, en faisant passer le trafic par des fournisseurs VPN commerciaux.
  • Listes noires de proxies : l’IP apparaît dans des listes commerciales ou open source dédiées à l’identification des proxies.

Limites : un utilisateur légitime peut utiliser un VPN pour protéger sa vie privée, et certains FAI routent une partie de leur trafic via des infrastructures qui ressemblent à des datacenters. Le contexte reste déterminant.

2. HTTP Headers

Les en-têtes HTTP sont une source d’information précieuse. Certains peuvent être modifiés, mais d’autres restent souvent en place ou trahissent la présence d’un proxy.

  • `X-Forwarded-For` / `X-Real-IP` : ces en-têtes sont généralement ajoutés par les proxies pour conserver l’adresse IP d’origine du client. Si votre application s’attend à recevoir directement l’IP du client, mais observe une IP proxy dans REMOTE_ADDR et une autre IP, potentiellement résidentielle, dans X-Forwarded-For, l’usage d’un proxy devient très probable. Attention toutefois : un attaquant expérimenté peut falsifier ces en-têtes.

Exemple :* REMOTE_ADDR = 192.0.2.1 (IP du proxy), X-Forwarded-For = 203.0.113.10 (IP d’origine possible du client).

  • En-tête `Via` : certains proxies, notamment anciens ou transparents, ajoutent un en-tête Via indiquant le protocole et le nom d’hôte ou l’IP des serveurs proxy traversés. Il est moins fréquent avec les proxies de navigateur modernes, mais il apparaît encore.

Exemple :* Via: 1.1 proxy.example.com

  • `Proxy-Connection` / `Proxy-Authorization` : la présence de ces en-têtes indique que le client a explicitement configuré son navigateur pour utiliser un proxy. Proxy-Authorization suggère plus précisément un proxy authentifié, courant en environnement d’entreprise, mais aussi utilisé par certains services proxy payants.
  • Incohérences dans le `User-Agent` : certaines extensions de navigateur peuvent modifier légèrement la chaîne User-Agent, ou celle-ci peut ne pas correspondre aux autres signaux observés. Exemple typique : un User-Agent mobile provenant d’une IP de datacenter, associé à des résolutions d’écran plutôt desktop.

Limites : les en-têtes peuvent être modifiés ou supprimés. X-Forwarded-For peut contenir plusieurs IP ou être entièrement fabriqué.

3. Connection Characteristics

Au-delà de l’IP et des en-têtes, la manière dont la connexion est établie et se comporte peut fournir d’autres indices.

  • Empreinte TLS/SSL (JA3/JA4) : la négociation TLS contient des motifs spécifiques liés au navigateur, au système d’exploitation et à la pile réseau du client. Un navigateur passant par un proxy peut présenter une empreinte TLS différente de celle attendue pour une connexion directe, par exemple une empreinte typique d’un composant serveur ou d’une bibliothèque générique.
  • Prise en charge HTTP/2 ou HTTP/3 : certains proxies rétrogradent ou modifient la version HTTP utilisée, ce qui peut créer un écart entre les capacités annoncées du client et le protocole réellement observé côté serveur.
  • Round Trip Time (RTT) / latence : sans être une preuve en soi, une latence anormalement élevée ou irrégulière pour une région donnée peut indiquer une chaîne proxy à plusieurs sauts.

Limites : le fingerprinting TLS est une technique avancée et peut être contourné. Le RTT varie fortement selon les conditions réseau.

Leveraging IP Intelligence

Corréler manuellement ces signaux sur des millions de lignes de logs n’est pas réaliste. C’est précisément là que les API spécialisées d’IP intelligence deviennent indispensables. Des services comme Guarda automatisent l’analyse de ces signaux, ainsi que de nombreux autres, afin de produire une évaluation consolidée du risque.

Un service d’IP intelligence fournit généralement :

  • Détection proxy/VPN/TOR : classification directe d’une IP comme proxy connu, VPN ou nœud de sortie TOR, à partir d’une surveillance continue et de listes spécialisées.
  • Données ASN/organisation : identification de l’Autonomous System Number et de l’organisation propriétaire. Les IP appartenant à des hébergeurs, par exemple avec des noms d’ASN contenant "HOSTING", "CLOUD" ou "DATACENTER", sont souvent considérées comme suspectes lorsqu’elles sont utilisées par des utilisateurs finaux.
  • Nom d’hôte rDNS : les enregistrements DNS inverses peuvent parfois révéler une infrastructure proxy, par exemple proxy.someprovider.net. Même s’ils sont faciles à manipuler, ils constituent un signal supplémentaire.
  • Score de risque : score numérique consolidé représentant la probabilité qu’une IP soit malveillante ou associée à des abus. Ce score intègre notamment les schémas d’attaque observés, la présence dans des listes noires et le type d’infrastructure.

En intégrant ce type d’API, vous pouvez enrichir vos logs avec du renseignement en temps réel. Lorsqu’une connexion entrante présente un REMOTE_ADDR identifié comme une IP de datacenter avec un score de risque élevé, tandis que X-Forwarded-For indique une autre IP, possiblement résidentielle, vous disposez d’un faisceau d’indices solide en faveur d’un usage proxy. Vous pouvez alors déclencher une authentification renforcée, bloquer la requête ou simplement journaliser l’événement pour analyse ultérieure.

Conclusion

Identifier des proxies de navigateur dans les logs demande une approche à plusieurs niveaux : vigilance opérationnelle, bonne compréhension des mécanismes HTTP et recours à des sources externes d’intelligence. Aucun signal n’est infaillible, mais une stratégie robuste agrège plusieurs indicateurs, de l’origine de l’IP aux en-têtes HTTP, en passant par les caractéristiques de connexion. Pour les ingénieurs qui exploitent des applications web, reconnaître ces schémas est essentiel afin de préserver la sécurité, la fiabilité et l’intégrité des données.

Pour vérifier votre propre IP ou tester certains de ces concepts, vous pouvez utiliser l’outil gratuit de recherche IP disponible sur guarda.net.

Votre connexion