Wie Cookie Jars von Agenten unbeabsichtigte Sitzungen behalten

HTTP-Clients lassen Cookies harmlos wirken, weil Browser uns daran gewöhnt haben. Ein autonomer Agent verändert jedoch die Folgen. Eine Response mit Set-Cookie kann dem nächsten Request eine Berechtigung geben, die der Agent nie angefordert und nie angezeigt hat und die er möglicherweise behält, nachdem sich die ursprünglichen Zugangsdaten geändert haben.

Behandle einen Cookie Jar als Authentifizierungsspeicher, nicht als Transportdetail. Wenn eine API Cookie-Sitzungen verlangt, gib dem Jar einen Namen, eine kurze Lebensdauer und eine beobachtbare Grenze. Falls nicht, schalte ihn aus. Ich habe zu viele Incident-Untersuchungen erlebt, die damit begannen, dass jemand darauf bestand, der Request habe keine Zugangsdaten enthalten, während der Client stillschweigend welche im Cookie-Header mitsendete.

Ein Set-Cookie-Header kann zu einer zweiten Zugangsdaten werden

Ein Server sendet Set-Cookie in einer Response. Ein Client mit einem Jar kann diesen Wert später in einem Cookie-Header senden. Identifiziert der Wert eine serverseitige Sitzung, ist er praktisch gesehen eine Zugangsdaten. Dass er erst nach einem authentifizierten Request ankam, macht ihn nicht weniger geeignet, den nächsten zu autorisieren.

Das überrascht Teams, weil sie sich auf das Geheimnis konzentrieren, das sie bewusst angegeben haben: ein Bearer-Token, ein Basic-Auth-Passwort oder einen signierten Request. Sie prüfen, woher dieses Geheimnis stammt und ob es den Agenten erreicht. Dann akzeptiert eine HTTP-Bibliothek ohne eine ausdrückliche Zeile Anwendungscode ein Sitzungs-Cookie. Der nächste Request kann funktionieren, obwohl der ursprüngliche Authorization-Header verschwunden ist.

Entscheidend ist der Unterschied zwischen dem Einfügen von Zugangsdaten und der Fortsetzung einer Sitzung. Beim Einfügen von Zugangsdaten hängt der Client einem Request ein bekanntes Geheimnis an. Bei der Sitzungsfortsetzung stellt der Server ein neues Geheimnis aus und fordert den Client auf, es später erneut zu senden. Beides kann Arbeit autorisieren. Nur eines davon ist in den Aufrufargumenten eines Werkzeugs normalerweise sichtbar.

RFC 6265 beschreibt diesen Austausch als Zustandsverwaltung: Der User Agent speichert Cookie-Informationen aus Set-Cookie und sendet passende Cookies in Cookie zurück. Diese Formulierung ist bewusst weit gefasst, weil Webbrowser sie brauchen. Ein Agent-Client sollte nicht die Browser-Gewohnheit übernehmen, Zustand einfach zu behalten, nur weil das HTTP-Protokoll es erlaubt.

Ein Cookie verändert auch die Bedeutung einer fehlgeschlagenen Token-Rotation. Angenommen, ein Agent ruft eine API mit einem Token auf, erhält sid=... und verliert später den Zugriff auf dieses Token. Akzeptiert die API das Sitzungs-Cookie allein, hat der Agent weiterhin einen Weg zum Konto. Die Rotation hat die bekannte Zugangsdaten behoben, die ausgestellte Sitzung aber nicht beendet. Das ist eine Frage der serverseitigen Sitzungsverwaltung und der clientseitigen Eindämmung. Beides musst du behandeln.

Der Client entscheidet, ob versteckter Zustand entsteht

Set-Cookie bewirkt allein nichts. Ein Client muss sich entscheiden, es zu behalten. Diese Entscheidung kann sich an überraschend vielen Stellen verbergen: in einem wiederverwendbaren HTTP-Client, dem Cookie-Manager einer Bibliothek, einem Wrapper um fetch, einem Test-Harness oder einer Redirect-Implementierung.

Manche verbreiteten Clients behalten Cookies erst, wenn du ihnen ein Jar gibst. Andere behalten sie, wenn Code einen standardmäßigen Cookie-Handler anhängt. Ein gemeinsamer Client kann so versehentlich auch ein gemeinsames Jar schaffen. Leite das Verhalten nicht aus der API-Dokumentation oder daraus ab, dass ein Aufruf erfolgreich war. Prüfe die Client-Erstellung und führe einen Test aus.

