Ne faites pas d’une application de bureau un scanner d’intranet : la protection SSRF pour les agents IA

L’essentiel

• Si un assistant IA peut demander à une application de bureau de récupérer un lien, une instruction piégée peut la diriger vers votre routeur, un service local ou une adresse de métadonnées cloud au lieu d’une vidéo.
• Une même adresse peut s’écrire de bien des façons : 127.1, 2130706433, 0x7f000001 et [::ffff:127.0.0.1] mènent tous à cet ordinateur. KwaFlux analyse les noms d’hôte comme le font les navigateurs, si bien que chaque écriture est vérifiée pour l’adresse qu’elle désigne réellement.
• Au moment où un téléchargement va démarrer, KwaFlux résout aussi le nom d’hôte et le refuse s’il pointe vers cet ordinateur ou vers un réseau privé, sans bloquer la plage d’adresses qu’utilisent les outils proxy en mode fake-IP.
• Les redirections pendant un téléchargement et le DNS rebinding ne sont pas encore couverts. Nous le disons clairement, et ces points figurent sur notre feuille de route.

Quand un assistant IA demande à KwaFlux de télécharger un lien, c’est le moteur de téléchargement de KwaFlux qui se connecte. Ce moteur tourne sur votre ordinateur, à l’intérieur de votre réseau. Si le lien pointe vers http://192.168.1.1/ au lieu d’une page vidéo, une application peu soigneuse se connecterait sans broncher à votre routeur pour le compte de l’assistant.

KwaFlux empêche les liens soumis par un assistant d’atteindre cet ordinateur et les réseaux privés. Voici comment, et où s’arrête cette protection.

Dans ce guide, vous verrez ce que signifie la SSRF pour une application de bureau, pourquoi les listes de blocage échouent face aux écritures alternatives d’une adresse, comment KwaFlux vérifie à la fois l’hôte tel qu’il est écrit et l’adresse obtenue par résolution, et quels cas restent ouverts.

Sommaire

1. Qu’est-ce que la SSRF ?
2. Pourquoi une application de bureau pilotée par l’IA est exposée
3. Une adresse, de multiples écritures
4. Couche 1 : analyser l’hôte comme un navigateur
5. Couche 2 : vérifier vers quoi le nom se résout
6. L’exception du fake-IP
7. Où s’arrête la protection
8. Questions fréquentes

Qu’est-ce que la SSRF ?

La falsification de requête côté serveur (SSRF, pour server-side request forgery) est une attaque dans laquelle quelqu’un amène un programme à envoyer une requête vers une destination choisie par l’attaquant, en général une destination que celui-ci ne peut pas atteindre directement, comme un service sur la même machine ou un réseau interne.

Le nom vient des serveurs web, mais le schéma s’applique à tout programme qui récupère des URL pour le compte de quelqu’un d’autre. Les recommandations de sécurité de MCP listent les cibles habituelles : des IP internes comme http://192.168.1.1/admin, des points de terminaison de métadonnées cloud à http://169.254.169.254/, et des services localhost comme http://localhost:6379/.

Pourquoi une application de bureau pilotée par l’IA est exposée

Trois éléments se combinent :

1. L’application récupère des URL. La fonction Téléchargement de fichier de KwaFlux se connecte au lien qu’on lui donne, quel qu’il soit.
2. L’application se trouve dans votre réseau. Depuis votre ordinateur, 192.168.x.x désigne votre routeur, votre NAS ou votre imprimante, et 127.0.0.1 chacun des services que vous faites tourner en local.
3. Le lien peut venir d’un texte lu par le modèle. Une description de vidéo ou une page web peut dire à l’assistant de « vérifier d’abord ce lien ». Pour voir comment cela se produit, lisez l’injection de prompt dans les titres de vidéos en ligne.

Un moteur de téléchargement qui récupère une adresse interne ne montre pas forcément la réponse à qui que ce soit, mais même un message d’erreur peut indiquer à un attaquant si un appareil existe à cette adresse. C’est ce que nous entendons par faire d’une application de bureau un scanner d’intranet.

Une adresse, de multiples écritures

Bloquer 127.0.0.1 et localhost par simple comparaison de chaînes ne suffit pas. Les analyseurs d’URL acceptent bien d’autres façons d’écrire la même adresse. Voici ce que l’analyseur d’URL WHATWG de Node.js 20 fait de quelques-unes :

Toutes les lignes sauf les deux dernières mènent à cet ordinateur. 10.0.0.1 est une adresse privée, et 169.254.169.254 est l’adresse link-local qu’utilisent les plateformes cloud pour les métadonnées d’instance.

Le standard URL du WHATWG explique pourquoi : une partie qui commence par 0x est lue en base 16, une partie qui commence par 0 en base 8, et dans une adresse de moins de quatre parties, la dernière remplit les octets restants. Le guide de prévention des SSRF de l’OWASP met en garde contre ces mêmes encodages « Hex, Octal, Dword », et les recommandations de sécurité de MCP ajoutent : « Évitez d’implémenter vous-même la validation des adresses IP. Les attaquants exploitent des astuces d’encodage (octal, hexadécimal, IPv6 mappée IPv4) que les analyseurs maison laissent souvent passer. »

Couche 1 : analyser l’hôte comme un navigateur

KwaFlux ne compare pas des chaînes. Il analyse l’hôte avec les mêmes règles que les navigateurs et vérifie le résultat :

