Kann ein macOS-UI-Automatisierungstest eine Agent-Freigabe umgehen?

Eine Freigabekarte ist nur dann eine Sicherheitskontrolle, wenn die Person und nicht ein anderer Prozess die Freigabe auslöst. Das klingt selbstverständlich, bis die Karte auf einem normalen macOS-Desktop erscheint. Clients für Bedienungshilfen können Steuerelemente untersuchen, Automatisierungswerkzeuge können Apps aktivieren und jedes Fenster im Vordergrund kann um den nächsten Klick konkurrieren.

Teste deshalb nicht, ob eine Karte modal aussieht oder ob ihre Schaltfläche beruhigend beschriftet ist. Prüfe, ob ein Prozess mit realistischen lokalen Berechtigungen eine geschützte Aktion auslösen kann, ohne dass die vorgesehene Person eine bewusste und informierte Entscheidung trifft. Das Ergebnis sollte kein spektakuläres Exploit-Video sein, sondern eine wiederholbare Antwort auf eine engere Frage: Welche Eingabepfade können die Freigabegrenze überschreiten, unter welchen Berechtigungen und welche Belege beweisen das Ergebnis?

Das ist ein Red-Team-Test für Software, die dir gehört, auf einem Mac und in einem Konto, die du kontrollierst. Halte die angeforderte Aktion harmlos. Verwende einen Dummy-HTTP-Endpunkt, einen SSH-Host außerhalb der Produktion oder eine Aktion, die einen festen Testwert zurückgibt. Ein Sicherheitstest, der versehentlich Geld ausgeben, Daten löschen oder den Produktionszugang ändern kann, ist bereits schlecht abgegrenzt, bevor jemand ein Skript schreibt.

Die Berechtigung für Bedienungshilfen verändert das Angreifermodell

Ein Prozess mit der Berechtigung für Bedienungshilfen ist kein gewöhnlicher Hintergrundprozess. Apple beschreibt den Zugriff auf Bedienungshilfen als Möglichkeit für Apps, einen Mac zu steuern. macOS verlangt, dass die Person diesen Zugriff in den Einstellungen für Datenschutz und Sicherheit gewährt. Die Berechtigung für Automation beschreibt Apple getrennt als Erlaubnis, auf andere Apps zuzugreifen und sie zu steuern. Es sind unterschiedliche Berechtigungen, aber beide gehören in das Bedrohungsmodell, wenn eine Freigabekarte auf dem Desktop liegt.

Teams verwischen regelmäßig eine wichtige Unterscheidung: Eine Freigabeoberfläche darf zugänglich sein, ohne jede von einem Bedienungshilfen-Client ausgelöste Aktion als Beleg für menschliche Absicht zu behandeln. Bedienungshilfen müssen sinnvolle Beschriftungen, Rollen, Zustandsänderungen und Fokusinformationen bereitstellen, damit Menschen mit assistiven Technologien die Anwendung bedienen können. Das ist eine Anforderung an Inklusion. Daraus folgt nicht, dass die Anwendung einem fremden Prozess erlauben muss, eine irreversible Bestätigung ohne ein lokales Signal der Person auszulösen.

Beginne den Test, indem du den Angreifer beschreibst, den du tatsächlich simulierst. Vermeide die ungenaue Bezeichnung «Malware». Sie verschleiert die Berechtigungen, die über das Ergebnis entscheiden. Ein sinnvoller Ausgangspunkt ist ein lokal laufender, signierter Helfer unter demselben angemeldeten Benutzer, der bereits die Berechtigung für Bedienungshilfen erhalten hat. Eine stärkere Variante besitzt zusätzlich die Automation-Berechtigung und kann die Aktivierung einer Anwendung anfordern. Keine der beiden Varianten erhält Administratorzugang, umgeht die Bildschirmsperre oder verwendet eine veränderte Kopie der Freigabeanwendung.

