Tester les frontières de confiance entre fonctionnalités

Les tests des frontières de confiance entre fonctionnalités vérifient si une capacité sûre dans une partie d’une application devient dangereuse lorsqu’une autre fonctionnalité peut y accéder. Partez de ce que l’attaquant maîtrise, suivez chaque passage vers un contexte plus privilégié et testez les combinaisons qui rendent ce passage possible. Les vérifications de sécurité de chaque fonctionnalité ne fournissent qu’une partie des preuves nécessaires.

Pour une petite équipe de sécurité, le résultat utile est concret : une courte matrice des états des fonctionnalités, un rapport de vulnérabilité qui établit la capacité devenue accessible et une nouvelle vérification couvrant les variantes déployées. Vous pouvez commencer par un contenu partagé et les composants qui reçoivent des messages ou affichent du contenu pour son compte.

Un aperçu peut être isolé alors que son récepteur accorde trop de confiance

Dans son rapport du 28 octobre, Parameter a décrit une chaîne d’attaque dans ChatGPT associant une conversation partagée, un graphique et un aperçu HTML. Selon les chercheurs, le graphique chargeait MathLive dans la page principale. L’aperçu pouvait ensuite envoyer des messages à un récepteur qui acceptait du HTML définissant une disposition de clavier sans vérifier suffisamment l’expéditeur. Ce chemin de rendu créait un cadre sans bac à sable ; un point d’accès autorisé pour des scripts tiers permettait de contourner la CSP.

Parameter a démontré un accès aux données de conversations privées via la session connectée. La reproduction la plus stable nécessitait d’ouvrir le contenu partagé et de cliquer sur « Preview ». Parameter a également rapporté trois reproductions dans lesquelles l’aperçu s’ouvrait automatiquement. Selon Parameter, OpenAI a confirmé le 26 octobre que les deux versions de l’interface web rejetaient les messages signalés.

Il s’agit de résultats rapportés par les chercheurs, pas de tests que nous avons réalisés. La discussion sur Hacker News fournit le contexte de l’actualité. La leçon pratique consiste à tester la manière dont des fonctionnalités distinctes se transmettent des pouvoirs, y compris par les chemins qui permettent de les publier ou de les partager.

Cette démarche diffère de la vérification visant à savoir si un texte malveillant peut détourner un agent. L’injection de prompt dans le chemin de récupération d’un agent de recrutement concerne l’influence du contenu récupéré sur un assistant qui utilise des outils. Un récepteur dans le navigateur peut accepter une instruction non autorisée sans qu’il soit nécessaire de convaincre un modèle. La démarche diffère aussi de l’isolation des clients chez un fournisseur, qui consiste à vérifier si les traitements en aval séparent correctement les clients.

Repérez le moment où les données deviennent un pouvoir d’action

Une carte des frontières doit identifier à la fois l’entrée non fiable et l’opération privilégiée qu’elle peut influencer. Dire que « l’aperçu est dans un bac à sable » décrit un composant. Cela ne dit pas ce que l’application environnante fera lorsque cet aperçu enverra un message.

Décrivez le chemin en termes simples :

1. Une personne extérieure au compte de la victime maîtrise un contenu partagé.
2. Son ouverture charge un composant dans une page authentifiée.
3. Un autre composant accepte une instruction provenant de ce contenu.
4. L’instruction influence le rendu, une requête ou une action sur le compte.

Pour chaque transition, nommez le récepteur et la raison pour laquelle il accepte l’entrée. Vérifie-t-il une origine exacte ? Une fenêtre précise ? Un type de message ? Une décision d’autorisation côté serveur ? Si la seule réponse est que le message respecte la structure attendue, vous avez identifié une hypothèse à examiner.

Les recommandations de MDN sur postMessage demandent de vérifier l’identité de l’expéditeur et de valider les données reçues. Elles recommandent aussi de préciser une origine cible exacte lors de l’envoi. Un format de message reconnu ne donne pas l’autorisation d’utiliser les capacités du récepteur.

Distinguez les pouvoirs du navigateur de ceux du serveur dans cette carte. Un serveur peut autoriser correctement une requête au nom de l’utilisateur connecté alors qu’un code maîtrisé par l’attaquant a obtenu la possibilité d’émettre cette requête. L’enquête doit alors expliquer comment ce code est entré dans le contexte authentifié.

Construisez une petite matrice de combinaisons de fonctionnalités

Testez le plus petit ensemble de combinaisons permettant d’établir où la frontière change. Commencez par chaque composant seul, puis associez-les. Incluez le chemin qu’une autre personne utilise réellement pour ouvrir le contenu partagé.

La matrice ci-dessous illustre la préparation de tests pour une application proposant des aperçus partagés. Elle ne consigne aucun test réalisé sur ChatGPT ou Kit.

Notez le comportement attendu avant d’exécuter chaque ligne. Par exemple : « La fenêtre parente rejette un message de paramètres provenant de cet aperçu, car l’expéditeur n’a pas l’autorisation de modifier ce paramètre. » Une tentative d’exploitation qui échoue reste ambiguë. Le récepteur a pu la rejeter, ou ne jamais avoir été chargé.