Für einen sauberen Test brauchst du einen Server unter deiner Kontrolle oder einen ungefährlichen Testendpunkt. Die erste Response sollte ein eindeutig benanntes Cookie setzen, und der zweite Request sollte die empfangenen Header melden. Das Ergebnis muss zwei getrennte Fragen beantworten:

1. Hat der Client das Cookie nach dem Empfang von Set-Cookie behalten?
2. Hat der Client dieses Cookie in einem späteren passenden Request gesendet?

Mit curl macht eine ausdrücklich angegebene Cookie-Datei den Zustand sichtbar:

curl -i -c /tmp/agent-cookie-test.txt https://test.example/session/start
HTTP/1.1 200 OK
Set-Cookie: agent_probe=run-7f3; Path=/; Secure; HttpOnly

curl -i -b /tmp/agent-cookie-test.txt https://test.example/session/echo
HTTP/1.1 200 OK

{"received_cookie":"agent_probe=run-7f3"}

Die Datei ist der Kern der Übung. Der erste Befehl kann keine versteckte Sitzung erzeugen, wenn nichts seine Response behält. Der zweite kann keine wiedergeben, wenn er die Datei nicht erhält. Gibt dein Agent-Werkzeug dem Gegenstück zu dieser Datei ein namenloses prozessweites Zuhause, hast du eine Sitzungsgrenze geschaffen, die bei einer Prüfung niemand nachvollziehen kann.

Wiederhole den Test über genau den Runtime-Pfad, den dein Agent nutzt, einschließlich Request-Wrapper und Redirect-Einstellungen. Ein direkter curl-Test belegt curl, nicht dein Werkzeug. Halte fest, ob das Jar leer startet, wo es liegt und wodurch es gelöscht wird.

Wiederverwendung zwischen Aufrufen ist etwas anderes als zwischen Läufen

Einige Aufrufe innerhalb einer Aufgabe müssen möglicherweise eine Sitzung teilen. Diese Sitzung in einer späteren Aufgabe wiederzuverwenden, ist eine eigene Entscheidung. Werden diese beiden Lebensdauern zusammengelegt, wird aus einer kleinen Bequemlichkeit eine dauerhafte Berechtigung.

Nutze drei Grenzen, wenn du das Verhalten bewertest. Frage erst, ob ein einzelner Request Cookies überhaupt braucht. Frage dann, ob zusammenhängende Aufrufe in einem Agent-Prozess sie benötigen. Frage zuletzt, ob ein frischer Prozess, eine fortgesetzte Aufgabe, andere Zugangsdaten oder eine andere Person sie jemals übernehmen sollen. Jedes Ja braucht einen klar benannten Grund.

Ein In-Memory-Jar, das mit dem Prozess verschwindet, lässt sich leichter eindämmen als eine Datei in einem Projektverzeichnis. Eine Datei kann einen Absturz, einen Wiederholungsversuch, einen kopierten Workspace oder einen Wechsel der Person überdauern, die die Aufgabe ausführt. Sie kann auch in einem Support-Archiv oder in der Statusausgabe der Versionsverwaltung landen. HttpOnly schützt eine Cookie-Datei nicht vor dem Client, der sie geschrieben hat. Es beschränkt nur den Zugriff über Browser-Skripte.

Ich bevorzuge für jeden Agent-Lauf ein frisches Jar, selbst wenn dasselbe Modell einen Folge-Prompt erhält. Die Kontinuität des Modellgesprächs ist kein Grund, HTTP-Berechtigungen zu behalten. Braucht der Folgeaufruf die Sitzung wirklich, sollte der Betreiber einen fortgesetzten Lauf innerhalb derselben benannten Grenze freigeben, statt den letzten Lauf stillschweigend eine nutzbare Sitzung hinterlassen zu lassen.

Auch parallele Aufrufe brauchen eine eigene Entscheidung. Ein gemeinsames Jar kann reihenfolgeabhängiges Verhalten erzeugen: Request A erhält ein Cookie, Request B startet Augenblicke später und bekommt eine Sitzung, die er nie aufgebaut hat. Das macht Reproduktionen unerquicklich. Gib parallelen Aufgaben getrennte Jars, es sei denn, die API verlangt eine koordinierte Sitzung und die Aufgabe besitzt sie ausdrücklich.

Der Geltungsbereich von Cookies entspricht nicht der erwarteten Sicherheit

Cookie-Attribute begrenzen die Zustellung, machen eine Sitzung aber nicht harmlos. Lies sie als Routing-Anweisungen vom Server an den Client und entscheide dann, ob dein Client sie überhaupt beachten sollte.