• L’analyse d’hôte WHATWG convertit les formes courtes, les parties octales et hexadécimales, les adresses écrites en un seul nombre et le point final en l’adresse réelle, avant toute vérification.
• Les adresses IPv6 sont vérifiées sur leurs 16 octets, si bien qu’une forme IPv6 mappée IPv4 comme [::ffff:7f00:1] est reconnue comme loopback, et non traitée comme une adresse IPv6 inconnue.
• **Les hôtes contenant % sont refusés.** Cela écarte les identifiants de zone IPv6 et les astuces d’encodage-pourcent dans l’hôte.
• Les adresses loopback, privées et link-local sont refusées, comme 127.0.0.0/8, ::1, 10.0.0.0/8, 192.168.0.0/16 et 169.254.0.0/16.

C’est l’application d’un conseil de l’OWASP : « utiliser la valeur de sortie de la méthode ou de la bibliothèque comme adresse IP » lors de la vérification, plutôt que le texte saisi par l’utilisateur.

Couche 2 : vérifier vers quoi le nom se résout

Un nom d’hôte peut avoir l’air inoffensif et pointer malgré tout à l’intérieur de votre réseau. router.example.net peut avoir un enregistrement DNS qui indique 192.168.1.1.

Donc, quand un téléchargement avec session ouverte est sur le point d’être mis en file d’attente, KwaFlux résout aussi le nom d’hôte, avec un délai d’expiration de 2 secondes. Si le nom renvoie vers cet ordinateur ou vers un réseau privé, le téléchargement est refusé.

C’est cette vérification qui intercepte les noms d’hôte publics dont les enregistrements DNS pointent vers 127.0.0.1 ou vers une adresse privée.

L’exception du fake-IP

Certains outils proxy fonctionnent en mode « fake-IP » : ils répondent à chaque requête DNS par une adresse de la plage 198.18.0.0/15 et acheminent eux-mêmes la vraie connexion. Le registre de l’IANA classe cette plage comme « Benchmarking » (RFC 2544), et non comme une plage privée ou loopback.

Si KwaFlux traitait cette plage comme interne, tous les téléchargements échoueraient sur un ordinateur qui utilise un tel proxy. Elle est donc exclue de la vérification de l’adresse résolue.

Où s’arrête la protection

Nous tenons à être précis ici, car il est facile d’en promettre trop sur la protection contre la SSRF.

• Ce qui est couvert : le lien que soumet l’assistant. L’hôte tel qu’il est écrit et l’adresse vers laquelle son nom se résout sont tous deux vérifiés.
• Ce qui n’est pas encore couvert : ce qui se passe pendant le téléchargement. Un lien peut se résoudre en adresse publique au moment de la vérification, puis en adresse privée quelques instants plus tard (DNS rebinding), ou une page publique peut rediriger vers une adresse interne. Les recommandations de sécurité de MCP qualifient le premier cas de problème time-of-check to time-of-use (entre le moment du contrôle et celui de l’utilisation), et l’OWASP note qu’« une seconde résolution DNS, non vérifiée, entre la validation et la connexion peut contourner ces contrôles ».

La solution de fond consiste à faire passer les connexions du moteur de téléchargement par un composant qui vérifie chaque connexion, y compris chaque redirection, au moment où elle s’établit. C’est sur notre feuille de route. Nous ne l’avons pas encore fait, car cela change la façon dont le moteur de téléchargement accède au réseau dans trois bases de code distinctes et touche chaque téléchargement, y compris ceux que vous lancez vous-même : il faut donc une version et des tests dédiés.

L’affirmation exacte est donc la suivante : KwaFlux empêche un assistant IA de le diriger vers des adresses situées sur cet ordinateur et sur des réseaux privés. Il ne promet pas qu’aucune connexion ne puisse en aucun cas y aboutir, et nous ne le présentons pas comme limité à « l’Internet public uniquement ».

Deux autres limites aident en attendant. Les téléchargements par les agents sont désactivés par défaut, et, si KwaFlux doit vous demander à chaque fois, vous voyez le lien avant que quoi que ce soit ne soit récupéré. Voir pourquoi une IA ne peut pas approuver un téléchargement à votre place.

Conclusion

Vérifiez l’adresse, pas son écriture. Analysez les hôtes comme le font les navigateurs, vérifiez vers quoi le nom se résout avant qu’un téléchargement ne démarre, laissez tranquilles les plages fake-IP des proxys, et dites clairement ce qui reste ouvert. C’est ainsi que KwaFlux évite que les liens d’un assistant le transforment en scanner de votre réseau.

Votre assistant ne récupère que ce qu’il doit

Le serveur MCP local de KwaFlux permet à Codex, Claude, Cursor et aux autres applications MCP de travailler sur vos fichiers, et vérifie chaque lien que soumet un assistant. Le traitement IA tourne sur votre propre GPU et vos fichiers média ne sont pas envoyés pour être traités. KwaFlux fonctionne sous Windows 10 (64 bits, version 1809 ou plus récente), Windows 11 et macOS 12 ou plus récent sur Apple Silicon. Importer des fichiers et explorer l’app ne demandent pas de compte. Une connexion avec un forfait payant n’est requise que pour exporter, convertir, réparer un fichier ou télécharger un fichier depuis un lien.

Télécharger KwaFlux · Voir les offres