Diese Grenze macht den Test fair. Wenn dein Ergebnis lautet: «Ein Angreifer mit vollständiger Kontrolle über das Benutzerkonto kann das Benutzerkonto kontrollieren», hast du nichts gelernt. Lautet es dagegen: «Ein Helfer mit denselben Berechtigungen, die ein Benutzer einem Fenstermanager, Test-Runner, Makrotool oder assistiven Hilfsprogramm gewähren könnte, kann eine Zugangsdatenverwendung freigeben», hast du ein Designproblem mit einem klaren Lösungsweg gefunden.

Erstelle vor dem ersten Durchlauf eine Übersicht der Fähigkeiten:

Gewähre keine Berechtigung nur, weil ein Testwerkzeug danach fragt. Jede zusätzliche Berechtigung verändert die Aussage, die du anschließend treffen kannst. Notiere die genaue Kombination im Ergebnistitel, etwa «Helfer nur mit Bedienungshilfen kann die Freigabe pro Aufruf nicht bestätigen» statt «Freigaben sind sicher». Die zweite Aussage hält einer anderen Desktop-Konfiguration nicht stand.

Erfasse außerdem die Bundle-ID des Helfers, die Codesignatur, die Prozess-ID, den übergeordneten Prozess und den Startpfad. Ein gutes Freigabesystem sollte genug Prozessidentität anzeigen, damit eine Person die Anfrage beurteilen kann. Dein Testprotokoll braucht jedoch mehr Details, als auf einer Karte sinnvoll angezeigt werden können. Die Testperson muss klären können, ob ein Kindprozess einen vertrauenswürdig wirkenden Elternprozess geerbt hat, ob ein Terminal-Wrapper den Helfer gestartet hat und ob ein Neustart eine neue Prozessidentität erzeugt hat.

Eine anklickbare Schaltfläche beweist keine schwache Freigabe

Eine Schaltfläche in der macOS-Bedienungshierarchie ist nicht automatisch eine Schwachstelle. AppKit erwartet, dass Bedienungselemente an dieser Hierarchie teilnehmen, damit assistive Clients ein funktionierendes Steuerelement finden können. Apple dokumentiert, dass Steuerelemente Eigenschaften wie Beschriftungen, Titel, Rahmen und ihren Aktivierungsstatus bereitstellen.

Das schwache Design ist eines, bei dem das Auslösen dieser sichtbaren Schaltfläche als ausreichender Beleg für eine sensible Aktion gilt. Dadurch wird eine synthetische Bedienungshilfen-Aktion von einem bewussten Klick ununterscheidbar. Außerdem bleibt der Fehler leicht unbemerkt: Das Team testet mit einer Maus, sieht den erwarteten Callback und fragt nie, was denselben Callback noch auslösen kann.

Mache die Freigabeentscheidung von einem lokalen Autorisierungsereignis abhängig und nicht nur vom Action-Handler der Schaltfläche. Das Steuerelement kann die Anfrage starten, aber die geschützte Aktion sollte auf ein Autorisierungsergebnis warten, das festhält, wie die Bestätigung zustande kam. Bei einer normalen Sitzungsfreigabe kann das ein bewusster Klick sein, nachdem die Anwendung geprüft hat, dass ihre eigene Freigabeoberfläche aktiv und aktuell ist. Für eine risikoreiche Aktion solltest du ein systemvermitteltes lokales Authentifizierungsereignis verlangen, zum Beispiel Touch ID, sofern verfügbar.

Mache nicht den typischen Fehler, die Schaltfläche «Freigeben» im Baum der Bedienungshilfen zu verstecken oder umzubenennen. Das bestraft Menschen, die assistive Technologien benötigen, und hilft wenig gegen einen fähigen lokalen Angreifer, der den Fokus weiterhin manipulieren oder alternative Pfade auslösen kann. Teste stattdessen, ob die Bestätigungskette einen synthetischen Pfad, eine veraltete Karte, eine inaktive Karte und eine Anfrage ablehnt, deren angezeigte Details nicht mehr zu der unmittelbar bevorstehenden Aktion passen.

Ein nützlicher interner Entscheidungsdatensatz sieht so aus:

{
  "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
}