Ein Host-only-Cookie geht an genau den Host zurück, der es ausgestellt hat. Ein Cookie mit Domain=example.com kann an passende Subdomains wie api.example.com und admin.example.com zurückgehen. RFC 6265 sagt außerdem, dass ein User Agent einen Domain-Wert ablehnt, der nicht zum Ursprungs-Host passt. Das löst jedoch nicht den gewöhnlichen Fehler, jeder Subdomain unter einer breit gefassten Unternehmensdomain zu vertrauen.

Path=/billing beschränkt ein Cookie auf Requests, deren Pfade zum Cookie-Pfad passen. Es hindert einen Server auf einem anderen erlaubten Pfad nicht daran, dasselbe Cookie zu akzeptieren, wenn es ihn über einen anderen Weg erreicht, und es ersetzt keine Berechtigungsprüfungen. Verwende Path in Entwurfsdiskussionen nicht als Sicherheitsgrenze. Es ist eine Regel dafür, wann der Client sendet.

Secure weist den Client an, das Cookie nur über eine sichere Verbindung zu senden. HttpOnly weist einen Browser an, es nicht über Script-APIs offenzulegen. Beide Attribute sind gute Hygiene, doch keines begrenzt Aufbewahrung, Aufgabenteilung, Redirects oder die Fähigkeit des Agenten, das Cookie zu nutzen. SameSite steuert vor allem den Site-Kontext im Browser. Ein Nicht-Browser-Agent sollte es nicht als Beleg dafür nehmen, dass ursprungsübergreifendes Verhalten sicher ist.

Es gibt noch einen leicht zu übersehenden Fehler: Roh-Header beim Debuggen zu protokollieren. Ein Redaktor, der Authorization entfernt, aber Cookie stehen lässt, hat die Authentifizierung nicht redigiert. Protokolliere das Vorhandensein eines Cookies, seinen Namen, die deklarierte Domain und Path, den Ablauf-Typ und, falls nötig, einen nicht umkehrbaren Korrelationsbezeichner. Protokolliere nicht den Wert.

Redirects machen Cookie-Tests zu Zieltests

Ein Redirect ist nicht bloß eine andere URL. Er kann verändern, welcher Server den nächsten Request sieht, ob Zugangsdaten erhalten bleiben und welche Response Zustand setzen darf. Teste ihn als eigenen Ablauf.

Beginne mit einem Endpunkt, der nach dem Setzen eines Cookies einen Redirect zurückgibt. Teste dann jedes Ziel getrennt: denselben Host, eine erlaubte Subdomain, eine benachbarte Subdomain und einen unabhängigen Host. Beobachte sowohl ausgehendes Cookie als auch ausgehendes Authorization. Unterschiedliche HTTP-Stacks treffen unterschiedliche Entscheidungen, und ein Wrapper kann die Standardwerte überschreiben.

Ein nützliches Fixture erzeugt einen kurzen Trace wie diesen:

request 1  GET https://api.example.test/start
response 1  302 Location: https://api.example.test/next
            Set-Cookie: probe=A; Path=/; Secure
request 2  GET https://api.example.test/next
            Cookie: probe=A
response 2  200

Ändere dann nur den Location-Host. Leitet api.example.test zu reports.example.test weiter, darf ein Host-only-Cookie nicht folgen. Ein Domain-begrenztes Cookie darf es möglicherweise. Dein Test sollte das erwartete Ergebnis festhalten, bevor er läuft, denn ein Trace, der dich überrascht, ist der Sinn der Sache und keine Unannehmlichkeit, die man überdecken sollte.

Lehne ursprungsübergreifende Redirects ab, wenn der API-Vertrag sie nicht verlangt. Musst du ihnen folgen, vergleiche alten und neuen Ursprung, entferne Request-Zugangsdaten nach einer ausdrücklichen Regel und lass eine frische Response neuen Cookie-Zustand aufbauen. Nutze niemals eine breite automatische Redirect-Richtlinie und nimm an, der Cookie-Bereich werde dich retten.

Ein Sitzungstest muss Zugangsdaten und Prozesse überqueren

Der Test, der den kostspieligen Fehler erkennt, ist nicht request eins, request zwei. Er überschreitet die Grenzen, die dein Betriebsmodell angeblich durchsetzt.

Baue einen ungefährlichen Endpunkt, der erst nach dem Empfang einer gewählten Kennzeichnung für Zugangsdaten ein Cookie ausstellt. Bei jedem autorisierten Request soll er die Sitzungskennzeichnung zurückgeben. Führe dann diese Abfolge aus:

1. Starte Lauf A mit Zugangsdaten A und erhalte sid=A.
2. Führe einen zweiten Aufruf ohne Zugangsdaten A, aber mit demselben Jar aus.
3. Starte Lauf B mit Zugangsdaten B und einem leeren Jar.
4. Starte Lauf C ohne Zugangsdaten und mit einem beliebigen gespeicherten Jar aus Lauf A.
5. Widerrufe Zugangsdaten A oder mache ihre Sitzung auf dem Testserver ungültig, dann versuche es erneut mit dem Jar aus Lauf A.

Die erwartete Ausgabe ist eine Richtlinienentscheidung, keine universelle Antwort. Eine Cookie-basierte API kann den zweiten Aufruf innerhalb von Lauf A absichtlich erlauben. Lauf B darf den Zustand von A nicht sehen. Lauf C sollte fehlschlagen, sofern du Persistenz nicht ausdrücklich freigegeben hast. Nach dem Widerruf sollte der Testserver die alte Sitzung ablehnen, wenn dein Bedrohungsmodell verlangt, dass eine Token-Rotation den aktiven Zugriff beendet.

Schreibe die Erwartung neben den Test, statt sie im Gedächtnis eines Entwicklers zu vergraben. Eine knappe Tabelle in einem Testkommentar genügt:

run A, same jar, no bearer header: allowed only if session continuation is intended
run B, fresh jar, credential B: must identify as B
run C, persisted jar, no credential: rejected
run A after session invalidation: rejected

Damit wird ein Unterschied sichtbar, den Teams oft verwischen: Das Widerrufen einer Start-Zugangsdaten und das Widerrufen ausgestellter Sitzungen sind nicht dieselbe Operation. Der API-Verantwortliche muss Sitzungen ungültig machen. Der Verantwortliche für das Agent-Werkzeug muss vermeiden, sie über ihre freigegebene Lebensdauer hinaus zu bewahren. Keine Seite kann annehmen, dass die andere es erledigt hat.

Implizite Jars deaktivieren, sofern die API keines braucht

Die sinnvolle Voreinstellung für eine HTTP-Aktion eines Agenten ist: keine Cookie-Speicherung und kein automatischer Cookie-Header. Eine Response kann weiterhin Set-Cookie enthalten. Halte fest, dass dies passiert ist, falls dein Audit-Konzept es erlaubt, und verwirf es dann. Beim nächsten Aufruf sollte die API ihre normale Request-Zugangsdaten nutzen.

Diese Empfehlung ist unpopulär, weil viele webnahe APIs nach einem Login-Endpunkt nur funktionieren, wenn der Client ein Cookie behält. Menschen greifen zu einem gemeinsamen Jar, weil es Demos und Integrationstests bestehen lässt. Das ist die falsche Lösung, wenn die dokumentierte API Bearer-Tokens oder einen anderen requestbezogenen Mechanismus unterstützt. Du bewahrst unsichtbare Berechtigungen, um einen Integrationspfad auszugleichen, den du nicht hättest wählen sollen.

Verlangt die API wirklich Cookies, mache das Jar zu einer ausdrücklichen Fähigkeit. Der Aufrufer sollte zu Beginn des Laufs ein benanntes, leeres Jar auswählen. Das Werkzeug sollte melden, wenn die Response ein Cookie erzeugt oder ersetzt, und das Jar sollte am Ende verschwinden. Lass keinen Endpunkt jeden Agenten in eine dauerhafte Sitzung aufnehmen, nur indem er einen Header zurückgibt.

Eine minimale Richtlinie kann einfach genug für eine Prüfung sein:

cookie mode: disabled by default
allowed mode: ephemeral per agent run
persistence: prohibited
sharing: prohibited between agent processes
redirects: same-origin only unless the action definition permits another origin
logging: record cookie names and scope, never values

Das ist absichtlich weniger ausgeklügelt als eine Regel-Engine. Eine ausgeklügelte Cookie-Richtlinie sammelt Ausnahmen, bis niemand mehr sagen kann, welche Aktion welchen Zustand mit sich führt. Wenige Entscheidungen geben Prüfenden eine echte Antwort.

Den Zustandswechsel prüfen, nicht nur den Request

Ein Prüfpfad, der URLs und Statuscodes auflistet, übersieht das nützlichste Ereignis: Eine Response hat verändert, was spätere Aufrufe tun können. Erfasse Änderungen des Cookie-Zustands als eigenständige Ereignisse, ohne das Sitzungsgeheimnis selbst zu behalten.

