Les tests d'automatisation de l'interface macOS peuvent-ils contourner une approbation d'agent ?

Une carte d'approbation n'est un contrôle de sécurité que si c'est la personne, et non un autre processus, qui provoque l'approbation. Cela paraît évident jusqu'à ce que vous placiez la carte dans un bureau macOS ordinaire, où les clients d'accessibilité peuvent inspecter les contrôles, les outils d'automatisation peuvent activer les applications et toute fenêtre au premier plan peut se disputer le prochain clic.

Ne testez pas cela en vous demandant si la carte semble modale ou si son bouton porte un intitulé rassurant. Vérifiez plutôt si un processus qui dispose déjà de privilèges locaux réalistes peut provoquer une action protégée sans que la personne concernée fasse un choix délibéré et éclairé. Le résultat utile n'est pas une vidéo spectaculaire d'exploitation. C'est une réponse reproductible à une question plus précise : quels chemins d'entrée peuvent franchir la frontière d'approbation, avec quelles autorisations, et quelles preuves établissent le résultat ?

Il s'agit d'un exercice d'équipe rouge pour un logiciel qui vous appartient, sur un Mac et un compte que vous contrôlez. Gardez l'action demandée inoffensive. Utilisez un point de terminaison HTTP factice, un hôte SSH hors production ou une action qui renvoie une valeur de test fixe. Un test de sécurité qui peut par accident dépenser de l'argent, supprimer des données ou modifier des accès de production est mal défini avant même l'écriture du moindre script.

L'autorisation d'accessibilité change le modèle d'attaque

Un processus autorisé à utiliser l'accessibilité n'est pas un processus d'arrière-plan ordinaire. Apple décrit l'accès à l'accessibilité comme la possibilité pour les applications de contrôler un Mac, et macOS exige que la personne l'accorde dans les réglages Confidentialité et sécurité. Apple décrit séparément l'autorisation Automatisation, qui permet d'accéder à d'autres applications et de les contrôler. Ces autorisations sont différentes, mais toutes deux doivent entrer dans le modèle de menace lorsqu'une carte d'approbation se trouve sur le bureau.

La distinction que les équipes brouillent régulièrement est la suivante : une interface d'approbation peut être accessible sans que toute action provenant de l'accessibilité soit considérée comme la preuve d'une intention humaine. L'accessibilité doit exposer des intitulés, des rôles, des changements d'état et le focus afin que les personnes utilisant des technologies d'assistance puissent manipuler l'application. C'est une exigence d'inclusion. Elle n'oblige pas l'application à laisser un processus étranger déclencher l'action de confirmation irréversible sans aucun signal local de la personne.

Commencez le test par une description précise de l'attaquant que vous simulez. Évitez l'étiquette vague « logiciel malveillant ». Elle dissimule les autorisations qui déterminent le résultat. Un attaquant de référence utile est un assistant signé qui s'exécute localement sous le même utilisateur connecté et qui a déjà reçu l'autorisation d'accessibilité. Une variante plus forte possède aussi l'autorisation Automatisation et peut demander l'activation d'une application. Aucune de ces variantes ne dispose des identifiants administrateur, d'un contournement du verrouillage de l'écran ou d'une copie modifiée de l'application d'approbation.

Cette limite rend le test équitable. Si votre conclusion est « un attaquant qui contrôle entièrement le compte utilisateur peut contrôler le compte utilisateur », vous n'avez rien appris. Si elle est « un assistant disposant des mêmes autorisations qu'un utilisateur pourrait accorder à un gestionnaire de fenêtres, un outil de test, un outil de macros ou un utilitaire d'assistance peut approuver l'utilisation d'un identifiant », vous avez trouvé un problème de conception avec une voie de correction claire.

Établissez une fiche de capacités avant le premier essai :

N'accordez pas une autorisation simplement parce qu'un outil de test la demande. Chaque autorisation supplémentaire modifie l'affirmation que vous pourrez faire ensuite. Notez la combinaison exacte dans le titre du résultat, par exemple « Un assistant avec l'accessibilité seule ne peut pas confirmer une approbation par appel », plutôt que « l'approbation est sûre ». La seconde affirmation ne résiste pas à une autre configuration du bureau.