Wichtiger als die Feldnamen ist die Trennung. decision sagt, was passiert ist. decision_method sagt, wie es passiert ist. Die Generationswerte verhindern, dass eine alte Karte nach einer Neudarstellung, Wiederholung oder Aktionsänderung eine neue Anfrage freigibt. Die Aktivierungsfelder halten fest, ob die Person zum Entscheidungszeitpunkt deine Karte sehen konnte. Mit dem letzten Feld lässt sich die Reihenfolge der Vorgänge prüfen.

Diese Trennung deckt auch einen subtilen Implementierungsfehler auf: Eine Freigabe wird früh akzeptiert und die Karte erst danach pro forma angezeigt. Bei diesem Fehler bestehen alle visuellen Tests. Die geschützte Aktion hat bereits begonnen, die Karte liefert also nur noch Theater statt Kontrolle. Der Aktionsausführer sollte ein Entscheidungstoken verlangen, das ausschließlich das Freigabesystem nach Abschluss der relevanten Prüfungen erzeugt.

Das Testsystem sollte harmlose, vergleichbare Durchläufe erzeugen

Baue eine Testvorrichtung, die eine vorhersehbare Freigabeanfrage erstellt, und einen Beobachter, der Belege sammelt. Beginne nicht mit einem allgemeinen Desktop-Automatisierungsframework, das auf echte Zugangsdaten zeigt. Ein Testsystem sollte Unklarheit verringern und nicht vergrößern.

Deine Testvorrichtung braucht eine Anfrage mit stabiler Kennung, sichtbaren Details, die sich pro Durchlauf ändern, kurzer Gültigkeit und einem harmlosen Abschluss. Lass die geschützte Aktion zum Beispiel einen lokalen Endpunkt aufrufen, der erst nach der Freigabe approved:test-4d8f zurückgibt. Wenn die Aktion ohne gültigen Freigabedatensatz erfolgreich ist, liegt ein klarer Fehler vor. Bei einem Timeout oder einer Ablehnung hast du ein eindeutiges Ergebnis ohne Freigabe.

Verwende eine kurzlebige Nonce sowohl in der Karte als auch in der geschützten Anfrage. Eine Freigabekarte mit der alleinigen Aussage «Agent-Zugriff erlauben?» kann keinen Fehler mit einem veralteten Fenster aufdecken. Eine Karte mit «Testanfrage 4d8f den Aufruf des Staging-Echo-Dienstes erlauben?» schon. Ändere die Nonce bei jedem Durchlauf und prüfe anschließend, ob das Aktionsergebnis dieselbe Nonce enthält.

Halte in den Belegen drei unabhängige Zeitpunkte fest:

1. Den Zeitpunkt der Anfrageerstellung.
2. Den Zeitpunkt der Entscheidung.
3. Den Zeitpunkt, an dem die geschützte Aktion begonnen hat.

Verwende innerhalb der Anwendung möglichst monotone Zeit. Die Uhrzeit ist für eine menschliche Zeitleiste nützlich, kann sich aber durch Zeitsynchronisierung, Ruhezustand oder manuelle Änderungen verschieben. Die Reihenfolge ist einfach: Die Aktion darf erst nach einer gültigen Entscheidung für dieselbe Anfragegeneration beginnen. Ein Screenshot kann diese Reihenfolge nicht beweisen.

Dein Beobachter sollte die aktive Anwendung, das fokussierte Fenster, die sichtbare Anfrage-ID der Freigabekarte und das spätere Aktionsergebnis erfassen. Eine Bildschirmaufnahme hilft bei der Diagnose überraschenden Verhaltens, ersetzt aber keine strukturierten Ereignisse. Bildschirmaufnahmen enthalten keine Prozesskennungen, verschlucken schnelle Übergänge und verbergen das entscheidende Ereignis oft hinter einer Zeigerbewegung.

Verwende für jeden Versuch einen Testdatensatz wie diesen:

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

Der Wert attempt sollte den Mechanismus beschreiben und nicht das gewünschte Ergebnis. Schreibe activate-then-click, stale-window, keyboard-focus-shift oder voiceover-navigation statt attack-1. Sechs Wochen später bewahrt dich diese klare Beschreibung davor, den falschen Fall erneut auszuführen.