Bei jeder HTTP-Aktion sollte der Datensatz diese Fragen beantworten können: Hat der Request Cookies gesendet, hat die Response welche gesetzt oder gelöscht, welches Jar hat sie erhalten, gehörte das Jar zu diesem Lauf und gab es einen Redirect? Cookie-Namen und Attribute reichen für die Diagnose normalerweise aus. Speichere Werte nur, wenn du ein überzeugendes Sicherheitskonzept für ihren Schutz und ihr Ablaufen hast. Die meisten Agent-Werkzeuge brauchen das nicht.

Wenn ein Agent Sallyport für HTTP-Aktionen nutzt, kann der Tresor die konfigurierte API-Zugangsdaten während der Ausführung außerhalb des Agenten halten. Diese Trennung hilft nur, wenn der HTTP-Client zurückgegebenen Sitzungszustand mit derselben Skepsis behandelt, statt ihn stillschweigend in einen weiteren Zugangsdatenpfad zu verwandeln.

Prüfdatensätze brauchen zudem eine für Menschen lesbare Laufgrenze. Widerruft ein Betreiber einen Agent-Lauf, sollte klar sein, ob das nur künftige Aufrufe über die konfigurierte Zugangsdaten verhindert oder auch den an den Lauf gebundenen Sitzungszustand löscht. Falls nicht, sage es deutlich und mache den verbleibenden Zustand für einen späteren Prozess unzugänglich.

Der erste Test, den ich hinzufügen würde, ist absichtlich langweilig: Ein Endpunkt sendet Set-Cookie, der nächste bestätigt, ob es angekommen ist, und ein neuer Agent-Prozess wiederholt den Aufruf. Führe ihn aus, bevor du Wiederholungsversuche, Redirects, Browser-Kompatibilität oder einen persistenten Cache hinzufügst. Ist die Antwort aus dem Trace nicht offensichtlich, hat dein Client mehr Berechtigung, als seine Schnittstelle zugibt.

API-Autoren können Agenten sicherer machen, ohne zu raten

API-Autoren sollten dokumentieren, ob Cookies erforderlich sind, was sie erzeugt, welche Lebensdauer sie haben sollen und wie Clients sie ungültig machen. Ein Satz wie «Verwende diesen Endpunkt nach dem Login» reicht nicht, wenn ein Login eine Sitzung ausstellen kann, die länger besteht als die Zugangsdaten, mit denen sie erhalten wurde.

Biete nach Möglichkeit eine requestbezogene Alternative an. Bearer-Authentifizierung, signierte Requests oder ein eng begrenztes Aktions-Token machen das Client-Verhalten oft leichter prüfbar, weil jeder Aufruf seine Berechtigung offen mitführt. Das macht diese Mechanismen nicht automatisch sicher, vermeidet aber einen zusätzlichen Wiederholungskanal, der im Client-Speicher verborgen ist.

Stellst du ein Sitzungs-Cookie aus, sorge dafür, dass das Ungültigmachen von Sitzungen funktioniert, und teste es. Eine Token-Rotation ohne Sitzungsungültigmachung gibt Betreibern ein unangenehmes falsches Gefühl, alles erledigt zu haben. Akzeptierst du sowohl ein Bearer-Token als auch ein Sitzungs-Cookie, lege fest, welches gewinnt, wenn sie widersprechen, und zeige diese Entscheidung in der Diagnoseausgabe.

Sag Entwicklern von Agenten nicht, sie sollten Browser nachahmen, es sei denn, dein Dienst hängt wirklich von Browser-Verhalten ab. Agenten führen wiederholte, unbeaufsichtigte Aufrufe aus und arbeiten oft über verschiedene Aufgaben hinweg. Der langlebige Komfortzustand eines Browsers ist dafür eine schlechte Voreinstellung.

Die sichere Voreinstellung ist ein frischer Client ohne gemerkte Sitzung

Cookie-Unterstützung ist nicht schlecht, unzugeordneter Zustand ist es. Ein kurzlebiges, ausdrücklich ausgewähltes Jar kann der richtige Weg sein, eine API-Aufgabe mit mehreren Aufrufen abzuschließen. Ein Jar, das erscheint, weil jemand einen HTTP-Client wiederverwendet hat, ist ein Unfall, der nur auf den passenden Wiederholungsversuch, Redirect oder eine passende Zugangsdaten-Rotation wartet.

Mach die Sitzungsgrenze in der Werkzeugschnittstelle und im Prüfdatensatz sichtbar. Beweise sie dann mit dem laufübergreifenden Test. Der Request-Trace sollte einer prüfenden Person erlauben, auf jeden Zugangsdatenpfad zu zeigen, den der Agent hatte, einschließlich derer, die der Server zurückgeben wollte.