# Wie das Einfügen von Zugangsdaten der Anfragevalidierung folgen sollte Zugangsdaten gehören ans Ende einer Pipeline für ausgehende Anfragen, nachdem der Client entschieden hat, was er senden darf. Fügt eine Komponente einen API-Schlüssel oder eine SSH-Zugangsdaten ein, bevor sie das tatsächliche Ziel und die Form der Anfrage prüft, hat sie die Sicherheitsentscheidung bereits getroffen. Alles danach ist nur noch Aufräumarbeit. Diese Reihenfolge ist bei autonomen Programmieragenten besonders wichtig. Ein Agent kann eine plausibel wirkende Anfrage erzeugen, einem Link aus einer API-Antwort folgen, ein Beispiel aus einem Repository wiederverwenden oder eine Weiterleitung akzeptieren, ohne die Folgen zu verstehen. Dafür muss der Agent nicht bösartig sein. Es reicht ein Anfragepfad, über den nicht vertrauenswürdige Eingaben beeinflussen, wohin eine authentifizierte Anfrage gesendet wird. Die nützliche Regel ist einfach: Vorgeschlagene Aktion parsen, die vollständige Aktion validieren, die Aktion einfrieren, die passende Verbindung aufbauen und die Zugangsdaten erst im letzten verantwortbaren Moment einfügen. Ändert sich die Anfrage, verwerfen Sie die Autorisierungsentscheidung und beginnen Sie von vorn. ## Zugangsdaten machen die Anfragevalidierung zur Sicherheitsgrenze Ein Injector für Zugangsdaten ist kein praktischer Wrapper um einen HTTP-Client. Er entscheidet, welche Gegenstelle die Berechtigung erhält, in Ihrem Namen zu handeln. Deshalb muss die Validierungsgrenze mehr umfassen als ein Hostname-Feld, das aus einem Anfrageobjekt kopiert wurde. Prüfen Sie bei einer HTTP-Aktion mindestens Schema, Hostname, Port, Methode, Pfad, Abfrageregeln, relevante Header und Body. Bei SSH müssen Sie Host, Port, die Vertrauensentscheidung für den Hostschlüssel, das Remote-Konto, den Befehl, die Weitergabe der Umgebung und jedes Ziel für die Dateiübertragung prüfen. Die Details unterscheiden sich, die Reihenfolge nicht. Teams vermischen häufig zwei getrennte Fragen: - Kann diese Anfrage den vorgesehenen Dienst erreichen? - Soll diese Zugangsdaten genau diese Anfrage autorisieren? Eine erfolgreiche DNS-Auflösung und ein gültiges TLS-Zertifikat beantworten nur einen Teil der ersten Frage. Die zweite beantworten sie nicht. Eine Anfrage an `https://api.example.com:8443` ist nicht automatisch gleichbedeutend mit einer Anfrage an den normalen HTTPS-Port. Ein `POST /v1/refunds` mit Bearer-Token ist nicht austauschbar mit einem `GET /v1/me`, selbst wenn beide denselben Host erreichen. Der häufigste Fehler ist eine weit gefasste Regel wie «Dieser Schlüssel gilt für api.example.com», gefolgt von einem Client, der eine beliebige URL akzeptiert, den Header ergänzt und die Bibliothek mit dem Versand beauftragt. Diese Regel überlässt URL-Parsing, Weiterleitungsverarbeitung, Proxy-Verhalten und vom Agenten kontrollierten Headern zu viel Einfluss. Außerdem werden Prüfungen dadurch irreführend. Ein Mensch genehmigt möglicherweise eine Anfrage, die als eine Sache beschrieben wird, während die Anfrage auf der Leitung etwas anderes sagt. Der Anfragevalidator muss auf beiden Seiten dieser Lücke die maßgebliche Instanz sein. Er sollte eine strukturierte Anfrage ausdrücklich beurteilen, statt in einer Zeichenfolge nach einem vertrauten Domainnamen zu suchen und zu hoffen, dass der Rest sich richtig verhält. ## Das Ziel in eine kanonische Origin parsen Eine Zielprüfung sollte strukturierte URL-Bestandteile vergleichen, keine Stringpräfixe. Die relevante Identität einer HTTP-Origin besteht aus Schema, Host und Port. RFC 3986 definiert den Authority-Teil als optionale Benutzerinformationen, einen Host und einen optionalen Port. RFC 9110 verwendet das Origin-Konzept für HTTP-Anfragen. Das sind kleine Definitionen mit weitreichenden Folgen. Beginnen Sie damit, die URL mit einem echten URL-Parser zu parsen. Lehnen Sie Werte ab, die Ihre Integration nicht benötigt. Reparieren Sie fehlerhafte Eingaben nicht zu etwas Großzügigerem. Ein Validator, der hilfreich sein will, erzeugt oft einen zweiten Parser, dessen Verhalten vom HTTP-Client abweicht. Für typische API-Zugangsdaten kann eine konservative Zielregel so aussehen: ```text accepted scheme: https accepted host: api.billing.example accepted port: 443 only accepted paths: /v1/invoices/* and /v1/customers/* userinfo: forbidden fragments: ignored before sending, rejected in proposed actions IP literals: forbidden unless explicitly configured ``` Bei der Kanonisierung ist Zurückhaltung wichtig. Schreiben Sie einen DNS-Hostnamen vor dem Vergleich in Kleinbuchstaben. Behandeln Sie einen fehlenden HTTPS-Port und Port 443 als denselben effektiven Port. Stellen Sie sicher, dass der Parser Userinfo und Host getrennt hat. Normalisieren Sie Punktsegmente nur, wenn Sie anschließend den normalisierten Pfad validieren, und dekodieren Sie reservierte Zeichen erst, wenn Sie wissen, wie der Client sie interpretiert. Mehrere URLs zeigen, warum Präfixprüfungen scheitern: ```text https://api.billing.example.attacker.invalid/v1/invoices https://api.billing.example@attacker.invalid/v1/invoices https://api.billing.example:8443/v1/invoices https://api.billing.example/v1/../admin/users ``` Nur die ersten Zeichen sehen vertraut aus. Authority oder späterer Pfad können anders sein. Die zweite URL verdient besondere Aufmerksamkeit: Der Text vor `@` ist Userinfo, nicht der Remote-Host. Ein Browser kann sie so darstellen, dass ein eilig prüfender Mensch auf den falschen Teil schaut. Internationalisierte Domainnamen erfordern dieselbe Vorsicht. Entscheiden Sie, ob die Integration einen festen ASCII-Hostnamen oder eine definierte Gruppe internationalisierter Namen akzeptiert. Konvertieren und vergleichen Sie nach einer einheitlichen, dokumentierten Regel. Vergleichen Sie nicht an einer Stelle die Darstellungsform und an einer anderen die Form auf der Leitung. DNS ist keine Autorisierungsdatenbank. Sie können DNS nach der Annahme einer Origin zum Verbindungsaufbau verwenden, aber akzeptieren Sie ein Ziel nicht allein deshalb, weil es zu einer erwarteten Adresse aufgelöst wird. Shared Hosting, Load Balancer, wechselnde Dienstadressen und DNS-Rebinding machen Annahmen über IP-Adressen brüchig. Wenn Sie Schutzmaßnahmen für private Netzwerke brauchen, wenden Sie sie als zusätzliche Verbindungsregel an, nicht als Ersatz für eine Origin-Allowlist. ## Verbindungsziel und HTTP-Authority gemeinsam prüfen URL, TLS-Servername und HTTP-Authority müssen dasselbe genehmigte Ziel beschreiben. Wenn das nicht der Fall ist, sollte der Injector für Zugangsdaten stoppen. HTTP bietet mehrere Stellen, an denen eine Authority auftauchen kann. HTTP/1.1 verwendet den `Host`-Header. HTTP/2 und HTTP/3 verwenden den Pseudo-Header `:authority`. Ein HTTP-Proxy kann ein Request-Target in Absolute-Form erhalten, das eine weitere Authority enthält. RFC 9112 verlangt, dass ein Client in HTTP/1.1 einen Host-Header sendet, und behandelt fehlende, doppelte oder ungültige Host-Felder als fehlerhaft. Diese Regel existiert, weil Routing anhand der Authority kein optionaler Zusatz ist. Bei einem Client, der Zugangsdaten verarbeitet, ist es am sichersten, die Authority-Erzeugung dem Agenten zu entziehen. Der vertrauenswürdige Transport erstellt `Host` oder `:authority` aus der bereits genehmigten URL. Er akzeptiert keine zweite, vom Agenten gelieferte Routing-Authority. Ebenso akzeptiert er keine vom Agenten gelieferten Header wie `Connection`, `Proxy-Authorization`, `Transfer-Encoding`, `Content-Length` oder `Expect`, es sei denn, eine enge Integration benötigt einen davon und die Implementierung behandelt ihn bewusst. So vermeiden Sie eine gefährliche gespaltene Anfrage. Stellen Sie sich einen Validator vor, der `https://api.billing.example/v1/invoices` genehmigt und anschließend beliebige Header des Agenten übernimmt. Wenn der HTTP-Stack einen mitgelieferten `Host`-Wert berücksichtigt, können Proxy, Gateway oder falsch konfigurierter Server die Anfrage anhand dieses Headers weiterleiten. Der Validator genehmigte ein Ziel, die Anfrage erreichte aber ein anderes. Dasselbe gilt für die Proxy-Konfiguration. Ein Unternehmensproxy kann legitim sein, ist aber eine Transportroute und keine neue Authority für die Zugangsdaten. Halten Sie Proxy-Einstellungen aus den Anfragedaten des Agenten heraus. Validieren Sie das endgültige Ziel unabhängig und machen Sie das Proxy-Verhalten in Audit-Einträgen sichtbar. Die Prüfung von TLS-Zertifikaten ist bei HTTPS zwingend, aber eine Zertifikatsprüfung ist keine Erlaubnis, beliebige Zugangsdaten zu verwenden. Der Client sollte den Hostnamen aus der genehmigten URL prüfen, diesen Hostnamen gegebenenfalls für Server Name Indication verwenden und eine Zertifikatsabweichung ablehnen. Geben Sie einem Agenten keinen Schalter «Prüfung überspringen». Eine vorübergehende Diagnoseabkürzung wird leicht zu einem dauerhaften Ausweg. ## Weiterleitungen sind neue Anfragen, keine Fortsetzung Eine authentifizierte Weiterleitung ist eine zweite Anfrage mit einem neuen Ziel. Wer sie als transparente Fortsetzung behandelt, sorgt dafür, dass Zugangsdaten die gesetzte Grenze verlassen. Die sicherste Standardeinstellung für API-Clients ist, automatische Weiterleitungen zu deaktivieren, sobald eine Anfrage Zugangsdaten enthält. Geben Sie die Weiterleitungsantwort an die vertrauenswürdige Anfrageebene zurück, parsen Sie den `Location`-Wert, lösen Sie ihn nach den URL-Regeln auf und führen Sie die daraus entstehende Anfrage durch den vollständigen Validator. Entscheiden Sie erst danach, ob eine weitere Anfrage gesendet wird, und fügen Sie erst dann Zugangsdaten für diese neue Anfrage ein. Eine Weiterleitung zu einer anderen Origin darf keine Zugangsdaten der ursprünglichen Anfrage erhalten. Das umfasst ein anderes Schema, einen anderen Hostnamen oder einen anderen effektiven Port. Eine Weiterleitung von HTTPS zu HTTP muss bei einem Aufruf einer API mit Zugangsdaten vollständig scheitern. Auch die Weiterleitung von `api.example.com` zu `login.example.com` ist ein Origin-Wechsel, selbst wenn beide Namen demselben Unternehmen gehören. Eigentum am Unternehmen ist keine Transportregel. Der HTTP-Statuscode verändert das Risiko. RFC 9110 legt das Verhalten bei Weiterleitungen fest, einschließlich Codes, die Methode und Body erhalten. RFC 9700, die OAuth 2.0 Security Best Current Practice, warnt, dass Autorisierungsserver bei einer Anfrage, die Benutzerzugangsdaten enthalten könnte, keine Weiterleitung mit HTTP 307 verwenden dürfen. Der Grund ist klar: Ein Client kann Methode und Body der ursprünglichen Anfrage am neuen Ziel wiederholen. Daraus ergibt sich eine praktische Weiterleitungsrichtlinie: 1. Lehnen Sie Weiterleitungen bei authentifizierten Machine-to-Machine-Aufrufen standardmäßig ab. 2. Erlauben Sie nur eine kleine, dokumentierte Gruppe von Weiterleitungen, wenn eine Integration sie benötigt. 3. Validieren Sie für jeden Hop das aufgelöste Ziel, die Methode, die Header und den Body erneut. 4. Entfernen Sie alle Zugangsdaten, bevor Sie den nächsten Hop prüfen. 5. Setzen Sie ein niedriges Weiterleitungslimit und protokollieren Sie jede Entscheidung. Lösen Sie das Problem nicht, indem Sie jeder Subdomain vertrauen. `uploads.example.com` und `api.example.com` können von unterschiedlichen Teams betrieben werden, unterschiedliche Infrastruktur nutzen oder unterschiedliche Angriffswege eröffnen. Ein Wildcard, das bei der Einrichtung praktisch wirkt, überlebt oft den ursprünglichen Grund für seine Existenz. Bei signierten Anfragen gibt es eine verwandte Falle. Wenn eine API Methode, Pfad, ausgewählte Header oder einen Body-Digest signiert, kann eine Weiterleitung die Signatur normalerweise ohnehin nicht erhalten. Eine erneute Signierung ist erst sinnvoll, wenn die nächste Anfrage ihre eigene Validierung bestanden hat. Eine Signatur beweist, dass jemand mit dem Geheimnis Daten signiert hat. Sie beweist nicht, dass diese Daten weiterhin ein genehmigtes Ziel beschreiben. ## Für Header muss zuerst die Zuständigkeit geklärt werden Header lassen sich leichter filtern, wenn Sie festlegen, wem jeder Header gehört. Die Anfrageebene sollte für Zugangsdaten und Routing zuständig sein. Der Agent darf nur die Anwendungs-Header verwalten, die eine bestimmte Integration ausdrücklich erlaubt. Zu den Zugangsdaten-Headern gehören `Authorization`, ein anbieterspezifischer API-Key-Header, Cookies und manchmal ein Signatur-Header. Fügen Sie sie nach der Validierung ein. Übernehmen Sie niemals einen davon vom Agenten, selbst wenn der Agent behauptet, er enthalte nur einen Platzhalter. Ein Platzhalter lädt zu versehentlicher Ersetzungslogik ein und vermittelt die falsche Schnittstelle: Der Agent schlägt eine Aktion vor, die vertrauenswürdige Komponente liefert die Berechtigung. Routing- und Framing-Header umfassen `Host`, `Content-Length`, `Transfer-Encoding`, `Connection`, `Upgrade` und HTTP/2-Pseudo-Header. Lassen Sie die Transportbibliothek diese erzeugen. Benutzereingaben dürfen sie nicht überschreiben. Anwendungs-Header können erlaubt sein, aber nur nach einem Schema. Angenommen, eine API akzeptiert eine Kundenkennung, einen Idempotency-Key und einen Content-Type. Erlauben Sie diese Namen, prüfen Sie ihre Werte und lehnen Sie alles andere ab. Übergeben Sie keine beliebige Header-Map, nur weil die meisten Aufrufe harmlose Header verwenden. Gerade der seltene Header kann aus einer normalen Anfrage eine Proxy-Anweisung, eine Cache-Variante, eine alternative Identität oder einen Debugging-Pfad machen. `Authorization` muss auch in Logs besonders behandelt werden. Protokollieren Sie, dass der Injector die Zugangsdatenreferenz `billing-prod-readwrite` verwendet hat, nicht deren Wert oder eine kodierte Form. Einen Header erst zu schwärzen, nachdem ein generischer Logger ihn bereits erfasst hat, ist nicht zuverlässig. Erzeugen Sie ein sicheres Ereignis aus strukturierten Feldern, bevor eine Komponente die Anfrage serialisiert. Benutzerdefinierte Header-Zugangsdaten sind nicht weniger sensibel als Bearer-Tokens, nur weil sie einen Namen wie `X-Api-Key` tragen. Wenn der empfangende Dienst den Wert als Berechtigung akzeptiert, kann jeder Empfänger ihn möglicherweise wiederverwenden. Andere Headernamen verändern Interoperabilität und Protokollierungsgewohnheiten. Sie ändern nicht die Notwendigkeit, das Ziel des Werts zu prüfen. ## Methode, Pfad und Body definieren die Aktion Eine Host-Allowlist ist zu weit gefasst, wenn ein Schlüssel Daten lesen, ändern oder Geldbewegungen auslösen kann. Die Form der Anfrage muss Teil der Berechtigungsentscheidung sein. Beginnen Sie mit der Methode. Erlauben Sie die Methoden, die die Integration benötigt, und lehnen Sie den Rest ab. Beschreiben Sie `POST` nicht grundsätzlich als gefährlich und `GET` als sicher. Viele APIs bieten zustandsverändernde Vorgänge über GET-Endpunkte an, und ein GET kann private Informationen über Query-Parameter oder Logs preisgeben. Methodenregeln bleiben wichtig, weil sie die Richtlinienprüfung konkret machen. Prüfen Sie anschließend den Pfad anhand von Routenschablonen, nicht anhand eines vagen Präfixes. Eine Routenschablone wie `/v1/projects/{project_id}/deployments` kann die Anzahl der Segmente, zulässige Zeichen in Kennungen und die Frage erzwingen, ob ein Agent ein Projekt außerhalb seines Bereichs auswählen darf. Wenn ein Endpunkt ein Query-Parameter zur Auswahl eines Kontos verwendet, prüfen Sie auch diesen Parameter. Ein korrekter Hostname macht `/v1/accounts/other-team/export` nicht akzeptabel. Der Body muss Teil der eingefrorenen Anfrage sein. Ein Validator, der ein JSON-Objekt genehmigt und anschließend eine andere Ebene serialisieren oder verändern lässt, autorisiert möglicherweise nicht die Bytes, die den Rechner verlassen. Das zeigt sich bei doppelten JSON-Schlüsseln, Form-Encoding, Multipart-Grenzen, Gleitkommaumwandlung und Middleware, die Felder hinzufügt. Ein praktikables Design lässt den Validator einen unveränderlichen Ausführungsplan erzeugen: ```json { "method": "POST", "url": "https://api.billing.example/v1/invoices/inv_123/cancel", "headers": { "content-type": "application/json", "idempotency-key": "job-7f3c" }, "body_sha256": "4d94c2...", "credential_ref": "billing-cancel" } ``` Der Transport erhält den Plan und die vorbereiteten Body-Bytes. Er bestätigt den Body-Digest, bevor er die authentifizierte Anfrage öffnet. Er leitet Routing-Header aus der URL ab, fügt das Geheimnis aus `credential_ref` ein und sendet genau diese Bytes. Weicht der Digest ab, schlägt der Vorgang fehl, statt zu raten, welche Stufe die Anfrage verändert hat. Dieser Ansatz verbessert auch die menschliche Genehmigung. Eine Genehmigungskarte kann eine verständliche Aktion sowie kanonische Origin, Methode, Route, ausgewählte Kontokennung und Betrag oder Ressourcennamen zeigen. Sie sollte niemanden auffordern, ein rohes JSON-Objekt zu genehmigen, in dem ein gefährliches Feld am Ende versteckt ist. ## Ein kleiner Validator ist sicherer als eine allgemeine Richtliniensprache Der verbreitete Impuls ist, eine umfangreiche Regel-Engine zu bauen: beliebige Bedingungen, reguläre Ausdrücke, Variablen, Ausnahmen und eine Notfallumgehung. Das klingt flexibel, bis jemand entscheiden muss, ob Zugangsdaten ein Weiterleitungsziel mit Proxy-Header und von einem Agenten zusammengestelltem JSON-Body erreichen dürfen. Für das Einfügen von Zugangsdaten reicht meist ein kleineres Modell. Jede Zugangsdatenart sollte einen ausdrücklichen Kanal und einen kompakten Anfragevertrag haben. Für HTTP benennt dieser Vertrag erlaubte Origins, Methoden, Routen, zulässige Header, Weiterleitungsverhalten und Body-Beschränkungen. Für SSH nennt er Hosts, Benutzer, Erwartungen an Hostschlüssel, erlaubte Befehlsformen und Einschränkungen bei Übertragungen. Eine kompakte Konfiguration kann so aussehen: ```yaml credential: billing-cancel channel: https origins: - https://api.billing.example:443 methods: [POST] routes: - /v1/invoices/{invoice_id}/cancel headers: content-type: application/json idempotency-key: generated redirects: deny body: required_fields: [reason] allowed_fields: [reason] ``` Dieses Fragment ist kein vollständiges Sicherheitssystem. Es zeigt aber die entscheidende Einschränkung: Zugangsdaten sind an eine enge Aktionsform gebunden. Wenn die nächste Integration `GET /v1/invoices/{invoice_id}` benötigt, geben Sie ihr eine eigene Route und möglichst auch separate, schreibgeschützte Zugangsdaten. Machen Sie aus den Zugangsdaten für Stornierungen nicht stillschweigend einen allgemeinen Kontoschlüssel. Reguläre Ausdrücke verdienen hier Misstrauen. Sie können für ein einzelnes Feld mit sorgfältig definierter Grammatik nützlich sein, sind aber kein guter Ersatz für das Parsen von URLs, JSON, Shell-Befehlen oder HTTP-Headern. Ein Ausdruck, der einen Pfad scheinbar einschränkt, kann versagen, wenn Dekodierung, Normalisierung oder ein nachgeschalteter Router dieselben Bytes anders interpretiert. Sallyport verfolgt für Agentenaktionen bewusst einen kleineren Ansatz: Geheimnisse bleiben im verschlüsselten Tresor und HTTP- oder SSH-Aktionen werden ausgeführt, ohne diese Geheimnisse dem Agenten offenzulegen. Diese Trennung ist nur dann sinnvoll, wenn das Aktions-Gateway die Aktion validiert, bevor es den Tresor zur Verwendung einer Zugangsdatenart auffordert. ## Die Validierung muss die Übergabe an den Transport überstehen Ein perfekter Validator hilft nicht, wenn eine spätere Ebene das Ziel ändern kann. Die Grenze braucht eine Übergabe, die das Genehmigte bewahrt. Validieren Sie kein veränderliches Anfrageobjekt und übergeben Sie dasselbe Objekt an Middleware, die URLs umschreiben, Header zusammenführen, Cookies anhängen, Weiterleitungen folgen oder anhand von vom Agenten kontrollierten Umgebungsvariablen einen Proxy auswählen kann. Validieren Sie in einen neuen, unveränderlichen Plan. Geben Sie dem Transport die möglichst wenig ausdrucksstarke Eingabe. Die Ausführungsreihenfolge sollte langweilig und fest sein: 1. Parsen Sie die vom Agenten vorgeschlagene Aktion in typisierte Felder. 2. Validieren Sie das kanonische Ziel und die erlaubte Form der Anfrage. 3. Serialisieren Sie die genehmigte Nutzlast einmal und speichern Sie ihren Digest. 4. Bauen Sie die Verbindung anhand von genehmigtem Schema, Host und Port auf. 5. Fügen Sie die Zugangsdaten im vertrauenswürdigen Transport unmittelbar vor der Übertragung ein. Fügen Sie Zugangsdaten nicht früher ein, nur um die Retry-Logik zu vereinfachen. Ein erneuter Versuch ist eine weitere Übertragung und braucht dieselben Ziel- und Anfrageprüfungen. Ein unveränderlicher genehmigter Plan kann wiederverwendet werden, solange sich nichts Wesentliches geändert hat. Ändert ein Retry Host, Route, Proxy-Modus, Methode, Body oder Authentifizierungsschema, ist es eine neue Aktion. Die Wiederverwendung einer Verbindung ist nur sicher, wenn die HTTP-Bibliothek Authority-Grenzen intakt hält. Eine Verbindung aus einem Pool darf nicht zulassen, dass Autorisierungsmetadaten einer Anfrage in die nächste gelangen. Das klingt selbstverständlich, aber gemeinsam verwendete veränderliche Header-Maps und schlecht abgegrenzte Interceptoren sind eine häufige Ursache für diese Fehlerklasse. Bei SSH entspricht dem die Validierung eines Hostnamens, während ein Befehls-Wrapper nach der Genehmigung einen anderen `ProxyCommand`, Agent-Socket, Ziel-Jump-Host oder Remote-Befehl durchlassen kann. Die Vertrauensentscheidung muss die gesamte Route und Ausführungsanfrage binden, nicht nur den ersten Hostnamen, den der Agent sieht. ## Testen Sie Fehler, die normale Integrationstests auslassen Ein Injector für Zugangsdaten sollte Tests haben, die beweisen, dass er verdächtige Eingaben ablehnt. Erfolgsfalltests zeigen, dass ein API-Aufruf funktioniert. Ablehnungstests zeigen, dass das Design nach einem Bibliotheksupgrade oder einer neuen Agentenfunktion noch das bedeutet, was Sie annehmen. Erstellen Sie eine Tabelle vorgeschlagener Aktionen und erwarteter Entscheidungen. Nehmen Sie mindestens diese Fälle auf: - Eine exakt genehmigte HTTPS-Origin und Route, die erfolgreich ist. - Ein Hostnamensuffix wie `api.billing.example.attacker.invalid`, das scheitert. - Eine URL mit Userinfo vor `@`, die scheitert. - Ein gültiger Host an einem unerwarteten Port, der scheitert. - Eine Weiterleitung zu einer anderen Origin, die scheitert, ohne Zugangsdaten zu senden. - Ein unerwarteter `Host`-, `Authorization`- oder Proxy-Header, der scheitert. - Ein Body, der sich nach der Genehmigung ändert und die Digest-Prüfung nicht besteht. Verwenden Sie einen lokalen Testserver, der jeden empfangenen Anfrage-Header aufzeichnet. Das ist überzeugender, als ein gemocktes Anfrageobjekt zu prüfen. Ihr Test sollte sicherstellen, dass der Server am nicht genehmigten Weiterleitungsziel keinen API-Schlüssel, kein Bearer-Token, keine Cookies und keinen Signatur-Header gesehen hat. Testen Sie sowohl Weiterleitungsantworten, die einen Body erhalten, als auch solche, die häufig zu einem GET werden, da Bibliotheksstandards variieren. Testen Sie außerdem abweichendes Parserverhalten. Geben Sie dem Validator und dem produktiven HTTP-Client dieselben ungewöhnlichen URLs, einschließlich Prozentkodierung, leerer Ports, doppelter Schrägstriche, Punktsegmente, gegebenenfalls IPv6-Literale und gegebenenfalls internationalisierte Namen. Wenn sie Authority oder Pfad unterschiedlich verstehen, lehnen Sie diese Kategorie ab, bis das Verhalten konsistent ist. Audit-Einträge sollten die Entscheidung des Validators vor dem Netzwerkaufruf und das Ergebnis des Transports danach erfassen. Ein nützlicher Eintrag nennt die angeforderte Zugangsdatenreferenz, die genehmigte kanonische Origin und Route, ob eine Weiterleitung auftrat und warum eine Anfrage abgelehnt wurde. Er enthält niemals geheime Inhalte. Wenn Sie nicht nachvollziehen können, warum ausgehende Zugangsdaten verwendet wurden, haben Sie für eine Untersuchung nicht genügend Belege. ## Eine Genehmigung hilft erst, wenn die Anfrage konkret ist Eine menschliche Genehmigungsabfrage kann verhindern, dass ein Agent Zugangsdaten im falschen Moment verwendet. Die Abfrage muss aber eine Anfrage beschreiben, die das System bereits validiert hat. Erst um Genehmigung zu bitten und später zu parsen, macht den Menschen zu einem schwachen URL-Parser. Zeigen Sie Origin, Aktion, Methode, Route und die wichtigen Geschäftsfelder. Bei einem Zahlungsaufruf zeigen Sie Empfänger, Währung und Betrag. Bei Quellcodeverwaltung zeigen Sie Repository, Branch und Vorgang. Bei einer Infrastruktur-API zeigen Sie Konto, Region, Ressource und zerstörerische Wirkung. Halten Sie rohe Geheimnisse und unbegrenzte Request-Bodies aus der Abfrage heraus. Eine Genehmigung pro Aufruf ist für Zugangsdaten sinnvoll, die erheblichen Schaden verursachen können. Eine Sitzungsgenehmigung eignet sich für wiederholte Aufrufe mit geringem Risiko, wenn die Sitzung eine erkennbare Prozessidentität und eine kurze Lebensdauer hat. Keine von beiden ersetzt die Anfragevalidierung. Ein Benutzer kann einem vertrauenswürdigen Programmierprozess zustimmen, aber das bedeutet nicht, dass jede von diesem Prozess zusammengesetzte URL dieselben Zugangsdaten verdient. Sallyports Autorisierung pro Sitzung und optionale Schlüsselgenehmigung pro Aufruf passen hinter diese Grenze: Die App kann eine Person bitten, einen bekannten Agentenprozess oder eine konkrete Verwendung von Zugangsdaten zu autorisieren, während der vertrauenswürdige Aktionspfad das Geheimnis behält und die Aktion aufzeichnet. Die Genehmigung muss den konkreten, validierten Ausführungsplan abdecken, nicht die informelle Beschreibung der Absicht durch den Agenten. Die erste Änderung ist normalerweise kein großes Richtlinienprojekt. Deaktivieren Sie automatische Weiterleitungen bei authentifizierten Aufrufen. Lehnen Sie Routing- und Zugangsdaten-Header des Agenten ab. Parsen Sie das Ziel in eine kanonische Origin. Binden Sie dann Methode, Route, Header und Body, bevor ein Geheimnis in die Anfrage gelangt. Diese Reihenfolge verhindert eine ganze Gruppe von Leaks, die sich durch noch so sorgfältige Geheimnisaufbewahrung nicht beheben lassen.