Führe dieselbe Vorrichtung zuerst ohne Berechtigungen für den Helfer aus. Das ist dein Kontrolllauf. Aktiviere danach jeweils nur eine Fähigkeit. Ein Red-Team-Ergebnis ohne Kontrolllauf lässt jeden Fehler schwer interpretierbar werden. Vielleicht war deine Karte nie per Tastatur erreichbar. Vielleicht ist der Endpunkt ausgefallen. Vielleicht fehlte dem Testhelfer die Berechtigung, von der du dachtest, dass er sie besitzt. Der Kontrolllauf macht diese Erklärungen als sichtbare Unterschiede erkennbar.

Synthetische Freigaben testen, ohne ein Exploit-Kit zu bauen

In diesem Fall soll festgestellt werden, ob ein berechtigter Bedienungshilfen-Client das Freigabesteuerelement auslösen und dadurch die geschützte Aktion starten kann. Du brauchst dafür keinen öffentlich einsetzbaren Klicker und keine Sammlung fragiler Koordinatenskripte.

Verwende deinen eigenen Testhelfer mit einer eng begrenzten Aufgabe: Er soll das Testfenster anhand der Anwendungsidentität und der nur für Tests verwendeten Anfrage-Nonce finden, dieselbe semantische Aktion anfordern wie ein Bedienungshilfen-Client und anschließend melden, ob die geschützte Aktion abgeschlossen wurde. Durchsuche nicht jedes Fenster des Desktops. Ziele nicht auf Dialoge von Drittanbietern. Speichere keine Zugangsdaten und interagiere nicht mit echten Dienstkonten.

Teste diese Pfade getrennt, weil sie unterschiedliche Aussagen liefern:

• Eine semantische Bedienungshilfen-Auslösung des Steuerelements «Freigeben».
• Tastaturnavigation, die auf «Freigeben» landet, gefolgt von einer synthetischen Aktivierung.
• Eine Zeigeraktion, nachdem der Helfer die Freigabeanwendung in den Vordergrund geholt hat.
• Eine Zeigeraktion, ohne dass der Helfer sie in den Vordergrund holt.
• Eine verzögerte Aktion, nachdem die Karte abgelaufen oder die Anfrage geändert worden ist.

Koordinatenklicks solltest du nur als Regressionstest für visuelle Überlagerungen behalten. Sie zeigen, ob ein Klick an einer Bildschirmposition nach einer Layoutänderung auf dem falschen Steuerelement landen kann. Sie zeigen nicht, ob ein fremder Prozess das gewünschte Element erkennen und aktivieren kann. Semantische UI-Automatisierung ist der stärkere Test für die Autorisierungslogik. Koordinaten sind der stärkere Test für Layout- und Fokusfehler.

Erwarte unterschiedliche Ergebnisse je nach Freigabemodus. Eine Sitzungsfreigabe soll normalerweise einen erkannten Agent-Prozess für die Lebensdauer dieses Prozesses autorisieren. Wenn deine Sitzungsfreigabe einen einfachen Klick akzeptiert, kann ein Helfer mit Bedienungshilfen-Berechtigung ihn möglicherweise nachahmen, sofern die App den Eingabepfad nicht unterscheidet oder die Freigabe nicht an ein stärkeres lokales Ereignis bindet. Für risikoarme Aktionen kann das ein akzeptabler Kompromiss sein, aber benenne ihn offen.

Eine Freigabe pro Aufruf sollte mehr aushalten. Wenn die Aktion eine Berechtigung verwendet, mit der Daten geändert, eine Veröffentlichung vorgenommen oder ein Produktionshost erreicht werden kann, ist ein einfacher Tastendruck zu wenig. Verlange Touch ID oder ein anderes systemvermitteltes lokales Authentifizierungssignal. Die Testfrage lautet dann: Kann der Helfer den Dialog anzeigen, jedes zugängliche Steuerelement in seiner Umgebung auslösen und die geschützte Aktion trotzdem nicht abschließen, solange die Person sich nicht authentifiziert? Das ist eine deutlich sauberere Sicherheitseigenschaft.

