# HTTP-Redirect-Validierung für authentifizierte Agent-Anfragen

Die Validierung von HTTP-Redirects muss erfolgen, bevor ein Agent Zugangsdaten an die nächste URL weitergibt. Ein Redirect ist keine harmlose Fortsetzung derselben Anfrage. Er ist eine Anweisung eines entfernten Servers, eine weitere Anfrage zu senden, oft an eine andere Instanz, mit einer anderen Methode und an ein anderes Netzwerkziel.

Dieser Unterschied geht verloren, wenn man einen Agenten mit einem API-Client verbindet und die standardmäßige Redirect-Einstellung des Clients aktiviert lässt. Der Agent sendet eine Anfrage an eine genehmigte API. Die API antwortet mit `302 Location: https://somewhere-else/...`. Der Client folgt dem Redirect. Werden Zugangsdaten zu früh hinzugefügt, kann ein Angreifer, der den ersten Endpunkt, einen Redirect-Parameter oder eine kompromittierte Abhängigkeit kontrolliert, einen erlaubten Aufruf in einen Dienst zur Weitergabe von Zugangsdaten verwandeln.

Ich habe oft erlebt, dass dieses Risiko heruntergespielt wird, weil ausgereifte HTTP-Bibliotheken `Authorization` bei einem Hostwechsel häufig entfernen. Das hilft, reicht aber weder immer noch aus. Benutzerdefinierte Zugangsdaten-Header, signierte Query-Parameter, Cookies, weitergeleitete Request-Bodys, DNS-Änderungen und Redirects innerhalb desselben Hosts auf einen gefährlichen Endpunkt werden dadurch nicht abgedeckt. Baue eine ausdrückliche Redirect-Entscheidung ein, statt Bibliotheksstandards als deine Richtlinie zu behandeln.

## Redirects schaffen eine neue Autorisierungsentscheidung

Jeder Redirect-Hop braucht dieselbe Prüfung wie die erste URL, weil der Server das nächste Ziel auswählt. Der Client hat eine Ressource angefordert und eine Antwort erhalten, die im Feld `Location` eine andere URI vorschlägt. Die ursprüngliche Allowlist-Entscheidung gilt nicht automatisch für diese URI.

RFC 9110 definiert Redirects anhand ihrer Statuscodes und beschreibt, wie User-Agents darauf reagieren dürfen oder sollen. Die Spezifikation sagt nicht, dass ein an die ursprüngliche Anfrage angehängtes API-Zugangsdatenobjekt für jede URI autorisiert ist, die ein Server zurückgeben könnte. Diese Lücke muss der Aufrufer schließen. Bei einem Agent-Gateway ist der Aufrufer dafür verantwortlich, welche nachgelagerten Aktionen ausgeführt werden.

Halte diese beiden Ereignisse im Code und in den Logs getrennt:

1. Der Server sendet eine Redirect-Antwort auf eine bereits gestellte Anfrage.
2. Der Client entscheidet sich, eine neue Anfrage an das aufgelöste Ziel zu senden.

Das erste Ereignis ist eine Tatsache. Das zweite ist eine privilegierte Aktion. Wenn deine Implementierung beides in einem Komfortaufruf wie `client.Do(request)` mit aktivierten automatischen Redirects verbindet, hast du den Moment verborgen, in dem die Richtlinie greifen muss.

Ein Redirect kann mehrere Grenzen gleichzeitig überschreiten. `https://api.example.test/v1/export` könnte auf `https://downloads.example.test/file` verweisen, das wiederum auf eine zeitlich begrenzte Objekt-URL bei einem Speicheranbieter zeigt. Diese Kette kann legitim sein. Sie bedeutet aber auch, dass eine lockere Regel wie «Der erste Host ist genehmigt» fast nichts über die endgültige Verbindung aussagt.