Enregistrez aussi l'identifiant de paquet de l'assistant, son autorité de signature, son identifiant de processus, son processus parent et son chemin de lancement. Un bon système d'approbation doit afficher suffisamment d'informations sur le processus pour permettre à une personne d'évaluer la demande, mais votre dossier de test doit être plus détaillé que ce qu'une carte peut raisonnablement montrer. L'opérateur doit pouvoir déterminer si un processus enfant a hérité d'un parent d'apparence fiable, si un terminal a lancé l'assistant et si un nouveau lancement a créé une nouvelle identité de processus.

Un bouton cliquable ne prouve pas une approbation faible

Un bouton exposé par la hiérarchie d'accessibilité de macOS n'est pas automatiquement une vulnérabilité. AppKit attend des éléments d'accessibilité qu'ils participent à cette hiérarchie afin que les clients d'assistance puissent trouver un contrôle fonctionnel. Apple précise que les contrôles exposent notamment des propriétés comme les intitulés, les titres, les cadres et leur état activé.

La conception faible est celle où l'invocation de ce bouton suffit à prouver une action sensible. Une action d'accessibilité synthétique devient alors impossible à distinguer d'un clic conscient. Le problème passe aussi souvent inaperçu : l'équipe teste avec une souris, observe le rappel attendu et ne se demande jamais ce qui pourrait produire le même rappel.

Faites dépendre la décision d'approbation d'un événement d'autorisation local, et non du seul gestionnaire d'action du bouton. Le contrôle d'interface peut lancer la demande, mais l'action protégée doit attendre un résultat d'autorisation indiquant comment la confirmation a eu lieu. Pour une approbation de session ordinaire, il peut s'agir d'un clic délibéré après vérification que la propre surface d'approbation de l'application est active et à jour. Pour une action à haut risque, exigez un événement d'authentification locale médié par le système, comme Touch ID lorsqu'il est disponible.

Ne commettez pas l'erreur courante qui consiste à masquer ou renommer le bouton Approuver dans l'arbre d'accessibilité. Cela pénalise les personnes qui ont besoin de technologies d'assistance et protège peu contre un attaquant local capable de manipuler le focus ou d'emprunter d'autres chemins. Testez plutôt si le pipeline de confirmation rejette une voie synthétique, une carte périmée, une carte inactive et une demande dont les détails affichés ne correspondent plus à l'action sur le point de s'exécuter.

Un journal de décision interne utile peut ressembler à ceci :

{
  "request_id": "test-4d8f",
  "decision": "approved",
  "decision_method": "touch_id",
  "card_generation": 7,
  "request_generation": 7,
  "app_active": true,
  "card_frontmost": true,
  "requester_pid": 48102,
  "requester_signing_authority": "Example Development Team",
  "action_started_after_decision": true
}

Les noms des champs comptent moins que leur séparation. decision indique ce qui s'est passé. decision_method indique comment. Les valeurs de génération empêchent une ancienne carte d'approuver une demande plus récente après un nouvel affichage, une nouvelle tentative ou un remplacement d'action. Les champs d'activation indiquent si la personne regardait votre carte au moment de la décision. Le dernier champ permet au test de vérifier l'ordre des opérations.

Cette séparation révèle aussi un défaut subtil : accepter l'approbation trop tôt, puis afficher la carte par simple souci de présentation. Dans ce cas, tous les tests visuels réussissent. L'action protégée a déjà commencé, et la carte ne sert plus qu'à donner une apparence de contrôle. Faites en sorte que l'exécuteur de l'action exige un jeton de décision que seul le sous-système d'approbation peut créer après la fin des vérifications nécessaires.

Le banc de test doit produire des essais inoffensifs et comparables

