La liaison entre la demande et l'approbation empêche les changements après le clic

Une approbation humaine n'a de sens que si elle autorise une action qui ne peut plus changer. Afficher la requête HTTP ou la commande SSH proposée par un agent, puis laisser ce même agent envoyer les détails définitifs plus tard, crée un intervalle entre la vérification et l'utilisation assez large pour faire passer une requête destructive.

J'ai vu cette erreur arriver sous des dehors rassurants : une belle feuille d'approbation, un badge d'identité du processus, un état de confirmation vert. Puis l'implémentation renvoie un jeton d'approbation détenu par le client sur le protocole et accepte à côté une nouvelle URL ou une nouvelle commande. La personne en a approuvé une. L'exécuteur en a réalisé une autre. C'est une conception d'autorisation défaillante, même si personne n'avait l'intention de la contourner.

Un aperçu doit décrire un objet d'autorisation immuable

L'écran d'approbation doit afficher un objet d'action conservé, et l'exécuteur doit envoyer ce même objet après l'approbation. L'écran montre l'état de référence. Il ne demande pas au client de répéter sa proposition avec davantage de soin.

Créez l'objet avant toute demande d'approbation. Donnez-lui un identifiant d'action aléatoire, associez-le au processus et à la session qui l'ont demandé, résolvez les paramètres propres au canal et conservez-le en mémoire ou dans un stockage local chiffré contrôlé par l'exécuteur. Le client peut recevoir un état en attente et un identifiant. Il ne doit pas recevoir une capacité lui permettant d'ajouter de nouveaux paramètres d'exécution plus tard.

Imaginez plutôt un ticket de restaurant qu'un permis. Une fois le ticket marqué comme approuvé par le serveur, la cuisine ne demande pas au client de décrire à nouveau son dîner. Elle prépare le ticket qu'elle détient. Si la commande change, la cuisine reçoit un nouveau ticket et le client voit la modification.

L'objet immuable doit contenir davantage que les champs visibles dans un aperçu compact. Il lui faut aussi l'identité du processus, l'identifiant de session, l'heure de création, l'heure d'expiration, le canal, la référence de l'identifiant, les détails normalisés de l'action et un condensat de liaison. Le condensat permet de détecter une mutation accidentelle ou une substitution volontaire, mais c'est la possession de l'objet par l'exécuteur qui assure réellement la sécurité.

Une réponse d'approbation devrait donc signifier uniquement : « approuver l'action 7c91... avec le condensat de liaison sha256:... ». Elle ne doit pas signifier « ce processus peut effectuer un appel HTTP » ou « l'appelant pourra exécuter la commande X plus tard ». Ces affirmations plus larges ont leur place dans l'autorisation de session, mais elles ne peuvent pas remplacer le consentement à un effet de bord précis.

Cette distinction compte particulièrement avec les agents autonomes, car le client n'est pas un greffier de confiance qui retranscrit fidèlement une décision humaine. C'est un programme actif qui peut réessayer, composer des appels de suivi, modifier son plan après le résultat d'un outil ou simplement contenir un bug. Considérez comme suspect tout champ qu'il peut encore influencer après l'aperçu.

Un aperçu HTTP doit nommer chaque paramètre effectif

Une approbation HTTP lie la méthode, la destination complète, les en-têtes effectifs, le corps et le comportement d'envoi qui peuvent modifier le sens de la demande. Un aperçu disant « POST vers le service de facturation » donne bien trop peu d'informations pour approuver un appel qui modifie l'état du système.

La RFC 9110 sépare la méthode, la cible, les champs et le contenu de la demande, car les serveurs peuvent attribuer un sens différent à chacun. Le code d'autorisation doit conserver cette séparation. Ne rédigez pas une phrase agréable pour la feuille d'approbation en laissant ensuite une couche inférieure compléter les éléments moins présentables.

Pour une demande sortante, capturez ces valeurs après résolution des modèles et des valeurs par défaut :

• Le schéma, le nom d'hôte, le port, le chemin et la chaîne de requête.
• La méthode HTTP et l'autorisation éventuelle de suivre les redirections.
• Le nom et la valeur de chaque en-tête effectif, à l'exception des secrets injectés par le coffre.
• Les octets finaux du corps, leur type de contenu, leur longueur et leur condensat.
• La référence de l'identifiant et le mode d'injection, par exemple bearer ou en-tête personnalisé.