Relative Redirects brauchen dieselbe Sorgfalt. Löse `Location: ../admin` mithilfe eines standardkonformen URL-Parsers relativ zu der URL auf, die den Redirect ausgelöst hat. Verknüpfe keine Zeichenketten. Ein Pfad, der mit `//` beginnt, ist schemarelativ und kann den Host ändern. Kodierte Trennzeichen und ungewöhnliche Formen wie ein leerer Location-Wert haben zu genügend unterschiedlichen Client-Verhalten geführt, dass ein Gateway Mehrdeutigkeiten ablehnen sollte, statt zu raten.

## Zugangsdaten erst nach der Zielprüfung einfügen

Die sichere Reihenfolge ist einfach: Antwort empfangen, mögliches Ziel parsen, Ziel validieren, nächste Anfrage erstellen und dann nur die für dieses Ziel genehmigten Zugangsdaten einfügen. Zugangsdaten gehören an den endgültigen Versandpunkt, nicht in ein veränderliches Request-Objekt, das eine Redirect-Kette überlebt.

Dieser Designfehler verursacht die meisten Leaks. Ein Wrapper erstellt eine Anfrage mit `Authorization: Bearer ...`, sendet sie und lässt den HTTP-Client die Anfrage nach einem Redirect kopieren oder erneut senden. Der Wrapper mag das Token für einen einzigen Host vorgesehen haben, kontrolliert aber nicht mehr jeden einzelnen Versand.

Verwende eine Anfragebeschreibung ohne geheime Inhalte. Sie kann Methode, Body, erlaubte Referenz auf Zugangsdaten und ursprüngliche URL enthalten. Erstelle für jeden Hop nach der Validierung eine neue Anfrage für die Übertragung. Die Versandebene sucht die Zugangsdaten erst dann heraus, wenn ein zulässiges Ziel feststeht.

Ein kompaktes Modell sieht so aus:

```text
request intent:
  method: POST
  initial URL: https://api.acme.test/v1/reports
  credential reference: billing-api-prod
  body digest: sha256:...

for each response:
  if status is not a supported redirect: return response
  target = resolve(response.request_url, response.headers["Location"])
  decision = validate(target, request intent, response.status)
  if decision is reject: record rejection and stop
  next_request = build(decision.method, target, permitted body)
  inject(credential reference, target, next_request)
  send(next_request)
```

Das Entscheidende ist nicht das Pseudocode-Beispiel, sondern die Lebensdauer des Geheimnisses. Das Token existiert nur in der Anfrage, deren Ziel bereits validiert wurde. Es liegt nie in einem allgemeinen Objekt, das ein Redirect-Callback versehentlich weiterleiten könnte.

Diese Reihenfolge macht auch den Umfang der Zugangsdaten durchsetzbar. Ein Bearer-Token für `api.acme.test` sollte nicht automatisch `uploads.acme.test` authentifizieren, selbst wenn beide Namen zu einem Unternehmen gehören. Weise jeder Zielregel eine ausdrückliche Referenz auf Zugangsdaten zu. Wenn zwei Dienste absichtlich gemeinsame Zugangsdaten verwenden, dokumentiere diese Beziehung in der Regel, statt sie aus einem DNS-Suffix abzuleiten.

## Der Abgleich des Ursprungs verhindert ein Leck, aber nicht alle anderen Risiken

Ein strenger Abgleich des Ursprungs blockiert offensichtliche Hostwechsel, beantwortet aber noch nicht, ob eine weitergeleitete Anfrage sicher ist. Ein Ursprung besteht aus Schema, Host und Port. Behandle jede Änderung an einem dieser Felder als Grenze, sofern keine ausdrückliche Ausnahme existiert.

Das Schema ist wichtig. Ein Redirect von HTTPS zu HTTP kann Header oder Anfrageinhalte im Netzwerk offenlegen. Lehne Herabstufungen für authentifizierten Datenverkehr ab. Ein Redirect von HTTP zu HTTPS klingt zwar sicher, ändert aber trotzdem die Instanz und kann einen unerwarteten Endpunkt verbergen. Prüfe ihn ganz normal.