Melde nicht einfach «blockiert», nur weil die Schaltfläche nicht reagiert hat. Berichte die vollständige Kette: Hat der Helfer die Karte gefunden? Hat er das Steuerelement ausgelöst? Hat die App eine Entscheidung protokolliert? Hat das Autorisierungssystem ein Token ausgestellt? Hat der Aktionsausführer begonnen? Ein Helfer kann heute daran scheitern, die Schaltfläche zu betätigen, während morgen ein alternativer Tastaturpfad funktioniert. Das Entscheidungstoken ist die relevante Grenze.

Fokusdiebstahl kann einen ehrlichen Klick in die falsche Entscheidung verwandeln

Direktes skriptgesteuertes Klicken erhält Aufmerksamkeit, weil es bösartig aussieht. Fokusdiebstahl ist oft der realistischere Fehler, weil dadurch eine echte Benutzergeste die Freigabe einer anderen Anfrage auslösen kann.

Die AppKit-Dokumentation von Apple macht deutlich, dass die Aktivierung einer Anwendung eine Anfrage und keine Garantie ist. Auch der Aktivierungsstatus kann sich ändern, während macOS den Desktop verwaltet. Apple stellt außerdem APIs bereit, die Anwendungen mit Aktivierungsverhalten starten oder öffnen. Deshalb muss Freigabecode den Status im Vordergrund als Ereignis behandeln, das er beobachtet und überprüft, nicht als dauerhafte Tatsache, die beim Zeichnen der Karte angenommen wurde.

Teste den Wettlauf absichtlich. Zeige eine harmlose Freigabekarte mit eindeutiger Nonce an. Bewege den Zeiger über das Bestätigungssteuerelement, ohne zu klicken. Lass deinen kontrollierten Helfer eine zweite Testanwendung aktivieren oder ein harmloses Testfenster anzeigen. Führe danach den vorgesehenen Klick wiederholt zum gleichen Zeitpunkt aus. Erfasse, welche Anwendung bei mouse-down und mouse-up aktiv war, welches Fenster das fokussierte Element besaß und ob die geschützte Aktion begonnen hat.

Akzeptiere «Die Karte war sichtbar» nicht als bestanden. Eine sichtbare Karte kann inaktiv sein. Sie kann hinter einem anderen Fenster liegen. Ihre Steuerelemente können weiterhin gezeichnet werden, während der Tastaturfokus woanders liegt. Der Freigabepfad sollte erneut prüfen, ob die aktuelle Anfrage weiterhin die angezeigte Karte besitzt und ob die App aktiv ist, wenn sie die Freigabe übernimmt.

Ein guter Testsatz für Fokusdiebstahl enthält diese Fälle:

Die Formulierung «eine neue Interaktion verlangen» ist wichtig. Den Fokus automatisch wiederherzustellen und den ursprünglichen Klick nach einer kurzen Unterbrechung zu akzeptieren, ist gefährlich. Die Person glaubt vielleicht, der Klick habe die Unterbrechung beendet, während deine Anwendung ihn als Freigabe behandelt. Ziehe die ausstehende Entscheidung zurück oder setze sie sichtbar zurück. Die Person muss eine neue Bestätigung auslösen, sobald deine App zweifellos wieder aktiv ist.

Löse das nicht, indem du deine App aggressiv in den Vordergrund zwingst. Das schafft ein anderes Problem: Überraschendes Verhalten im Vordergrund bringt Menschen dazu, es einfach wegzuklicken. Die Karte sollte bei Eingang einer Anfrage deutlich erscheinen, aber keinen Fokuskrieg mit dem Desktop führen. Wenn sie im falschen Moment die Aktivierung verliert, kann sie sicher ablehnen und erneut fragen.

Veraltete Karten und ausgetauschte Anfragen brauchen eigene Angriffsfälle

Eine Karte kann einen direkten synthetischen Klick abwehren und trotzdem die falsche Aktion autorisieren. Das passiert, wenn die Oberfläche eine Anfrage darstellt, während das Backend bereits zu einer anderen weitergegangen ist.