La valeur de l'identifiant n'a pas sa place dans l'aperçu ni dans le contexte de l'agent. La personne doit tout de même disposer d'assez d'informations pour juger de son utilisation. « Identifiant de paiement de production envoyé uniquement à api.example.test comme jeton bearer » raconte une histoire différente de « identifiant joint ». L'exécuteur peut afficher cette description à partir d'un enregistrement du coffre sans exposer le jeton.

N'approuvez pas un modèle non développé. Supposons que l'agent propose POST /users/{id}/role avec un corps contenant {role}. Si un autre composant développe ces variables après l'approbation, il peut modifier la cible effective ou le niveau de privilège. Résolvez d'abord les variables, puis créez l'objet d'action. Lorsqu'une donnée ne sera volontairement disponible que plus tard, demandez l'approbation au moment où elle devient concrète.

Les en-têtes demandent plus d'attention que ne leur en accordent la plupart des équipes. Un en-tête dupliqué, un Content-Type modifié, l'ajout d'un en-tête de remplacement ou un encodage différent de la requête peuvent changer le comportement du serveur tout en laissant un résumé convivial inchangé. Conservez les champs répétés dans leur ordre lorsque le protocole ou le serveur cible donne un sens à cet ordre. Refusez les données ambiguës au lieu de les réunir silencieusement avec des virgules.

Une structure interne raisonnable pourrait ressembler à ceci. Il s'agit d'un modèle d'implémentation, pas d'un contrat d'endpoint :

{
  "action_id": "7c91e2d4",
  "binding": "sha256:4f06...",
  "caller": {"session": "p-481", "process_start": "..."},
  "http": {
    "method": "PATCH",
    "url": "https://api.example.test/v1/users/42",
    "headers": [["content-type", "application/json"]],
    "body_sha256": "a4d8...",
    "body_length": 31,
    "redirects": "deny"
  },
  "credential_ref": "vault:payments-prod"
}

Après l'approbation de cet objet, la couche de transport lit http et credential_ref dans son propre enregistrement conservé. Elle n'accepte pas une seconde URL, une nouvelle carte d'en-têtes ou un autre corps provenant du client. Cette dernière règle empêche le bug ; le condensat sert uniquement à prouver à quel enregistrement l'approbation faisait référence.

Les commandes SSH ont besoin de leur contexte d'exécution résolu

L'aperçu d'une commande SSH doit lier le contexte d'exécution distant, car la chaîne de commande seule ne dit pas à la personne ce qui sera exécuté. Le même texte peut produire des effets différents selon l'utilisateur, l'hôte, le shell, le répertoire de travail, l'environnement ou le flux d'entrée standard.

La RFC 4254 définit une demande du protocole de connexion SSH pour l'exécution d'une commande, mais elle ne crée pas de limite d'approbation lisible par une personne. SSH transmet une chaîne de commande au serveur. L'interprétation par le shell distant, la configuration du compte, les commandes forcées et les enveloppes de commande peuvent ajouter un sens absent d'un aperçu élémentaire.

Conservez et affichez le nom d'hôte, le port, l'utilisateur distant, l'attente concernant l'authentification de l'hôte, la référence de l'identité, les octets exacts de la commande, le mode d'exécution, l'allocation du terminal, le répertoire de travail, l'environnement fourni ainsi que le condensat et la longueur de l'entrée standard. Pour une opération sur fichier menée par un outil SSH, liez également le chemin distant, le type d'opération, le condensat du fichier et tout comportement d'écrasement.

Le mode d'exécution n'est pas un détail esthétique. Ces deux commandes ne sont pas interchangeables :

/usr/local/bin/deploy --environment=staging
sh -lc '/usr/local/bin/deploy --environment=staging'

La première demande une exécution directe, si l'outil l'accepte. La seconde demande explicitement à un shell d'analyser la chaîne. L'analyse par le shell introduit l'expansion, la substitution de commandes, le comportement au démarrage du shell et les règles de guillemets. Si votre produit accepte les deux modes, indiquez-les clairement et ne transformez jamais l'un en l'autre après l'approbation.