Auch der Port ist wichtig. `https://api.example.test` und `https://api.example.test:8443` sind unterschiedliche Ursprünge. Entwickler vergessen das oft, weil Browser Standardports verbergen und lokale Testumgebungen ständig alternative Ports verwenden. Ein Token für die öffentliche API kann bei einem Administrationsdienst landen, wenn deine Allowlist nur den Hostnamen prüft.

Der Pfad ist relevant, wenn ein API-Host verschiedene Anwendungen bereitstellt. Ein Redirect von `/v1/files` zu `/internal/debug/export` bleibt zwar im selben Ursprung, kann aber einen Body offenlegen oder eine unsichere Zustandsänderung auslösen. Eine Pfad-Allowlist ersetzt keine Autorisierung auf Anwendungsebene. Begrenze Redirect-Ziele trotzdem auf die API-Präfixe, die deine Integration tatsächlich benötigt.

Query-Parameter brauchen besondere Aufmerksamkeit. Ein Redirect-Ziel kann eine vorab signierte URL, einen Zustandsparameter oder ein einmaliges Download-Token enthalten. In der Praxis sind solche Werte Zugangsdaten, auch wenn sie keinen `Authorization`-Header verwenden. Übernimm keine Query-Parameter aus der alten Anfrage in die neue URL. Verwende genau das geparste Redirect-Ziel, nachdem Regeln angewendet wurden, die Userinfo-Felder, Fragmente oder verdächtig wirkende Zugangsdatenparameter verbieten.

Eine sinnvolle Ausgangsbasis ist, Redirects innerhalb desselben Ursprungs nur dann zu erlauben, wenn das Schema HTTPS bleibt, der Port genehmigt bleibt, der Zielpfad innerhalb der erlaubten API-Fläche der Integration liegt und der Redirect-Status die vorgesehene Methode zulässt. Behandle Redirects zwischen verschiedenen Ursprüngen als eigene Klasse mit benannten Zielregeln.

## Redirect-Statuscodes ändern die mögliche Anfrage

Redirect-Statuscodes enthalten Informationen zur Methode. Ein Client, der sie ignoriert, kann aus einem sicheren Lesevorgang einen unerwarteten Schreibvorgang machen oder einen sensiblen Body erneut senden. Reduziere nicht jede 3xx-Antwort auf «Location folgen».

RFC 9110 besagt, dass 307 und 308 Methode und Inhalt beibehalten. War die ursprüngliche Anfrage beispielsweise ein `POST` mit einer Berichtsdefinition, fordert ein 307- oder 308-Redirect den Client auf, denselben `POST` mit demselben Body an das neue Ziel zu senden. Das ist der riskanteste Redirect-Fall, weil der neue Host sowohl Geschäftsdaten als auch eine Anfrage mit Nebenwirkungen erhalten kann.

Status 303 weist den Client an, eine Darstellung mit `GET` oder `HEAD` abzurufen, unabhängig von der ursprünglichen Methode. Das passiert häufig nach dem Absenden eines Formulars. Bei einer Agent-Aktion solltest du dies nur erlauben, wenn das Ziel des weitergeleiteten GET separat genehmigt ist und deine Integration dieses Muster erwartet. Ein 303 darf keinen Authorization-Header übernehmen, nur weil der ursprüngliche POST einen hatte.

Die historischen Problemfälle sind 301 und 302. RFC 9110 beschreibt die langjährige Praxis, POST bei diesen Antworten in GET zu ändern, während 307 und 308 für Aufrufer eingeführt wurden, die Methoden beibehalten müssen. Bibliotheken unterscheiden sich in Details, besonders bei Nicht-POST-Methoden und Bodys. Überlasse diese Unklarheit niemals einem autonomen Client.

Schreibe das Verhalten ausdrücklich fest. Zum Beispiel:

