Teknik - CAIDO, le proxy offensif, ou la complexité de coder un proxy - Parce que... c'est l'épisode 0x33C! — PolySécure Podcast

Teknik - CAIDO, le proxy offensif, ou la complexité de coder un proxy - Parce que... c'est l'épisode 0x33C!

PolySécure Podcast · 03/09/2026 04:00 · 1 h 06
Informatique

Contenu de l'épisode

Parce que… c’est l’épisode 0x33C! Shameless plug Description

Cette description a été faite à l’aide de GLM 5.3 Flash, à partir de la transcription qui a été effectuée par ElevenLabs Scribev2. Aucune vérification humaine n’a été faite. Si vous découvrez des erreurs ou des inexactitudes, vous pouvez m’en faire part afin que je procède aux modifications appropriées.

Présentation de Caido

Cet épisode technique de Polysécure accueille Émile Fugulin et Christopher Guay, cofondateurs de Caido, un projet développé depuis cinq ans. Tous deux proviennent de l’ingénierie, Christopher dirigeant la technique et Émile venant de la sécurité web. Leur produit se définit comme un proxy offensif, une boîte à outils pour les audits web et d’API, destiné aux chasseurs de primes, aux testeurs d’intrusion et aux équipes red team.

Le fonctionnement du proxy

Le proxy s’insère entre le navigateur et l’API, qui lui envoie toutes ses requêtes. La première étape consiste à faire accepter au navigateur un certificat généré par l’outil afin de terminer la connexion HTTPS localement. Le navigateur envoie ensuite une requête Connect pour établir un tunnel vers le serveur distant. Un proxy ordinaire laisse passer des octets chiffrés sans les lire, mais Caido se substitue au serveur distant et termine lui-même le tunnel pour pouvoir lire et modifier le trafic.

TLS et détection de robots

L’interception ne pose pas de difficulté puisque le certificat est installé sur la machine de l’utilisateur, peu importe la version de TLS. Le défi se situe du côté sortant, où la détection de robots analyse la structure du paquet TLS, des extensions comme Grease signalant un vrai navigateur, leur absence trahissant un automate. Les CDN comme Cloudflare ou Akamai croisent les empreintes TLS avec les en-têtes HTTP et bloquent facilement selon la réputation des adresses IP. Des plugins répartissent le trafic sur plusieurs IP, mais Amazon a restreint l’usage de son API Gateway après des abus, et les proxys résidentiels demeurent une zone grise sans support officiel.

Une stack HTTP maison

Le modèle de base demeure la paire requête-réponse, majoritairement en HTTP/1.1, avec un support récent de HTTP/2. La spécification HTTP/1, ancienne et vague, ne sépare en-têtes et corps que par des caractères de contrôle. Cette ambiguïté a donné naissance aux attaques de désynchronisation, où un proxy et un backend interprètent différemment les frontières des requêtes, notamment entre le content-length et le transfer-encoding, permettant d’injecter des requêtes dans une connexion réutilisée pour plusieurs clients. Les stacks standard, rigoureuses surtout en Rust, ne conviennent pas pour injecter des données non conformes, d’où la réécriture complète de la stack maison. Gérer les réponses non conformes exige aussi de la souplesse, un serveur pouvant annoncer dix octets et en envoyer quinze, ces derniers contenant parfois des informations précieuses.

Les attaques synchronisées

L’attaque last byte sync en HTTP/1 consiste à charger plusieurs requêtes dans des buffers, à ouvrir plusieurs connexions TCP, puis à envoyer le dernier octet de chacune simultanément. Si le verrou applicatif est mal implémenté, un code de rabais peut s’appliquer plusieurs fois. En HTTP/2, le single packet attack exploite le multiplexage des f

Plus d'informations