Die bekannte Variante ist ein Fehler bei Wiederholungen. Ein Agent fordert einen HTTP-Aufruf an. Die Karte erscheint. Der Agent trennt die Verbindung, verbindet sich erneut und sendet eine zweite Anfrage mit leicht veränderten Headern. Die Oberfläche verwendet die vorhandene Karte wieder, weil sie ähnlich aussieht. Ein Klick auf das, was die Person für Anfrage A hält, gibt Anfrage B frei. Der Identitätstext kann perfekt sein und die Freigabe trotzdem falsch.

Binde die Freigabe an einen unveränderlichen Anfrage-Digest. Nimm den Operationstyp, das Ziel, die Identität oder den Alias der Berechtigung, relevante Zieldetails, die Identität des Agent-Prozesses und die Nonce auf. Sobald sich ein geschütztes Feld ändert, muss die aktuelle Karte ungültig werden. Aktualisiere nicht einfach die Beschriftung und behalte ein bereits bereites «Freigeben»-Steuerelement. Ersetze die Anfragegeneration und mache die vorherige UI-Instanz unfähig, irgendetwas abzuschließen.

Sende für eine Testvorrichtung zwei Anfragen in kurzer Folge:

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

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

Lass die Karte von Anfrage A lange genug sichtbar, damit die Testperson sie erkennen kann. Sende anschließend B über denselben Agent-Prozess. Versuche die Bestätigung per Maus, Tastatur, Bedienungshilfen-Aktion und nach einem Fokuswechsel. Die einzigen akzeptablen Abschlüsse sind: A wird mit alpha-4d8f abgeschlossen, B wird nach einer eigenen neuen Freigabe mit bravo-7a21 abgeschlossen oder keine der beiden Anfragen wird abgeschlossen. Wenn die sichtbare Karte von A B freigibt, ist das ein blockierender Autorisierungsfehler.

Führe denselben Test mit einer Änderung des Ziels durch, die einer eiligen Person harmlos erscheinen könnte. Eine SSH-Aktion kann den Befehl beibehalten und trotzdem den Host ändern. Eine HTTP-Aktion kann den Host beibehalten und trotzdem den Pfad oder die eingesetzte Berechtigung ändern. Die Karte muss nicht jedes Byte einer Anfrage anzeigen, aber sie muss die Details zeigen, die die Sicherheitsentscheidung unterscheiden. Das Backend muss die vollständige kanonische Anfrage binden und nicht nur die Details, die du anzeigen möchtest.

Auch Ablaufprüfungen sind hier wichtig. Lass die Anfrage nicht nur aus optischen Gründen herunterzählen. Wenn sie abläuft, muss der Backend-Autorisierungspfad für diese Anfragegeneration widerrufen werden. Teste anschließend eine Bedienungshilfen-Aktion genau an der Ablaufgrenze und ein mouse-up, das knapp nach dem Ablauf eintrifft. Das erwartete Ergebnis ist eine Ablehnung mit einem Grund, der erkennen lässt, ob Ablauf, Fokusverlust, Generationsabweichung oder Autorisierungsfehler die Aktion gestoppt hat.

Deine Logs müssen die Diskussion beenden, wenn die Bildschirmaufnahme vorbei ist

Freigabetests werden zu Streitfragen, wenn der einzige Beleg lautet: «Ich habe geklickt und es hat funktioniert.» Du brauchst Datensätze, mit denen eine andere Person die Kausalkette rekonstruieren kann, ohne der Interpretation der Testperson vertrauen zu müssen.

Protokolliere zwei zusammengehörige Datenströme: den Agent-Lauf und den einzelnen geschützten Aufruf. Der Laufdatensatz beantwortet, wer die Arbeit begonnen hat und ob der Lauf später widerrufen wurde. Der Aufrufdatensatz beantwortet genau, welche Aktion angefordert wurde, wie die Freigabe aufgelöst wurde und ob die Ausführung begonnen hat. Halte die Freigabeereignisse in derselben geordneten Audit-Geschichte wie Anfrageerstellung, Fokuswechsel, Autorisierungsergebnisse und Ausführung.