- Folge 301 und 302 nur bei `GET`- und `HEAD`-Anfragen.
- Folge 303 nur mit einem GET oder HEAD ohne Zugangsdaten. Prüfe das Ziel anschließend erneut, bevor du genehmigte Lesezugangsdaten einfügst.
- Folge 307 und 308 nur, wenn die Zielregel die ursprüngliche Methode und Body-Klasse ausdrücklich erlaubt.
- Lehne einen Redirect nach einer nicht idempotenten Methode wie `POST`, `PATCH` oder `DELETE` ab, sofern die Integration keinen dokumentierten Redirect-Ablauf besitzt.

Das kann eine schlecht entworfene API unbrauchbar machen. Das ist besser, als eine Zahlungsanweisung, einen Quellcode-Upload oder einen Administrationsbefehl stillschweigend dort zu wiederholen, wohin ein entfernter Server ihn gelenkt hat. Wenn ein Anbieter weitergeleitete Schreibvorgänge verlangt, füge eine eng begrenzte Ausnahme hinzu und teste die genaue Abfolge.

## Zielregeln brauchen Felder, keine Hostnamen-Zeichenkette

Ein guter Redirect-Validator prüft ein Ziel gegen eine Regel, die den vorgesehenen Dienst ausreichend genau beschreibt. Eine einfache Hostname-Allowlist wirkt attraktiv, weil sie kurz ist. Sie ist aber auch der Punkt, an dem sich Ausnahmen ansammeln, bis niemand mehr erklären kann, was ein Agent wohin senden darf.

Lege für jedes erlaubte Redirect-Ziel Folgendes fest:

- Welche Schemata erlaubt sind, normalerweise nur HTTPS.
- Welche normalisierten Hostnamen und Ports erlaubt sind.
- Welche Methoden und Pfadpräfixe die weitergeleitete Anfrage verwenden darf.
- Welche Referenz auf Zugangsdaten dort gegebenenfalls eingefügt werden darf.
- Ob das Ziel in private oder lokale Netzwerkadressen aufgelöst werden darf.

Normalisiere vor dem Abgleich. Schreibe DNS-Hostnamen klein, entferne einen abschließenden Punkt einheitlich, parse IPv6-Literale in eckigen Klammern korrekt und lehne fehlerhafte Prozentkodierungen ab. Vergleiche niemals rohe URL-Zeichenketten. Bei `https://api.example.test@evil.test/` ist `evil.test` der Host, obwohl vor dem `@` ein vertrauenswürdiger Name steht.

Verwende `endsWith("example.test")` nicht als Prüfung der Instanz. Dadurch wird auch `notexample.test` akzeptiert. Selbst eine suffixbasierte Regel mit Trennzeichen wie `*.example.test` braucht eine Prüfung der Besitzverhältnisse. Wildcard-Subdomains enthalten oft Vorschau-Systeme, kundengesteuerte Namen, Redirectoren oder Infrastruktur, die von einer anderen Gruppe verwaltet wird.

Der Validator sollte eine begründete Entscheidung statt eines booleschen Werts zurückgeben. Betreiber müssen wissen, ob ein Herabstufen des Schemas, ein nicht genehmigter Port, eine unzulässige Methode, eine private Adresse oder ein ausgeschöpftes Redirect-Limit zur Ablehnung geführt hat. Diese Information gehört mit entfernten Tokenwerten in den Aktionsdatensatz.

Setze ein kleines, festes Redirect-Limit. Es verhindert Schleifen und macht lange Ketten sichtbar. Akzeptiere keine Anzahl, die der Agent liefert. Das Gateway bestimmt das Limit, weil es die Netzwerkaktionen kontrolliert.

## Ein gewöhnlicher Download-Ablauf kann eine privilegierte Anfrage offenlegen

Die gefährlichen Fälle sind selten als Angriffe gekennzeichnet. Oft sehen sie wie normale Komfort-Endpunkte aus, die eine URL akzeptieren oder einen Download-Ort zurückgeben.

