Considérez chaque proxy gratuit comme une infrastructure non fiable, car c'est le cas. L'opérateur est anonyme, le modèle de financement est flou, et la même socket peut passer par un botnet, un routeur domestique compromis et un pot de miel de chercheur en une seule semaine. Rien de tout cela ne rend les proxies gratuits inutilisables — cela rend un petit ensemble d'habitudes non négociables.
Les attaques courantes
Les menaces ne sont pas spectaculaires. Ce sont celles, ennuyeuses, qui réussissent parce que la plupart des utilisateurs ne prennent pas la peine de s'en défendre.
Vol d'identifiants sur HTTP en clair. Si vous vous connectez à quoi que ce soit via http:// à travers un proxy inconnu, l'opérateur voit le mot de passe. Toujours tunneliser TLS via CONNECT ou utiliser SOCKS vers une destination qui impose elle-même HTTPS. Les flux de connexion modernes sont exclusivement en HTTPS sur les grands sites, mais les intranets hérités, les pages d'administration IoT et les anciens CMS ne le sont pas.
Injection d'en-têtes et de contenu. Un proxy HTTP hostile peut réécrire des parties arbitraires de votre requête : modifier les cookies, échanger les référents, injecter des paramètres de suivi ou supprimer les en-têtes de cache. Le même proxy peut injecter du contenu dans les réponses — des scripts dans le HTML, des redirections dans le JSON, des publicités dans les pages statiques. Si vous lisez les réponses du serveur via le proxy, considérez-les comme compromises jusqu'à ce que vous puissiez vérifier leur intégrité depuis un chemin de confiance.
Détournement DNS via SOCKS5. SOCKS5 peut résoudre les noms d'hôte au niveau du proxy. Si le proxy ment sur un enregistrement DNS, vous vous connectez à un serveur contrôlé par l'opérateur. Configurez votre client pour résoudre localement lorsque c'est possible : curl --resolve example.com:443:93.184.216.34, ou dans le code, passez une adresse IP plutôt qu'un nom d'hôte.
Journalisation du trafic. Même un proxy bien intentionné peut enregistrer chaque URL que vous récupérez. Pour les modèles de menace qui incluent « quelles URL cette personne a-t-elle demandées », tout proxy public est le mauvais outil. Utilisez Tor ou un VPN payant avec une politique de non-journalisation publiée et un historique de contestation de citations à comparaître.
Épuisement des ressources côté client. Certains proxies limitent délibérément les connexions à un ralentissement, renvoient des réponses très volumineuses ou maintiennent les sockets ouvertes sans envoyer de données. Définissez des limites strictes de taille de réponse et des délais d'attente de connexion côté client.
Défenses, par ordre de priorité
Envoyez tout à l'intérieur de TLS via CONNECT ou vers une destination HTTPS via SOCKS. Ne réutilisez jamais d'identifiants derrière un proxy public que vous réutiliseriez ailleurs. Validez strictement les certificats — épingler l'émetteur est excessif pour une utilisation occasionnelle, mais accepter n'importe quelle chaîne est imprudent. Définissez des délais d'attente courts sur la connexion et la lecture. Enregistrez les réponses du proxy pour une analyse médico-légale lorsque la charge de travail est importante. Alternez fréquemment ; un proxy qui fonctionnait il y a cinq minutes n'est pas nécessairement le même proxy maintenant.
À quoi servent réellement les proxies gratuits
Trois catégories de travaux justifient le bruit. Tester les variations de contenu géographique : votre CDN sert-il la bonne page depuis Francfort par rapport à São Paulo ? Récupérer des données publiques non authentifiées : résultats de moteurs de recherche, API publiques sans limite de taux par IP, contenu déjà indexé ailleurs. Vérifier que votre application se comporte correctement lorsque son IP sortante est inconnue de la cible — utile pour le QA sur les systèmes avec des heuristiques de fraude basées sur l'IP.
Utilisez-les pour cela. Acceptez le taux d'échec. Ne mettez rien que vous ne voudriez pas perdre derrière un proxy.