Sallyport führt ein Sitzungsjournal für Agent-Läufe und ein Aktivitätsjournal für einzelne Aufrufe. Beide werden aus einem verschlüsselten, hashverketteten Audit-Log erzeugt. Der Befehl sp audit verify prüft diese Kette offline über den Chiffretext, ohne einen Tresorschlüssel zu benötigen. So erhält das Testteam eine Integritätsprüfung der Belege statt eines veränderbaren Exports, den jemand nach einem überraschenden Ergebnis unbemerkt bearbeiten kann.

Bewahre bei jedem Red-Team-Lauf diese Fakten gemeinsam auf:

• Den Namen des Testfalls und die Berechtigungsmatrix.
• Die Identität des anfordernden Prozesses und seine Codesignatur.
• Den Anfrage-Digest, die sichtbare Nonce und die Anfragegeneration.
• Die Entscheidungsmethode, das Entscheidungsergebnis und bei einer Ablehnung den Grund.
• Das erste Ausführungsereignis oder einen eindeutigen Beleg, dass kein Ausführungsereignis existiert.

Hashketten beweisen nicht, dass die Freigaberichtlinie korrekt ist. Sie beweisen etwas Engeres, aber weiterhin Nützliches: Nach dem Schreiben des Logs kann eine untersuchende Person prüfen, ob der Datensatz verändert oder umgeordnet wurde. Der Richtlinientest liefert die andere Hälfte, indem er zeigt, welche Ereignisse die Anwendung bis zur Ausführung gelangen lässt.

Mache die Logprüfung zu einem Kriterium für einen bestandenen Test. Ein Lauf, der eine Aktion korrekt blockiert, aber nur «abgebrochen» protokolliert, ist nicht abgeschlossen. Du musst eine synthetische Bedienungshilfen-Auslösung von einem Abbruch durch die Person, eine veraltete Generation von einer abgelaufenen Anfrage und eine Ablehnung wegen Fokusverlust von einem App-Absturz unterscheiden können. Diese Unterschiede verwandeln einen einzelnen Fehlerbericht in eine Reihe von Regressionstests.

Bestanden ist der Test, wenn die Aktion hinter der menschlichen Entscheidung bleibt

Behaupte nicht, eine Freigabeoberfläche sei sicher, nur weil dein erstes Automatisierungsskript gescheitert ist. Ein gutes Red-Team-Ergebnis hat einen kleinen, exakten Geltungsbereich: Auf einem kontrollierten Mac und mit festgelegten Berechtigungen konnte jede getestete synthetische Aktivierung und jeder getestete Pfad zur Fokusstörung weder ein gültiges Autorisierungstoken erzeugen noch die geschützte Aktion starten.

Die stärksten Tests hinterlassen eine unbequeme, aber nützliche Liste von Ausnahmen. Vielleicht erlaubt die Sitzungsfreigabe einen einfachen Klick, weil das Risiko gering ist und die Person den Agent-Prozess bereits freigegeben hat. Vielleicht verlangt die Freigabe pro Aufruf für ausgewählte Schlüssel Touch ID. Vielleicht bricht eine Karte jedes Mal ab, wenn die App ihre Aktivierung verliert. Das kann einige Menschen stören, verhindert aber einen Fokus-Wettlauf. Verankere diese Entscheidungen im Produktverhalten und teste sie. Sicherheit, die nur in einer Designbesprechung existiert, hält einem Desktop voller Helfer nicht stand.

Führe diese Testsuite aus, wenn du die Darstellung der Freigabe änderst, einen neuen Aktionskanal hinzufügst, die Behandlung der Prozessidentität änderst oder den Code für den Übergang von UI-Entscheidung zu Ausführung überarbeitest. Die relevante Regression wird sich nicht als «Umgehung der Bedienungshilfen» ankündigen. Sie kommt als harmlose Bereinigung, die einen Callback verschiebt, ein Fenster wiederverwendet oder eine alte Anfrage als gleichwertig zu einer neuen behandelt.

Die abschließende Aussage sollte klar sein: Die geschützte Aktion beginnt erst, nachdem die aktuelle Anfrage die erforderliche lokale Autorisierung erhalten hat. Wenn irgendein UI-Automatisierungspfad diese Aussage falsch werden lässt, ist die Freigabekarte bis zur Behebung nur Dekoration.