Ne créez pas un aperçu à partir d'une commande formatée pour l'affichage tout en exécutant un tableau assemblé séparément. Une chaîne affichée peut masquer un argument vide, un saut de ligne, un caractère non imprimable ou la différence entre --file=/tmp/a b et deux arguments. Produisez une représentation échappée sûre à partir de la séquence exacte d'octets ou du vecteur d'arguments utilisé par l'outil. Si la commande contient des octets impossibles à afficher de façon sûre, refusez-la ou montrez une représentation encodée explicite que l'utilisateur peut inspecter.

Les changements de destination distante demandent la même rigueur que les redirections HTTP. Un alias de configuration SSH local, un saut par proxy ou une recherche dans la configuration de l'hôte peut transformer un nom court en une destination différente. Résolvez le plan de connexion final avant l'approbation et liez-le. Si le rejeu DNS fait partie du modèle de menace, ajoutez avec prudence une règle distincte pour les adresses d'hôte ; fixer une adresse peut casser le basculement habituel, tandis qu'ignorer un résolveur hostile peut envoyer un nom d'hôte valide vers la mauvaise machine. Ne prétendez pas qu'un aperçu de commande règle ce problème distinct.

L'intervalle vulnérable commence après le clic

La défaillance survient lorsque l'interface vérifie les détails proposés, enregistre un accord, puis qu'un chemin d'exécution ultérieur lit des détails modifiables depuis le client. Elle se cache souvent derrière du code asynchrone tout à fait ordinaire.

Prenons le cas d'un processus agent qui demande à une passerelle de transférer des fonds :

1. Le client envoie POST https://api.example.test/transfers avec un corps correspondant à 50 unités.
2. La passerelle crée un aperçu et attend l'approbation d'une personne.
3. La personne approuve après avoir lu la destination et le montant.
4. Le client envoie execute avec l'identifiant d'approbation et un nouveau corps correspondant à 5 000 unités.
5. La passerelle vérifie uniquement que l'identifiant d'approbation est valide, injecte l'identifiant et envoie le nouveau corps.

Rien dans cette séquence ne nécessite une interface compromise ou un identifiant volé. Le client a utilisé une API proposée par la passerelle. Un test qui approuve la demande initiale et vérifie seulement que l'identifiant fonctionne réussira. Un test qui compare les octets sortants finaux aux octets représentés par l'objet approuvé échouera, ce qui est exactement le résultat recherché.

La même erreur apparaît lorsqu'une passerelle conserve par référence un objet de demande modifiable. Un processus d'aperçu le lit, un gestionnaire de nouvelle tentative côté agent le modifie, puis le processus d'envoi transmet la version modifiée. Copier l'objet ne suffit pas si les cartes imbriquées, les tampons du corps ou les rappels restent partagés. Créez une valeur immuable sans références détenues par le client, ou sérialisez-la dans une représentation de référence et reconstruisez-la uniquement à partir de cette représentation.

L'expiration ne corrige pas un état modifiable. Une approbation valable trente secondes peut toujours autoriser une demande modifiée envoyée pendant la première seconde. Les limites de débit ne corrigent rien non plus. Elles réduisent la fréquence à laquelle un client peut exploiter une erreur, mais ne changent pas ce que la personne a approuvé.

Gardez la machine à états assez petite pour être auditée :

proposed -\u003e frozen -\u003e awaiting_human -\u003e approved -\u003e dispatched
                         |                 |
                         v                 v
                      rejected           expired

Seule la transition de approved à dispatched peut effectuer l'action externe. Cette transition doit charger l'enregistrement figé par identifiant d'action, revérifier l'appelant et l'expiration, puis transmettre directement l'enregistrement à l'exécuteur HTTP ou SSH. Toute demande de modification revient à proposed et crée un nouvel identifiant.

Liez les octets lorsque la sémantique peut dériver

Une liaison a besoin d'une représentation stable. Sinon, deux composants peuvent croire avoir approuvé la même demande tout en construisant des données différentes sur le réseau. La difficulté consiste à décider quelle représentation doit faire autorité.