Construisez un dispositif de test qui crée une demande d'approbation prévisible et un observateur qui recueille les preuves. Ne commencez pas avec un framework général d'automatisation du bureau dirigé vers un identifiant réel. Un banc de test doit réduire l'ambiguïté, pas en ajouter.

Votre dispositif a besoin d'une demande dotée d'un identifiant stable, de détails visibles qui changent à chaque essai, d'une expiration courte et d'un effet final inoffensif. Par exemple, faites appeler par l'action protégée un point de terminaison local qui renvoie approved:test-4d8f uniquement après la libération par le système d'approbation. Si l'action réussit sans enregistrement d'approbation valide, l'échec est clair. Si elle expire ou enregistre un refus, le résultat de non-approbation est tout aussi clair.

Utilisez un nonce de courte durée dans la carte et dans la demande protégée. Une carte qui indique seulement « Autoriser l'accès de l'agent ? » ne permet pas de révéler un problème de fenêtre périmée. Une carte qui indique « Autoriser la demande de test 4d8f à appeler le service echo de staging ? » le permet. Changez le nonce à chaque essai, puis vérifiez que le résultat de l'action contient le même nonce.

Conservez trois horloges indépendantes dans les preuves :

1. L'heure de création de la demande.
2. L'heure de la décision.
3. L'heure de début de l'action protégée.

Utilisez si possible une horloge monotone dans l'application. L'heure civile est utile pour une chronologie humaine, mais elle peut changer à cause de la synchronisation réseau, de la veille ou d'une modification manuelle. La règle d'ordre est simple : l'action doit commencer après une décision valide pour la même génération de demande. Une capture d'écran ne peut pas prouver cet ordre.

Votre observateur doit enregistrer l'application active, la fenêtre ayant le focus, l'identifiant de demande visible sur la carte et le résultat final de l'action. Un enregistrement d'écran aide à diagnostiquer un comportement surprenant, mais ne remplace pas les événements structurés. Les enregistrements perdent les identifiants de processus, compressent les transitions rapides et dissimulent souvent l'événement important derrière un mouvement de pointeur.

Utilisez une fiche comme celle-ci pour chaque tentative :

case=AX-invoke-approve
request=test-4d8f
helper=TestHelper pid=48102
permissions=accessibility
approval_surface=active
attempt=accessibility_action
decision=denied
protected_action=not_started
artifact=activity-event-0192

La valeur attempt doit décrire le mécanisme, et non le résultat recherché. Écrivez activate-then-click, stale-window, keyboard-focus-shift ou voiceover-navigation, plutôt que attack-1. Six semaines plus tard, cette description simple évitera à quelqu'un de relancer le mauvais cas.

Exécutez d'abord le même dispositif sans autorisation pour l'assistant. C'est votre contrôle. Activez ensuite une capacité à la fois. Un résultat d'équipe rouge sans essai de contrôle est difficile à interpréter. Peut-être que votre carte n'était jamais accessible au clavier. Peut-être que le point de terminaison a échoué. Peut-être que l'assistant de test n'avait pas l'habilitation que vous pensiez lui avoir accordée. Le contrôle rend ces explications visibles par comparaison.

Tester l'approbation synthétique sans transformer le test en kit d'exploitation

L'objectif de ce cas est de déterminer si un client d'accessibilité autorisé peut invoquer le contrôle d'approbation et provoquer l'exécution de l'action protégée. Vous n'avez besoin ni d'un outil de clic prêt à être publié ni d'une collection de scripts fragiles fondés sur des coordonnées.

Utilisez votre propre assistant de test avec une mission étroite : trouver la fenêtre d'approbation de votre application de test grâce à l'identité de l'application et au nonce de demande réservé au test, demander la même action sémantique qu'un client d'accessibilité et signaler si l'action protégée s'est terminée. Ne recherchez pas toutes les fenêtres du bureau. Ne ciblez pas les boîtes de dialogue de tiers. Ne stockez pas d'identifiants et n'interagissez pas avec de vrais comptes de service.

Testez séparément les chemins suivants, car ils ne prouvent pas la même chose :