Stell dir vor, ein Agent soll einen Bericht von einer genehmigten Abrechnungs-API abrufen. Der Agent sendet `POST /v1/exports` mit einem Bearer-Token. Die API antwortet mit einem 303 auf eine Download-URL. Das Gateway folgt automatisch und überträgt das Bearer-Token, weil sein benutzerdefinierter Header-Injektor vor dem Redirect-Hook der HTTP-Bibliothek ausgeführt wird.

Zunächst ist der Download-Host ein weiterer Dienst desselben Teams. Monate später wird die Konfiguration geändert, sodass der Export-Endpunkt einen `destination`-Parameter akzeptiert und Kunden einen Speicheranbieter verwenden können. Ein Angreifer mit Zugriff auf Berichtsparameter übergibt eine von ihm kontrollierte URL. Die genehmigte API leitet auf diese URL weiter. Die HTTP-Bibliothek behandelt den Vorgang als normalen 303, und das Gateway hat `X-Service-Token` bereits eingefügt.

Nichts Ungewöhnliches ist passiert. Die erste API-Anfrage war erlaubt, die Redirect-Syntax war gültig und das Token tauchte nie in einem Agent-Prompt auf. Der Fehler bestand darin, Zugangsdaten einzufügen, bevor das Ziel feststand.

Eine korrekte Implementierung protokolliert den 303, löst das Ziel auf, erkennt, dass für den Host keine Zielregel existiert, und stoppt. Der Betreiber sieht einen abgelehnten Redirect statt eines rätselhaften ausgehenden Aufrufs. Wenn der vorgesehene Download-Dienst Zugriff braucht, erstelle eine separate Regel für seinen exakten Host und verwende Download-Zugangsdaten, mit denen sich die Abrechnungs-API nicht aufrufen lässt.

Agenten schaffen einen weiteren Weg in diesen Fehler. Ein Agent kann eine URL über Aufgabentext, eine Repository-Konfigurationsdatei, ein API-Antwortfeld oder eine Anweisung eines Tools beeinflussen. Gehe nicht davon aus, dass eine URL von einem Entwickler stammt, nur weil sie in einer Anfrage erscheint, die dein Agent erstellt hat. Daten können sehr schnell zu Routing-Eingaben werden.

## DNS-Prüfungen müssen zum Zeitpunkt der Verbindung erfolgen

Eine reine Hostnamenprüfung verhindert keinen serverseitigen Request Forgery. Ein Hostname kann bei der Prüfung auf eine öffentliche Adresse zeigen und beim Verbindungsaufbau auf Loopback, Link-Local- oder privaten Adressraum aufgelöst werden. Die Redirect-Verarbeitung gibt einem Angreifer wiederholt Gelegenheit, diese Lücke auszunutzen.

Löse jeden genehmigten Hostnamen möglichst kurz vor dem Verbindungsaufbau auf und prüfe jede zurückgegebene Adresse gegen deine Netzwerkregeln. Lehne Loopback-Bereiche, nicht spezifizierte Adressen, Link-Local-Bereiche, private Bereiche, Multicast-Adressen und entsprechende IPv6-Bereiche ab, sofern eine Regel sie nicht ausdrücklich erlaubt. Behandle auch literale IP-Adressen in Redirect-URLs auf diese Weise.

Löse einen Hostnamen nicht einmal auf, genehmige eine Adresse und lasse anschließend einen separaten HTTP-Stack erneut auflösen. Dadurch entsteht eine Lücke zwischen Prüfung und Nutzung. Die Verbindung muss die geprüfte Adressmenge verwenden, oder der Transport muss eine verlässliche Bestätigung der Peer-Adresse liefern und eine Abweichung ablehnen. Mit Verbindungspools, Proxys und Dual-Stack-DNS ist das schwieriger, als es klingt.

Unternehmens-Proxys brauchen ein festgelegtes Ausnahmemodell. Wenn das Gateway nur eine ausdrücklich konfigurierte Proxy-Verbindung nutzt, validiere den Proxy als Netzwerk-Peer und behalte die Anwendungsregeln für das Ziel bei, bevor du die Proxy-Anfrage bildest. Erkläre nicht alle privaten Bereiche für sicher, nur weil eine Organisation private Dienstadressen verwendet. Benenne die internen Hosts und Ports, die ein Agent benötigt.