Pour les demandes JSON simples, normalisez une structure selon des règles documentées, sérialisez-la une fois, puis conservez les octets finaux du corps et leur condensat. L'aperçu peut afficher un JSON lisible, tandis que le chemin d'envoi transmet les octets conservés. N'analysez jamais, ne reformatez jamais et ne sérialisez jamais à nouveau après l'approbation, sauf si la sortie transformée est l'objet qui a été approuvé.

Pour les formulaires, les chargements multipart, les en-têtes répétés ou les données binaires arbitraires, les octets constituent généralement la limite la plus sûre. Liez les octets exacts, le type de contenu et les décisions de cadrage du transfert qui influencent l'interprétation par le serveur. Un condensat permet à l'interface d'identifier un corps volumineux sans afficher un document privé sur une feuille d'approbation, mais l'exécuteur doit conserver ces octets exacts ou pouvoir les régénérer depuis un état de confiance.

La canonisation des URL est un autre piège. Normaliser la casse d'un nom d'hôte est généralement sans danger. Décoder et réencoder un chemin, trier les paires de requête, supprimer une valeur vide ou considérer + et %20 comme équivalents peut modifier la manière dont une application achemine ou valide une demande. Choisissez une forme canonique précisément définie, documentez-la et refusez les entrées qui admettent plusieurs interprétations plausibles. « Nous normalisons les URL » n'est pas une propriété de sécurité.

Pour SSH, un vecteur d'arguments vaut mieux qu'une chaîne shell lorsque l'outil de protocole peut l'exécuter sans invoquer de shell. Liez chaque argument comme une séquence d'octets distincte. Si le côté distant reçoit nécessairement une seule chaîne de commande shell, liez cette chaîne exactement et présentez fidèlement son échappement. Ne prétendez pas qu'un analyseur sur la machine locale peut prouver ce que fera le fichier de démarrage d'un shell distant arbitraire.

Le condensat d'approbation doit couvrir un encodage versionné et séparé par domaine. Préfixez les données encodées par une étiquette fixe comme action-v1/http ou action-v1/ssh, incluez tous les champs immuables avec des longueurs sans ambiguïté ou un sérialiseur déterministe, puis hachez le résultat. Le versionnage empêche qu'une ancienne interprétation devienne silencieusement une nouvelle après une mise à niveau. La séparation par domaine empêche qu'un objet HTTP corresponde un jour à un objet SSH simplement parce que leurs octets sérialisés coïncident.

L'identité de l'appelant et la liaison de l'action règlent deux problèmes différents

L'autorisation par session indique quel processus en cours peut demander des actions. La liaison d'action indique quelle action exacte ce processus peut exécuter. Les deux sont nécessaires et aucun ne remplace l'autre.

Liez l'action à l'identité du processus observée par la passerelle, et non à un nom envoyé par le client. Sur macOS, cette identité peut inclure l'autorité de signature du code, l'identifiant du processus et son instance de démarrage. L'instance de démarrage compte, car un système d'exploitation peut réutiliser un identifiant de processus. Si le processus se termine, supprimez ses actions en attente et approuvées avec l'autorité de session.

Ne laissez pas un processus enfant hériter d'une approbation étendue simplement parce qu'il connaît l'identifiant de son parent. Observez chaque processus qui se connecte à la limite de la passerelle. Si l'architecture de vos outils rend cela impossible, indiquez clairement cette limite et réduisez la durée de l'approbation au lieu de feindre une certitude que vous n'avez pas.

L'approbation humaine doit également avoir une durée de vie courte et limitée. L'expiration doit figurer dans l'objet figé et dans la décision d'approbation, pas seulement dans un minuteur de l'interface. Une fois l'expiration passée, l'exécuteur refuse l'envoi, même si le client a conservé une ancienne réponse pendant toute la durée. Une session révoquée doit également empêcher l'envoi de toute action approuvée mais encore inutilisée qui lui est associée.

L'autorisation par session de Sallyport peut établir si un processus agent nouvellement connecté peut utiliser une exécution, mais une passerelle d'action a toujours besoin de cette limite immuable distincte pour chaque effet de bord affiché. Une décision de session est volontairement large ; l'approbation d'une demande HTTP ou d'une commande SSH doit rester exacte.