• Une invocation sémantique d'accessibilité du contrôle Approuver.
• Une navigation au clavier qui arrive sur Approuver, suivie d'une activation synthétique.
• Une action du pointeur après que l'assistant a placé l'application d'approbation au premier plan.
• Une action du pointeur sans que l'assistant place l'application au premier plan.
• Une action différée après l'expiration de la carte ou la modification de la demande.

Le clic par coordonnées ne mérite d'être conservé que comme test de régression du chevauchement visuel. Il indique si un clic à une position donnée peut atteindre le mauvais contrôle après un changement de mise en page. Il ne dit pas si un processus étranger peut identifier et activer l'élément visé. L'automatisation sémantique de l'interface est le test le plus pertinent pour la logique d'autorisation ; les coordonnées sont plus adaptées aux erreurs de mise en page et de focus.

Les résultats devraient différer selon le mode d'approbation. Une approbation au niveau de la session est généralement conçue pour autoriser un processus agent reconnu pendant toute sa durée de vie. Si votre approbation de session accepte un simple clic, un assistant autorisé par l'accessibilité peut probablement l'imiter, sauf si l'application distingue le chemin d'entrée ou lie l'approbation à un événement local plus robuste. Cela peut être un compromis accepté pour des actions peu risquées, mais dites-le clairement.

Une approbation par appel doit résister davantage. Si l'action utilise un identifiant capable de modifier des données, de publier une version ou d'atteindre un hôte de production, un simple bouton est une preuve trop faible. Demandez Touch ID ou un autre signal local médié par le système. Le test devient alors : l'assistant peut-il faire apparaître l'invite, invoquer tous les contrôles accessibles autour d'elle et néanmoins échouer à terminer l'action protégée sans authentification de la personne ? C'est une propriété de sécurité bien plus nette.

Ne signalez pas simplement « bloqué » parce que le bouton n'a pas répondu. Décrivez toute la chaîne : l'assistant a-t-il trouvé la carte, a-t-il invoqué le contrôle, l'application a-t-elle enregistré une décision, le sous-système d'autorisation a-t-il émis un jeton et l'exécuteur de l'action a-t-il démarré ? L'assistant peut échouer à appuyer sur le bouton aujourd'hui, tandis qu'un autre chemin clavier réussira demain. Le jeton de décision est la frontière qui compte.

Le détournement du focus peut transformer un clic honnête en mauvaise décision

Les clics scriptés directs attirent l'attention parce qu'ils semblent malveillants. Le détournement du focus est souvent un échec plus réaliste, car il peut transformer un geste humain authentique en approbation d'une autre demande.

La documentation AppKit d'Apple indique clairement que l'activation d'une application est une demande et non une garantie, et que l'état d'activation peut changer lorsque macOS gère le bureau. Apple fournit aussi des API qui lancent ou ouvrent des applications avec un comportement d'activation. Le code d'approbation doit donc traiter l'état au premier plan comme un événement qu'il observe et vérifie, et non comme un fait permanent supposé au moment où la carte a été dessinée.

Testez volontairement la course. Affichez une carte d'approbation inoffensive avec un nonce unique. Placez le pointeur au-dessus du contrôle de confirmation sans cliquer. Demandez à votre assistant contrôlé d'activer une seconde application de test ou d'afficher une fenêtre de test anodine. Effectuez ensuite le clic prévu selon le même calendrier, dans des essais répétés. Enregistrez l'application active au moment de l'appui et du relâchement de la souris, la fenêtre qui possédait l'élément ayant le focus et le démarrage ou non de l'action protégée.

N'acceptez pas « la carte est restée visible » comme résultat positif. Une carte visible peut être inactive, se trouver derrière une autre fenêtre ou rester dessinée alors que le focus clavier a changé. Le chemin d'approbation doit vérifier à nouveau que la demande actuelle possède toujours la carte affichée et que l'application est active au moment où elle consomme l'approbation.

Un ensemble solide de tests de détournement du focus comprend les cas suivants :

