# Können API-Host-Aliasse Ihre Zielprüfung umgehen? Eine Zielprüfung hat nur dann einen Wert, wenn sie den Namen prüft, der die Zugangsdaten erhält. Wenn ein Team `https://api.example.test` freigibt, Agenten aber weiterhin `https://api-us.example.test`, `https://gateway.example.test` oder einen vom Anbieter bereitgestellten Kompatibilitätsendpunkt nutzen dürfen, beschreibt die Freigabe eine Absicht statt einer Grenze. Ich habe das auf die denkbar unspektakuläre Weise scheitern sehen: Jemand gibt einen vertrauten Hostnamen frei, eine Bereitstellungsvariable zeigt auf einen regionalen Alias, und dasselbe Bearer-Token funktioniert. Dafür brauchte niemand einen spektakulären Exploit. Das Team hatte schlicht mehr Zielnamen, als sein Prüfprozess zuließ. Die erste Korrektur betrifft das Konzept. Ein CNAME-Eintrag, eine alternative Basis-URL, eine Weiterleitung, eine IP-Adresse und eine HTTP-Autorität hängen zusammen, sind aber nicht austauschbar. Wer sie gleichsetzt, erhält Prüfungen, die sorgfältig aussehen, und Kontrollen, durch die Zugangsdaten entweichen. ## Eine Zielprüfung deckt nur den exakten Host ab Eine Prüfung von `api.example.test` gibt nicht `api-eu.example.test`, `proxy.example.test` oder `api.example.test.evil.invalid` frei. Zugangsdaten sollten nur an einen exakten, normalisierten Hostnamen gehen, der in einem ausdrücklichen Inventar für diese Zugangsdaten steht. Teams beginnen oft mit einer informellen Regel wie „Dieses Token ist für die API von Example.“ Das beschreibt Eigentümerschaft, nicht das Ziel. Ein Unternehmen kann viele Domains betreiben, ein Anbieter kann Datenverkehr hinter mehreren Namen verlagern, und ein Dritter kann einen Teil des Edge-Netzwerks eines Anbieters hosten. Der HTTP-Client braucht eine konkrete URL. Deine Kontrolle ebenfalls. Beschreibe die Grenze so, dass ein URL-Parser sie vergleichen kann: - Schema: normalerweise `https` - Hostname: kleingeschriebener ASCII-Hostname nach IDNA-Verarbeitung - Port: der ausdrücklich angegebene Port oder der Standardport des Schemas - Pfadrichtlinie: nur wenn die Zugangsdaten auf eine bestimmte API-Oberfläche begrenzt sind Ersetze die Hostnamenliste nicht durch einen Suffix-Test. `endsWith("example.test")` akzeptiert `notexample.test`. `endsWith(".example.test")` akzeptiert weiterhin jede heutige und künftige Subdomain. Das kann für ein internes Service-Mesh mit einem Verantwortlichen und strengen Vergabekontrollen vertretbar sein. Für Zugangsdaten, die Produktionsdaten verändern können, ist es meist nachlässig. Die unbequeme Frage lautet, ob ein Mensch jeden Hostnamen vor der Nutzung freigeben muss. Bei einem Token mit weitreichenden Rechten: ja. Bei einem Token mit geringem Umfang für einen Anbieter mit vielen veröffentlichten regionalen Endpunkten: Gib eine gepflegte Liste frei und behandle Ergänzungen als bewusste Änderung. Eine zusätzliche Prüfung kostet weniger, als erklären zu müssen, warum ein Token einen Hostnamen erreichte, den niemand erfasst hatte. Das trennt auch die Zielkontrolle von der Prüfung des Anfrageinhalts. Ein Prüfer kann einem `GET` an einen freigegebenen Host zustimmen und ein `POST` ablehnen, das Abrechnungen ändert. Das sind getrennte Fragen. Behaupte nicht, ein Hostname-Check entscheide, ob eine Anfrage sicher ist. Er entscheidet, wohin die Zugangsdaten gehen dürfen. ## CNAMEs ändern den Weg, nicht den HTTP-Host Ein CNAME ändert die DNS-Auflösung. Er schreibt nicht von sich aus den Hostnamen in der URL, den HTTP-Header `Host` oder die TLS-Server-Name-Indication um, die ein gewöhnlicher HTTPS-Client sendet. Angenommen, ein Agent ruft diese URL auf: ```text https://api.example.test/v1/orders ``` DNS kann antworten: ```text api.example.test. 300 IN CNAME api.edge.vendor.test. api.edge.vendor.test. 300 IN A 203.0.113.42 ``` Die TCP-Verbindung erreicht `203.0.113.42`, möglicherweise auf Infrastruktur des Anbieters. Der Client sollte TLS weiterhin für `api.example.test` anfordern und `Host: api.example.test` senden. Legt der Server kein für diesen ursprünglichen Namen gültiges Zertifikat vor, sollte die Zertifikatsprüfung fehlschlagen. Tut er es doch, ist der Server zumindest zu diesem Zeitpunkt berechtigt, Datenverkehr für diesen Namen zu terminieren. Dieser Unterschied ist wichtig, weil er eine beliebte, aber falsche Lösung widerlegt: das CNAME-Ziel freizugeben, als wäre es die API-Autorität. Der Zielname ist ein Hinweis auf den Datenweg. Er hilft zu verstehen, wohin der Verkehr läuft, ersetzt aber nicht die Prüfung des URL-Hostnamens, der den Autorisierungsheader erhält. RFC 1034 beschreibt einen CNAME als Alias für einen anderen Domainnamen und verlangt, die Auflösung beim kanonischen Namen fortzusetzen. Das erklärt das Verhalten des Resolvers, nicht die Entscheidung über HTTP-Zugangsdaten. DNS kennt weder Bearer-Tokens noch API-Berechtigungen oder deine Änderungsfreigabe. Ein CNAME wird in vier praktischen Fällen sicherheitsrelevant: 1. Der DNS-Name gehört einem anderen Team oder Anbieter, sodass eine Eintragsänderung beeinflussen kann, wo deine freigegebene Autorität terminiert. 2. Die aufgelöste Adresse führt in ein unerwartetes Netzwerk, etwa einen internen Bereich oder eine Cloud-Metadatenadresse. 3. Eine Kontrolle gibt Namen aus DNS-Ausgaben statt der URL-Autorität frei und lässt damit eine Aliasbeziehung als eigentliche Autorisierungsentscheidung gelten. 4. Die Anwendung erstellt aus dem aufgelösten Namen, einem Weiterleitungsziel oder einem Ergebnis der Diensterkennung eine zweite URL und leitet dann Zugangsdaten weiter. Der vierte Fall lässt Tokens entweichen. Die ersten drei schwächen die Prüfung und erhöhen die Wahrscheinlichkeit späterer Lecks. Sie brauchen unterschiedliche Tests und unterschiedliche Verantwortliche. Ein CNAME schützt auch nicht vor DNS-Rebinding. Löst ein Hostname, den dein Client zulässt, später zu einer anderen Adresse auf, kann der Client eine neue Verbindung zu dieser Adresse herstellen. Überwache bei Zielen unter deiner Kontrolle die Einträge und beschränke, wohin sie auflösen dürfen. Bei Zielen außerhalb deiner Kontrolle solltest du nicht annehmen, dass eine einmalige DNS-Auflösung dauerhafte Sicherheit belegt. ## Alternative Basis-URLs schaffen die unauffälligere Umgehung Alternative Basis-URLs sind die häufigere Umgehung, weil sie die HTTP-Autorität direkt ändern. Es sind die Namen, die sich in Umgebungsvariablen, SDK-Standardwerten, Test-Fixtures und Migrationshinweisen verbergen. Ein Dienst kann all diese Adressen aus guten Gründen dokumentieren: ```text https://api.example.test https://api-us.example.test https://sandbox-api.example.test https://gateway.example.test/service-a https://tenant-42.api.example.test ``` Heute können sie am selben Edge enden. Das heißt nicht, dass sie dieselben Zugangsdaten erhalten sollten. Der Produktionsendpunkt kann ein Token auf Kontoebene akzeptieren, der Sandbox-Endpunkt Anfragen in ein separates System senden, der Gateway-Pfad einen anderen Dienst auswählen und der Mandanten-Hostname nach Kundenidentität routen. Die Namen enthalten betriebliche Unterschiede, die ein IP-Vergleich verdeckt. Das Fehlermuster ist vorhersehbar. Eine Codebasis definiert `API_BASE_URL` mit einem Produktionsstandard. Ein Entwickler ändert ihn für einen regionalen Test oder eine Migration. Die Schicht zum Einfügen der Zugangsdaten sieht eine URL, die noch immer verwandt wirkt, und fügt den Header hinzu. Die Zielprüfung war an ein Etikett wie „Example API“ gebunden, nicht an die genaue Autorität, daher bemerkt niemand die Erweiterung. Korrigiere das Datenmodell, bevor du den Code korrigierst. Jede Zugangsdatenfolge braucht einen eigenen Eintrag mit vier Feldern, die Prüfer einsehen können: ```text credential: orders-write-prod allowed authorities: https://api.example.test:443 https://api-us.example.test:443 purpose: create and amend production orders owner: commerce operations review trigger: DNS change, new endpoint, scope change ``` Das Wort „Autoritäten“ ist bewusst gewählt. Speichere Schema, Host und Port gemeinsam. Ein Hostname, der über HTTPS in Ordnung ist, ist nicht automatisch über einen nicht standardmäßigen Port freigegeben. Ein Pfad kann wichtig sein, wenn ein gemeinsames Gateway einen Host für unabhängige APIs nutzt. Pfadregeln brauchen jedoch sorgfältige Normalisierung und sollten getrennte Zugangsdaten niemals ersetzen, wenn sich die Berechtigungsumfänge unterscheiden. Verlass dich nicht auf die veröffentlichte Liste eines Anbieters als fertiges Inventar. Die Anbieter-Dokumentation zeigt, was existieren kann. Dein Code und deine Bereitstellungseinstellungen zeigen, was du aufrufen kannst. Du brauchst beides, einschließlich der Namen, die nach einer Migration in alter Automatisierung zurückbleiben. ## Die Zielgruppe der Zugangsdaten ist die Grenze Die richtige Frage lautet nicht „Welche Server gehören zu diesem Anbieter?“, sondern „Welche HTTP-Autoritäten dürfen dieses genaue Geheimnis auf diesem genauen Anfrageweg erhalten?“ Ein Bearer-Token hat keine eingebaute Einschränkung auf eine Zielgruppe, sofern der Aussteller sie nicht durchsetzt. Sobald ein Client es in einen `Authorization`-Header setzt, kann jeder Empfänger dieses Headers versuchen, es zu nutzen. Bei Basic Authentication und benutzerdefinierten API-Key-Headern besteht dasselbe Transportproblem. Transportverschlüsselung schützt die Anfrage unterwegs, beschränkt aber nicht die Zielgruppe auf Anwendungsebene. OAuth-Access-Tokens enthalten manchmal einen `aud`-Claim. Das hilft dem Ressourcenserver, ein für jemand anderen bestimmtes Token abzulehnen. Verwechsle jedoch eine serverseitige Ablehnung nicht mit sicherem Clientverhalten. Ein Token an den falschen Hostnamen zu senden, legt es diesem Hostnamen offen und bringt es in dessen Zugriffsprotokolle, Telemetrie oder Incident-Queue. Ein abgelehntes Token ist besser als ein akzeptiertes, aber die Offenlegung bleibt vermeidbar. Die Bindung von Zugangsdaten hat zwei Teile: - Der Client fügt Zugangsdaten nur für eine geprüfte Autorität ein. - Der Aussteller der Zugangsdaten gibt ihnen den engstmöglichen praktischen Umfang, die engstmögliche Zielgruppe und Umgebung. Du brauchst beides. Die Host-Bindung verhindert, dass ein Clientfehler ein Geheimnis über benachbarte Dienste verteilt. Der Berechtigungsumfang begrenzt den Schaden, falls der erwartete Host, seine Protokolle oder seine Routing-Konfiguration kompromittiert wird. Deshalb ist ein einzelner organisationsweiter API-Schlüssel ein so schlechter Tausch. Er vereinfacht die Einrichtung und macht die Reaktion auf Vorfälle unerquicklich. Erreicht derselbe Schlüssel eine Zahlungs-API, einen Analytics-Collector und ein Staging-Gateway, kannst du den Zugriff auf ein Ziel nicht widerrufen, ohne alle drei zu stören. Getrennte Zugangsdaten machen aus einem Routingfehler eine begrenzte Rotation statt eines Ausfalls, der alle beschäftigt. ## Namen aus Code, DNS und Anbieter-Dokumentation erfassen Ein Inventar von Endpunkten wird glaubwürdig, wenn es beobachtete Nutzung statt nur geplanter Architektur erfasst. Erstelle es aus Code, Bereitstellungskonfiguration, DNS und Anbieter-Dokumentation und gleiche die Unterschiede ab. Beginne im Repository mit einer Suche nach URL-Schemata und Einstellungen für Basis-URLs. Beziehe Anwendungscode, Shell-Skripte, CI-Definitionen, Beispieldateien, Infrastrukturdefinitionen und Test-Fixtures ein. Erfasse jeden Hostnamen, auch Namen, die veraltet wirken. Alte Namen bleiben gefährlich, wenn ein Cron-Job oder Agenten-Prompt sie noch aufruft. Löse dann jeden Kandidaten über denselben Resolver-Kontext auf, den die aufrufende Maschine verwendet. Unter macOS oder einem anderen Unix-System sieht eine grundlegende Prüfung so aus: ```sh dig +noall +answer api.example.test CNAME A AAAA ``` Eine hilfreiche Ausgabeform ist: ```text api.example.test. 300 IN CNAME api.edge.vendor.test. api.edge.vendor.test. 60 IN A 203.0.113.42 api.edge.vendor.test. 60 IN AAAA 2001:db8::42 ``` Führe getrennte Abfragen für `CNAME`, `A` und `AAAA` aus, wenn dein Resolver nicht die gesamte Kette in einer Antwort liefert. Notiere Abfragedatum und verwendeten Resolver, denn Split-DNS kann einem Laptop, einem CI-Runner und einem Produktionshost unterschiedliche Antworten geben. Übernimm die resultierende IP-Adresse nicht in eine dauerhafte Allowlist für eine Internet-API. Edge-Netzwerke wechseln ihre Adressen regelmäßig. Halte sie als Prüfbeleg fest und warne bei überraschenden Änderungen. Erstelle anschließend eine Inventartabelle mit einer Zeile pro Autorität, nicht pro Anbieter. Sie sollte diese Fragen ohne Meeting beantworten: | Autorität | Verwendet von | Zugangsdaten | DNS-Verantwortlich | Erwarteter Weg | Prüfstatus | | --- | --- | --- | --- | --- | --- | | `https://api.example.test:443` | Produktionsagent | orders-write-prod | Anbieter | öffentlicher Edge | freigegeben | | `https://api-us.example.test:443` | regionaler Job | orders-write-us | Anbieter | öffentlicher Edge | ausstehend | | `https://gateway.example.test:443` | älteres Skript | keine | internes Team | internes Gateway | stillgelegt | Erfinde keine Zeile, nur weil ein Anbieter einen Endpunkt hat. Markiere ihn als ungenutzt, bis Code, Konfiguration oder eine freigegebene Migration ihn benötigt. Das Inventar soll versehentliche Fähigkeiten sichtbar machen, nicht jede Möglichkeit dokumentieren. Das OWASP Server-Side Request Forgery Prevention Cheat Sheet betont einen verwandten Punkt: Wenn eine Anwendung nur mit bekannten, vertrauenswürdigen Anwendungen kommuniziert, ist eine Allowlist sinnvoll, aber die Validierung von Domains allein klärt das DNS-Verhalten nicht. Diese Empfehlung zielt auf SSRF, doch die betriebliche Lehre gilt auch hier. Eine Hostnamenliste ist nur stark, wenn du weißt, wer die Namen pflegt, wohin sie auflösen und ob ein Aufrufer einen geprüften Namen später in eine andere Anfrage verwandeln kann. ## Weiterleitungen brauchen eine eigene Prüfung Eine Weiterleitung ist eine neue Zielentscheidung. Ein Client, der Weiterleitungen automatisch folgt, kann die freigegebene Autorität nach der ersten Anfrage verlassen. Ein Autorisierungsheader darf diese Reise nicht mitmachen. Beginne bei API-Aufrufen mit Zugangsdaten mit deaktivierten Weiterleitungen. Behandle eine Antwort mit 301, 302, 303, 307 oder 308 als Antwort, die eine ausdrückliche Entscheidung braucht. Steht die neue URL bereits in der Liste exakter Autoritäten für diese Zugangsdaten und sind das Verhalten von Methode und Body akzeptabel, stelle eine separate Anfrage dorthin. Ist sie nicht gelistet, stoppe. Die Statuscodes sind nicht austauschbar. Ein 303 ändert eine Anfrage häufig zu `GET`; 307 und 308 erhalten Methode und Anfrage-Body. Das automatische Wiederholen eines `POST` mit einem Autorisierungsheader ist folgenreicher als ein harmlos wirkendes `GET`, besonders wenn sich der neue Host unterscheidet. Teste das Verhalten der konkreten HTTP-Bibliothek, die du einsetzt. Manche Clients entfernen sensible Header bei Hostwechseln, andere behalten Header unter Bedingungen bei, die du nicht erwartest, und Wrapper können Standardwerte überschreiben. Ein Test sollte die Anfrage erfassen, die an einem kontrollierten zweiten Host eintrifft, und dann bestätigen, dass sie weder die Zugangsdaten noch einen kopierten Body erhalten hat. Der Name einer Bibliothek beweist nichts über ihre Weiterleitungsrichtlinie. Ein sicherer Aufrufpfad lässt sich einfach beschreiben: ```text 1. Parse the requested URL. 2. Normalize and match its authority against the credential record. 3. Inject the credential only after that match. 4. Send one request with redirects disabled. 5. If a redirect arrives, parse and review the new authority before any new request. ``` Diese Reihenfolge schützt auch vor einem subtileren Fehler: den Header in einen allgemeinen Client einzufügen, bevor das Ziel geprüft ist. Sobald Code ein Token an ein wiederverwendbares Anfrageobjekt hängt, können spätere URL-Änderungen es an ein unbeabsichtigtes Ziel tragen. Binde Zugangsdaten erst im letztmöglichen verantwortbaren Moment ein, nachdem die endgültige URL feststeht. ## Gemeinsame Hostnamen brauchen getrennte Zugangsdaten Ein einzelner Hostname kann mehrere APIs, Umgebungen und Mandanten hosten. Exaktes Host-Matching ist nötig, kann aber nicht alle Sicherheitsunterschiede hinter einem gemeinsamen Gateway ausdrücken. Betrachte `https://gateway.example.test`. Ein Pfad kann Rechnungen erstellen, ein anderer Telemetrie senden und ein dritter Nutzer verwalten. Wenn ein Bearer-Token alle drei autorisiert, bietet eine Hostprüfung nur groben Schutz. Ein Fehler, der `/telemetry` in `/admin` ändert, bleibt auf dem freigegebenen Hostnamen und funktioniert weiterhin. Die richtige Antwort sind in der Regel getrennte Zugangsdaten mit unterschiedlichen Berechtigungsumfängen. Gib dem Telemetrie-Client ein Token, das keine Nutzer verwalten kann, selbst wenn beide Aufrufe an denselben Host gehen. Wenn der Anbieter Zielgruppen oder Ressourcenindikatoren unterstützt, nutze sie. Wenn er nur breit angelegte Tokens anbietet, trenne Dienstkonten oder wähle eine sicherere Integrationsgrenze, statt so zu tun, als löse eine Pfad-Allowlist das Autorisierungsproblem. Pfadregeln haben dennoch ihren Platz. Sie können Programmierfehler auffangen und Absichten prüfbar machen. Pfade sind aber leichter falsch zu behandeln als Hosts: Prozentkodierung, wiederholte Schrägstriche, Punktsegmente, Gateway-Umschreibungen und Versionsweiterleitungen erschweren den Vergleich. Normalisiere mit demselben URL-Parser und derselben Anfragebibliothek, die den Aufruf sendet. Triff niemals eine Sicherheitsentscheidung mit einer selbst geschriebenen Teilzeichenkettenprüfung. Dasselbe gilt für Ports. `api.example.test:443` und `api.example.test:8443` sind unterschiedliche Autoritäten. Ein Reverse Proxy kann sie zu unterschiedlichen Diensten routen, und ein Entwickler, der den zweiten Port testet, kann annehmen, die erste Prüfung decke ihn ab. Erfasse beide oder erlaube keinen von beiden. ## Freigaben dort platzieren, wo Menschen das Ziel noch beurteilen können Eine Freigabe, die nur „API-Aufruf erlauben“ sagt, bittet den Prüfer, einen Blankoscheck zu unterschreiben. Der Prompt braucht Methode, vollständig normalisierte Autorität, Anfragepfad, Identität der Zugangsdaten und den anfragenden Prozess. Sonst kann ein Mensch kaum bemerken, dass der Agent von der Produktions-API zu einem vergessenen Kompatibilitäts-Hostnamen gewechselt ist. Sallyport bewahrt die Zugangsdaten in seinem verschlüsselten Tresor auf und führt die HTTP-Aktion selbst aus, statt das Geheimnis an den Agenten weiterzugeben. Das ist hilfreich, weil die Freigabe an der Aktionsgrenze erfolgen kann, wo Ziel und anfragender Prozess gemeinsam sichtbar sind. Mach aus einem Freigabebildschirm kein Ritual. Eine Freigabe pro Sitzung eignet sich für einen bekannten, kurzlebigen Agentenlauf, der eine stabile Menge freigegebener Autoritäten aufruft. Verlange eine Bestätigung pro Aufruf für Zugangsdaten, die Geld bewegen, Daten löschen oder Administrationsendpunkte erreichen können. Die Reibung sollte sich nach der Folge eines falschen Aufrufs richten, nicht nach der Geduld des Prüfers. Sallyport hat bewusst keine Richtliniensprache und keine Regel-Engine. Behandle es daher nicht als Ausrede, das Endpunktinventar zu überspringen. Sein Tresor-Gate und seine Autorisierungskontrollen beantworten, ob ein Prozess Zugangsdaten jetzt verwenden darf. Dein Zugangsdaten-Eintrag muss weiterhin beantworten, welche Autorität sie erhalten darf. Aktivitätsaufzeichnungen sollten genug Belege festhalten, um die Entscheidung später zu rekonstruieren: angeforderte Autorität, aufgelöster Weg, soweit verfügbar, Methode, Status, anfragende Sitzung und den angewendeten Zugangsdaten-Eintrag. Protokolliere weder das Geheimnis noch vollständige sensible Nutzdaten, nur um die Audit-Spur zu verbessern. Ein Protokoll, das einen zweiten Geheimnisspeicher erzeugt, verbessert kein Audit. ## Aliasse nach jeder DNS- und Integrationsänderung erneut prüfen Zielbindung verliert an Wirksamkeit, wenn sich DNS, Anbieterendpunkte oder Bereitstellungseinstellungen ändern. Mache die Inventarprüfung zu einem Bestandteil dieser Änderungen, statt sie als jährliche Übung zu behandeln, die einen Haufen veralteter Namen entdeckt. Löse eine Prüfung aus, wenn jemand einen CNAME hinzufügt oder bearbeitet, einen A- oder AAAA-Eintrag für einen erlaubten internen Namen ändert, einen regionalen Endpunkt einführt, ein SDK austauscht, ein API-Gateway ändert oder eine Weiterleitung hinzufügt. Der Prüfer sollte die alte und neue Liste der Autoritäten vergleichen und dann entscheiden, ob die bestehenden Zugangsdaten der Änderung folgen dürfen. Änderungen der DNS-Verantwortung verdienen dieselbe Aufmerksamkeit wie Änderungen der Code-Verantwortung. Warne bei Namen unter deiner Kontrolle, wenn ein freigegebener Hostname plötzlich zu privaten, Loopback-, Link-Local- oder unerwarteten internen Adressen auflöst. Das dient der SSRF-Abwehr ebenso wie dem Schutz von Zugangsdaten. Warne bei öffentlichen Anbieternamen bei Änderungen des CNAME-Ziels und wesentlichen Änderungen der Adressbereiche. Untersuche sie, statt jede CDN-Rotation automatisch zu blockieren. Halte einen kleinen Regressionstest neben der Integration. Er sollte eine freigegebene URL, eine nicht gelistete alternative Basis-URL, einen Host mit irreführendem Suffix, einen ausdrücklich angegebenen alternativen Port und eine hostübergreifende Weiterleitung ausprobieren. Das erwartete Ergebnis ist nicht bloß eine fehlgeschlagene Netzwerkverbindung. Der Client muss das Anfügen der Zugangsdaten verweigern, bevor irgendeine Anfrage das nicht gelistete Ziel erreicht. Diese letzte Bedingung ist der Maßstab. Wenn der Agent das Geheimnis zuerst senden und erst danach feststellen kann, dass das Ziel falsch war, ist die Prüfung genau dann gescheitert, als sie wichtig war.