Ne réduisez pas le niveau de détail sous prétexte que l'identité du processus est connue. Un code signé et digne de confiance peut contenir des défauts, recevoir des entrées inattendues issues d'une injection dans les prompts ou charger un module qui emprunte une voie différente de celle prévue par son auteur. L'intérêt d'une barrière humaine est de voir l'effet concret avant qu'il ne quitte la machine.

Les nouvelles tentatives et les redirections doivent rester dans la limite approuvée

Une nouvelle tentative de transport peut réutiliser l'approbation uniquement si elle renvoie la même action figée dans les conditions enregistrées. De nombreuses implémentations de nouvelle tentative enfreignent discrètement cette règle en reconstruisant les demandes à partir d'un état client modifiable.

Définissez le comportement autorisé lors d'une nouvelle tentative au moment où vous figez l'action. Par exemple, autorisez un seul renvoi après une défaillance de connexion avant toute réponse HTTP, avec la même URL, les mêmes en-têtes, les mêmes octets de corps et la même référence d'identifiant. Enregistrez chaque tentative sous le même identifiant d'action. Ne relancez pas une demande non idempotente après une réponse incertaine, sauf si le protocole et l'API cible offrent un mécanisme d'idempotence fiable.

Un jeton d'idempotence n'est utile que s'il est lui-même lié. Si l'exécuteur en génère un, faites-le au moment de figer l'action et conservez-le dans l'ensemble d'en-têtes approuvé. Si le client en fournit un, considérez-le comme une partie de la demande approuvée. Le remplacer lors d'une nouvelle tentative peut faire produire un second effet de bord à une seule approbation.

La récupération après un problème d'authentification mérite la même méfiance. Si un coffre renouvelle un identifiant en interne, mais envoie la même demande approuvée à la même destination, l'action peut rester dans les limites prévues. Si la récupération modifie le locataire, la destination, la portée ou les en-têtes visibles par l'application, il s'agit d'une autre demande qui exige une nouvelle approbation. Évitez tout mécanisme en arrière-plan qui transforme un échec d'autorisation en appel alternatif non examiné.

Le comportement HTTP par défaut face aux redirections doit être le refus pour les actions approuvées. Une redirection qui conserve tous les champs pertinents peut malgré tout franchir la limite d'une autre autorité. Si le produit permet de suivre les redirections, examinez chaque saut avant l'envoi et exigez un nouvel objet d'action lorsque l'hôte, le port, la méthode ou le corps change. Traitez une redirection relative vers la même autorité selon une règle explicite, et non selon ce que décide par hasard la bibliothèque cliente utilisée.

Les reconnexions SSH suivent une règle similaire. Reconnectez-vous uniquement au plan d'hôte lié, avec l'identité et la commande liées. Une nouvelle empreinte d'hôte découverte, une route de proxy modifiée ou un changement de résolution de l'hôte peuvent exiger une nouvelle décision humaine selon votre modèle de menace. Le code de nouvelle tentative doit être suffisamment prévisible pour qu'un auditeur puisse constater qu'il ne peut pas élargir l'approbation initiale.

Auditez l'approbation et l'exécution comme deux événements distincts

Un enregistrement d'audit doit conserver à la fois l'action examinée par la personne et les tentatives effectuées par l'exécuteur. Un journal qui n'enregistre que la demande finale ne peut pas prouver que l'aperçu lui correspondait, et un journal qui n'enregistre que l'approbation ne peut pas prouver que l'envoi a eu lieu.

Enregistrez l'identifiant de l'action figée, son condensat de liaison, l'identité de l'appelant, les champs sans danger de l'aperçu, l'identifiant de référence du secret, l'heure d'approbation, l'expiration et le résultat. Enregistrez ensuite chaque tentative d'envoi avec le même identifiant, le résultat du transport, la raison d'une nouvelle tentative éventuelle et un condensat du corps ou de la commande réellement envoyé. Gardez les valeurs secrètes hors du journal visible par l'utilisateur comme de la réponse de l'agent.

C'est ici qu'un journal chaîné par hachage devient utile. Une chaîne peut révéler la suppression ou le réordonnancement d'entrées précédentes lorsque la vérification porte sur la séquence conservée. Elle ne peut pas rendre utile un événement vague. Si l'enregistrement dit seulement « action SSH approuvée », la chaîne préservera fidèlement un événement vague pour toujours.