L'expression « exiger une nouvelle interaction » est importante. Rétablir automatiquement le focus et accepter le clic initial après une brève interruption est dangereux. La personne peut croire que le clic a simplement fermé l'interruption, tandis que votre application le traite comme une approbation. Retirez la décision en attente ou réinitialisez-la visiblement. La personne doit lancer une nouvelle confirmation après le retour incontestable de votre application au premier plan.

Ne résolvez pas ce problème en forçant agressivement votre application au premier plan. Vous en créeriez un autre : un comportement surprenant au premier plan habitue les personnes à cliquer pour le faire disparaître. La carte doit apparaître clairement lorsqu'une demande arrive, mais elle ne doit pas engager une guerre du focus avec le bureau. Si elle perd son activation au mauvais moment, elle peut échouer de manière sûre et demander une nouvelle confirmation.

Les cartes périmées et les échanges de demandes méritent leurs propres cas d'attaque

Une carte peut résister à un clic synthétique direct tout en autorisant la mauvaise action. Cela se produit lorsque l'interface représente une demande alors que le serveur est déjà passé à une autre.

La version habituelle est un problème de nouvelle tentative. Un agent demande un appel HTTP. La carte apparaît. L'agent se déconnecte, se reconnecte et envoie une seconde demande avec des en-têtes légèrement différents. L'interface réutilise la carte existante parce qu'elle semble similaire. Un clic sur ce que la personne croit être la demande A libère la demande B. Le texte d'identité peut être parfait et l'approbation rester incorrecte.

Liez l'approbation à un condensat immuable de la demande. Incluez le type d'opération, la destination, l'identité ou l'alias de l'identifiant, les détails pertinents de la cible, l'identité du processus agent et le nonce. Lorsqu'un champ protégé change, invalidez la carte actuelle. Ne mettez pas l'intitulé à jour sur place en conservant un contrôle Approuver déjà prêt. Remplacez la génération de la demande et rendez l'ancienne instance d'interface incapable de terminer quoi que ce soit.

Pour un dispositif de test, envoyez deux demandes à la suite :

A: POST staging.example.invalid/echo
   header X-Test-Nonce: alpha-4d8f

B: POST staging.example.invalid/echo
   header X-Test-Nonce: bravo-7a21

Laissez la carte de la demande A visible assez longtemps pour que l'opérateur puisse l'identifier. Envoyez ensuite B par le même processus agent. Tentez la confirmation avec la souris, le clavier, une action d'accessibilité et après un changement de focus. Les seules réussites acceptables sont les suivantes : A s'exécute avec alpha-4d8f, B s'exécute après sa propre approbation avec bravo-7a21, ou aucune ne s'exécute. Si la carte visible de A libère B, considérez cela comme un défaut d'autorisation bloquant la mise en production.

Faites de même pour une modification de cible qui paraît anodine à une personne pressée. Une action SSH peut conserver la commande tout en changeant d'hôte. Une action HTTP peut conserver l'hôte tout en changeant le chemin ou l'identifiant injecté. Votre carte n'a pas besoin d'imprimer chaque octet de la demande, mais elle doit afficher les détails qui distinguent la décision de sécurité. Le serveur doit lier la demande canonique complète, et pas seulement les détails que vous avez choisi d'afficher.

Les tests d'expiration sont également importants. Ne faites pas défiler un compte à rebours pour la seule apparence. Lorsqu'une demande expire, révoquez le chemin d'autorisation serveur de cette génération. Testez ensuite une action d'accessibilité déclenchée exactement à la limite d'expiration et un relâchement de souris qui arrive juste après. Le résultat attendu est un refus dont la raison indique si l'expiration, la perte du focus, l'incompatibilité de génération ou l'échec d'autorisation l'a arrêté.

Vos journaux doivent trancher le débat une fois l'enregistrement d'écran terminé

Les tests d'approbation deviennent des débats lorsque la seule preuve est « j'ai cliqué et ça a marché ». Il vous faut des enregistrements qui permettent à un autre ingénieur de reconstituer la chaîne causale sans devoir faire confiance à l'interprétation du testeur.