DNS-Rebinding ist ein weiterer Grund dafür, dass eine Redirect-Regel keine dauerhafte Genehmigung eines Hostnamens sein darf. Cache-Verhalten, TTLs und Resolver können unterschiedliche Antworten liefern. Triff die Entscheidung für die Verbindung, die du gleich herstellen willst, und protokolliere die ausgewählte Peer-Adresse, ohne sie als Beweis dafür zu behandeln, dass das Anwendungsziel autorisiert war.

## Cookies, signierte URLs und Bodys sind ebenfalls Zugangsdaten

Teams schützen häufig `Authorization` und lassen alle anderen ausgehenden Inhalte unangetastet. Ein Redirect kann Zugangsdaten oder sensible Daten auf viele andere Arten offenlegen.

Cookies haben Regeln für Domain und Pfad. Ein Agent-Gateway sollte sich bei maschinellen Zugangsdaten trotzdem nicht auf ein allgemeines Cookie-Jar nach Browserart verlassen. Deaktiviere Cookies standardmäßig für privilegierte Aufrufe. Wenn eine Integration sie benötigt, beschränke das Jar auf diese Integration und prüfe das Anhängen von Cookies für jedes Redirect-Ziel erneut.

Vorab signierte URLs legen die Autorisierung absichtlich in die Query-Zeichenkette. Sie sollten normalerweise ohne weitere Diensttokens funktionieren. Wenn eine Zielregel eine vorab signierte Speicher-URL erkennt, sende sie genau mit dem vorhandenen Autorisierungsmaterial der URL und einer eingeschränkten Methode, normalerweise `GET` oder `PUT`. Füge nicht aus Gewohnheit deine Standard-Header hinzu.

Auch Request-Bodys enthalten Geheimnisse. Ein JSON-Body kann ein Quellarchiv, Kundendaten oder eine undurchsichtige signierte Zusicherung enthalten. Bei 307 und 308 musst du eine ausdrückliche Regel verlangen, die die Wiederholung des Bodys an genau diesen Dienst erlaubt. Bei anderen Redirect-Codes darfst du den Body nicht stillschweigend umwandeln oder erneut senden. Der Komfort einer Client-Bibliothek ist kein Grund, sensible Inhalte zu duplizieren.

Der HTTP-Header `Referer` kann Pfade und Query-Werte offenlegen, wenn ein Client ihn hinzufügt. API-Clients sollten einen `Referer` im Allgemeinen nicht über Redirects hinweg übertragen. Entferne ebenso Header, die die ursprüngliche interne Route, Agent-Sitzung oder Benutzeridentität beschreiben, sofern die Zielregel sie nicht ausdrücklich benötigt.

Ordne Header drei Gruppen zu: Header, die immer neu erzeugt werden können, Header, die nur für ein benanntes Ziel erlaubt sind, und Header, die eine Redirect-Grenze niemals überschreiten dürfen. Das ist zuverlässiger als eine vage Liste «sensibler Header». `Content-Type` kann bei einem erlaubten Upload harmlos sein, während `X-Internal-Actor` eine Person identifizieren kann, die das nächste Ziel nie autorisiert hat.

## Protokolliere die Kette als eine Aktion mit vielen Hops

Ein Audit-Datensatz sollte die Redirect-Kette zeigen, ohne die Inhalte offenzulegen, die die Anfrage privilegiert gemacht haben. Eine endgültige URL und ein Statuscode reichen nicht aus. Sie verbergen, ob der Client einen Ursprung überschritten, die Methode geändert, die Authentifizierung entfernt oder ein verdächtiges Ziel vor dem Verbindungsaufbau abgelehnt hat.