Utilisez des comptes de test autorisés et des marqueurs inoffensifs. Pour examiner une capacité d’accès aux données privées, créez une donnée de test contenant une valeur synthétique impossible à confondre. Il faut assez de preuves pour établir le franchissement ; recueillir les données de véritables utilisateurs accroît l’exposition sans améliorer l’explication.

Faites varier volontairement les délais lorsque les composants s’initialisent indépendamment. Notez si une action ne fonctionne qu’après le chargement d’une autre fonctionnalité, si un rechargement change le résultat et si l’interface normale exige un clic supplémentaire. Ces conditions doivent figurer dans le rapport, car elles influencent la reproductibilité et les circonstances dans lesquelles une personne pourrait rencontrer le problème.

Pour le triage, démontrez les possibilités offertes par la faille

Un rapport utile établit ce qui est devenu possible dans le contexte touché. Une capture d’écran d’une alerte peut aider à montrer où JavaScript s’est exécuté. Elle ne dit pas quelles données ou opérations cette exécution pouvait atteindre.

Préparez le rapport pour qu’un autre développeur puisse reproduire le résultat sans faire de suppositions :

• Maîtrise de l’attaquant : le contenu, le champ, le fichier ou le message que l’auteur du rapport peut fournir.
• Conditions côté victime : état du compte, rôle, fonctionnalités activées et interactions requises.
• Frontière franchie : contexte de l’expéditeur, récepteur et opération acceptée par ce dernier.
• Reproduction minimale : chemin d’accès et séquence exacts, avec des données de test synthétiques.
• Comportements attendu et observé : ce qui aurait dû être refusé et ce qui s’est produit à la place.
• Conséquences démontrées : donnée privée de test ou action restreinte précisément atteinte.
• Limites : résultats sensibles aux délais, rôles non testés, variantes indisponibles et prolongements hypothétiques.

Distinguez une lecture démontrée d’une écriture envisagée. Si la preuve récupère une donnée privée synthétique, indiquez directement cette atteinte à la confidentialité. Si une autre action sur le compte paraît accessible sans avoir été testée, présentez-la comme une hypothèse. Une formule générale comme « prise de contrôle complète du compte » ne remplace pas les preuves concrètes dont l’équipe a besoin pour évaluer l’étendue du problème.

Lorsqu’un rapport ne peut pas être reproduit, cherchez la condition manquante avant de l’écarter. Une fonctionnalité associée, une autre version de l’interface ou une seconde interaction peuvent expliquer la différence. Demandez explicitement cette précision, puis ajoutez-la à la matrice pour que la prochaine reproduction parte du même état.

Vérifiez la correction du récepteur sur l’ensemble du chemin

La vérification d’une correction doit établir pourquoi le franchissement initial échoue désormais. Bloquer un script en aval peut arrêter une démonstration particulière tout en laissant des messages non autorisés influencer un rendu de confiance.

Examinez la décision du récepteur et testez de nouveau le chemin depuis le contenu partagé. L’expéditeur non fiable peut-il encore modifier le paramètre ? Ses données peuvent-elles toujours atteindre un point d’insertion HTML ? Le contenu créé dynamiquement conserve-t-il les restrictions prévues ? Quel mécanisme rejette l’opération, et le test peut-il observer ce rejet ?

Les recommandations sur la messagerie web du Web Security Testing Guide d’OWASP couvrent la vérification de l’origine et le traitement des entrées. Même une entrée provenant d’une origine autorisée doit être validée de manière adaptée. Traitez l’origine, l’identité de la fenêtre, la structure du message et l’opération autorisée comme des questions distinctes.

Reprenez la matrice initiale pour la nouvelle vérification, puis ajoutez les variantes proches que justifie le code touché. Il peut s’agir d’un autre chemin de partage, d’un composant utilisant le même récepteur ou d’une ancienne interface qui reçoit encore du trafic. Évitez de transformer chaque rapport en audit sans limite ; suivez le mécanisme commun et documentez le point où l’examen s’arrête.

Vérifiez aussi le comportement légitime. Un composant autorisé doit toujours pouvoir réaliser l’opération prévue après le rejet de l’expéditeur non autorisé. Sinon, une correction qui désactive entièrement la fonctionnalité peut satisfaire le test de sécurité tout en empêchant les utilisateurs de travailler.

Distinguez la résolution de sa vérification

Consignez la correction et les preuves qui la confirment en deux étapes distinctes. Un changement déployé établit qu’une correction a été mise en production. La vérification établit ce qui a été testé de nouveau, sur quelle version et avec quel résultat.

Le processus de sécurité de Kit prévoit les états distincts « Résolu » et « Correctif vérifié » pour les rapports. Cette distinction permet à l’équipe de suivre le passage de relais. Elle n’exécute pas la matrice de tests dans le navigateur et ne prouve pas qu’une frontière tient ; le rapport doit toujours contenir la reproduction, les détails de version et les preuves de la nouvelle vérification.

Commencez cette semaine par un contenu public ou partageable. Dressez la liste des composants privilégiés qu’il peut contacter, choisissez un récepteur capable de modifier un état et testez le contenu seul, puis associé à la fonctionnalité qui charge ce récepteur. Le résultat doit indiquer où les autorisations sont vérifiées et donner au prochain développeur assez de preuves pour vérifier la même frontière.