Pour une passerelle qui conserve un journal chiffré, chaîné par hachage et impossible à modifier par écriture, un vérificateur hors ligne doit contrôler la chaîne de texte chiffré indépendamment de l'accès au coffre. Sallyport propose ce contrôle avec sp audit verify, ce qui est utile, car un enquêteur peut vérifier la continuité sans ouvrir d'abord le coffre d'identifiants.

La sortie d'audit doit rendre la liaison visible. Un réviseur doit pouvoir constater que l'approbation 7c91e2d4 couvrait le condensat 4f06..., que l'envoi a utilisé le même condensat et que l'exécuteur a refusé toute proposition différente. Évitez les journaux qui impriment un résumé humain au moment de l'approbation, puis une demande brute distincte au moment de l'exécution, sans lien durable entre les deux.

Testez le client comme s'il voulait changer d'avis

Un test d'intégration classique prouve qu'une action approuvée réussit. Un test de sécurité doit prouver qu'une action approuvée ne peut pas devenir une autre, même lorsque le client se comporte mal après le clic de la personne.

Construisez un banc de test qui s'interrompt immédiatement après l'approbation. Pendant que l'envoi attend, modifiez une à une toutes les données contrôlées par le client : méthode, hôte, port, chemin, requête, valeurs d'en-tête, en-têtes répétés, corps, sélection de l'identifiant, paramètre de redirection, utilisateur SSH, commande, environnement, entrée standard et condensat du fichier. L'exécuteur doit soit envoyer l'action originale conservée, soit refuser la tentative. Il ne doit jamais envoyer la version modifiée.

Testez les conditions de concurrence aussi volontairement que les changements de champs. Envoyez deux messages execute pour un seul identifiant approuvé. Annulez l'approbation et envoyez execute exactement au même moment. Laissez le processus demandeur se terminer, puis reconnectez un nouveau processus qui tente d'utiliser l'ancien identifiant. Redémarrez l'interface pendant qu'une approbation est en attente. Remplissez le stockage des actions en attente jusqu'au déclenchement du nettoyage des éléments expirés. Ce sont des événements ordinaires du cycle de vie, et le code d'autorisation échoue souvent dans les interstices qui les séparent.

Utilisez un faux serveur HTTP qui signale la méthode exacte, la cible, les en-têtes dupliqués et le condensat du corps reçus. Utilisez un endpoint SSH contrôlé qui enregistre l'utilisateur distant, les octets de la commande, la demande de terminal, l'environnement et le condensat de l'entrée standard. Vérifiez ces observations, et pas seulement l'objet représentant l'intention de la passerelle. Tout l'enjeu est de détecter une divergence entre l'intention et le transport.

Enfin, rendez les échecs faciles à comprendre. Un message utile indique que le condensat d'approbation 4f06... couvrait PATCH /v1/users/42, tandis que l'envoi tenté portait un condensat différent et a été refusé. Un vague message « échec de l'autorisation » renvoie les ingénieurs aux simples instructions d'affichage et les pousse à affaiblir les contrôles jusqu'à ce que le test passe au vert.

Placez la limite d'immutabilité à côté de l'exécuteur

Le composant qui détient les identifiants et ouvre la connexion HTTP ou SSH doit posséder l'action approuvée figée. Toute limite placée plus tôt laisse à une autre couche la possibilité de la réinterpréter, de la reconstruire ou de la remplacer.

Cette conception rend aussi l'interaction humaine honnête. La personne voit un aperçu généré à partir de l'objet qui sera envoyé ; l'agent reçoit des résultats, pas des identifiants ; et la piste d'audit possède un identifiant unique reliant intention, approbation et exécution. Ces avantages sont distincts, mais ils reposent tous sur le même refus d'accepter des changements après le clic.

Si votre flux actuel renvoie un jeton d'approbation à l'agent et accepte ensuite de nouveaux champs d'action, corrigez cela avant d'améliorer le texte, d'ajouter des contrôles de politique ou d'afficher une autre boîte de dialogue d'approbation. Figez d'abord la demande. Puis faites en sorte que l'exécuteur prouve qu'il a utilisé l'enregistrement figé.