Protokolliere die ursprüngliche Anfrageabsicht, jeden Antwortstatus, jeden ungekürzten Location-Wert nach der Entfernung sensibler Inhalte, das aufgelöste Ziel, das Ergebnis der Richtlinienprüfung, die ausgewählte Methode und die für diesen Hop verwendete Zugangsdatenklasse. Verwende eine stabile Kennung für die Zugangsdaten, niemals ein Token, Passwort oder eine vollständige signierte URL. Das Hashing einer vollständigen URL kann bei der Korrelation helfen. Ein Hash ist aber keine sichere Schwärzung, wenn die Eingabe nur wenige mögliche Werte hat.

Verknüpfe alle Hops mit einer übergeordneten Aktionskennung. So kann ein Ermittler zwischen «Der Agent hat einen Export angefordert» und «Das Gateway hat beim Export vier Netzwerkaufrufe ausgeführt» unterscheiden. Dadurch kann ein Betreiber auch eine laufende Sitzung widerrufen, sobald sich die Kette unerwartet verhält.

Ein manipulationssicheres Log liefert nachträglich wichtige Belege, stoppt aber keinen unsicheren Redirect. Die Prävention muss im Weiterleitungspfad stattfinden. Sallyport erfasst Agent-Sitzungen und einzelne Aufrufe in einem einzigen verschlüsselten, hashverketteten Audit-Log. Dadurch können redirectbewusste Aktionsdatensätze die Entscheidungskette bewahren, statt sie zu einem Endergebnis zu verkürzen.

Teste das Log mit absichtlich abgelehnten Fällen. Löse einen Cross-Origin-302, einen Redirect von HTTPS zu HTTP, einen 307 nach einem POST, ein fehlerhaftes Location-Feld und ein Ziel aus, das auf Loopback aufgelöst wird. Wenn diese Datensätze einem Prüfer nicht erklären, warum das Gateway gestoppt hat, verbessere das Ereignisschema, bevor ein Vorfall dich dazu zwingt.

## Mache Redirect-Verhalten zum Teil des Tool-Vertrags

Ein Tool, das eine HTTP-API aufruft, muss seinen Nutzern mitteilen, ob es Redirects verfolgt und unter welchen Bedingungen. «Verwendet Standard-HTTP» ist kein Vertrag. Das Verhalten unterscheidet sich je nach Bibliothek und ändert sich, wenn jemand den Client austauscht, einen Proxy hinzufügt oder die Authentifizierung in Middleware verschiebt.

Schreibe Tests gegen ein lokales Redirect-Testsystem mit getrennten Endpunkten. Das Testsystem sollte kontrollierte Statuscodes und Location-Werte zurückgeben und anschließend eingehende Methode, Body-Digest, Host und Header erfassen. Deine Assertions sollten beweisen, dass ein nicht genehmigtes Ziel keinen Zugangsdaten-Header erhält, dass ein 303 keinen POST-Body wiederholt und dass ein erlaubter 307 nur die Header und den Body sendet, die die Regel zulässt.

Lass den Agenten keine Redirect-Richtlinie als Tool-Argument auswählen. Ein Agent kann eine bekannte Integration anfordern und gewöhnliche Anfrageparameter liefern. Das Gateway entscheidet, ob für diese Integration Redirects verfolgt werden, wie viele Hops erlaubt sind und welche Zugangsdaten verwendet werden dürfen. Diese Trennung verhindert, dass eine Prompt-Injection zu `follow_redirects=true` wird.

Wähle für die erste Implementierung einen bewusst engen Vertrag: Folge genehmigten HTTPS-Redirects nur bei GET und HEAD, füge Zugangsdaten erst nach der Zielprüfung und abhängig vom Ziel ein und lehne jeden weitergeleiteten Schreibvorgang ab. Füge Ausnahmen erst hinzu, wenn du den Ablauf des Anbieters, die Zielgrenze, das Methodenverhalten und den Audit-Datensatz erklären kannst. Einige ausdrückliche Ablehnungen werden Entwickler ärgern. Ein Token, das an einen Angreifer gesendet wird, ärgert jedoch alle deutlich mehr.