Enregistrez deux flux liés : l'exécution de l'agent et chaque appel protégé. Le premier indique qui a lancé le travail et si cette session a ensuite été révoquée. Le second décrit précisément l'action demandée, la résolution de l'approbation et le début ou non de l'exécution. Conservez les événements d'approbation dans la même chronologie d'audit ordonnée que la création de la demande, les transitions de focus, les résultats d'autorisation et l'exécution.

Sallyport conserve un journal Sessions pour les exécutions d'agents et un journal Activity pour les appels individuels, tous deux générés à partir d'un journal d'audit chiffré et chaîné par hachage. Sa commande sp audit verify vérifie cette chaîne hors ligne sur le texte chiffré, sans nécessiter de clé de coffre. L'équipe de test dispose ainsi d'un contrôle d'intégrité des preuves, plutôt que d'un export modifiable que quelqu'un pourrait discrètement changer après un résultat surprenant.

Pour chaque essai d'équipe rouge, exportez ou conservez ensemble les éléments suivants :

• Le nom du cas de test et la matrice des autorisations.
• L'identité du processus demandeur et son autorité de signature.
• Le condensat de la demande, le nonce visible et la génération de la demande.
• La méthode de décision, le résultat de la décision et la raison du refus s'il y en a un.
• Le premier événement d'exécution, ou la preuve explicite qu'aucun événement d'exécution n'existe.

Les chaînes de hachage ne prouvent pas que la politique d'approbation est correcte. Elles prouvent quelque chose de plus limité, mais toujours utile : après l'écriture du journal, un enquêteur peut vérifier si l'enregistrement a été modifié ou réordonné. Le test de la politique fournit l'autre moitié en montrant quels événements l'application laisse atteindre l'exécution.

Faites de la revue des journaux un critère de réussite du test. Un essai qui bloque correctement une action mais n'enregistre que « annulé » n'est pas terminé. Vous devez distinguer une invocation d'accessibilité synthétique d'une annulation par la personne, une génération obsolète d'une demande expirée et un refus dû à la perte du focus d'un plantage de l'application. Ces distinctions transforment un rapport de défaut en une famille de tests de régression.

Réussir signifie que l'action est restée derrière la décision humaine

Ne prétendez pas qu'une surface d'approbation est sûre parce que votre premier script d'automatisation a échoué. Un bon résultat d'équipe rouge possède une portée réduite et exacte : sur un Mac contrôlé, avec des autorisations définies, chaque activation synthétique et chaque chemin d'interférence du focus testés n'ont produit ni jeton d'autorisation valide ni démarrage de l'action protégée.

Les tests les plus solides vous laissent une liste d'exceptions inconfortable mais utile. Peut-être que l'approbation de session permet un simple clic, parce que le risque est faible et que la personne a déjà approuvé le processus agent. Peut-être que l'approbation par appel exige Touch ID pour certaines clés. Peut-être qu'une carte s'annule chaque fois que l'application perd son activation, ce qui gêne quelques personnes mais empêche une course de focus. Inscrivez ces décisions dans le comportement du produit et testez-les. Une sécurité qui n'existe que dans une réunion de conception ne survivra pas à un bureau rempli d'assistants.

Exécutez cette suite chaque fois que vous modifiez l'affichage de l'approbation, ajoutez un nouveau canal d'action, changez la gestion de l'identité des processus ou refactorisez le code qui passe de la décision d'interface à l'exécution. La régression importante ne se présentera pas sous le nom « contournement de l'accessibilité ». Elle arrivera comme un nettoyage anodin qui déplace un rappel, réutilise une fenêtre ou considère une ancienne demande comme équivalente à une nouvelle.

Gardez l'assertion finale directe : l'action protégée ne commence qu'après que la demande actuelle a reçu l'autorisation locale requise. Si un chemin d'automatisation de l'interface peut rendre cette assertion fausse, la carte d'approbation n'est qu'un décor jusqu'à sa correction.