Zusammenfassung

  • RFC 10025 regelt, wann ein User Agent Cookie-Zustand speichern und zurücksenden kann. Die fachliche Bedeutung des Werts und die Annahme einer Sitzung entscheidet der Dienst.
  • Host-only, Domain, Pfad, Secure, HttpOnly, SameSite und die Präfixe begrenzen verschiedene Übergaben. Sie bilden keine allgemeine Genehmigungskette.
  • Nur getrennte Nachweise für Sitzungslebenszyklus, Anfragekontext, Berechtigung, Frische, Commit und beobachtete Wirkung erlauben eine belastbare Untersuchung.

Ein Administrator beantragt die Freigabe eines neuen Zugangs. Der Dienst sieht eine bekannte Session und führt den Vorgang aus. Später ist umstritten, ob der Zugang tatsächlich autorisiert war. Das Cookie kann bei der Rekonstruktion helfen, aber es beantwortet den Streit nicht. Es ist kein Protokoll über Delegation, Rolle, Bestätigung, Sperrfrist oder das Ergebnis im Zielsystem.

RFC 10025 belässt die Bedeutung des Cookie-Werts bewusst bei der Anwendung. Ein Browser speichert Name, Wert und Attribute wie Ablauf, Domain, Pfad, Host-only-, Secure-, HTTP-only- und Same-site-Status nach seinen Regeln und kann Einträge ignorieren oder verwerfen. Ein Server kann daher nicht aus der fortdauernden Existenz im Browser schließen, dass seine eigene Annahmeregel fortbesteht.

Ohne Domain ist ein Cookie host-only; mit einer zulässigen Domain kann seine Auswahl breiter sein. Die Public Suffix List hilft, zu weit gefasste Domain-Zuweisungen abzuweisen. Das ist eine Zustellungsgrenze. Es ist weder eine Eigentumsbehauptung noch ein Beweis, dass jeder passende Host derselben organisatorischen Vertrauens- und Berechtigungsdomäne angehört. Der Pfad hat dieselbe begrenzte Funktion. Er steuert Auswahl, nicht Autorisierung.

Secure und HttpOnly sind ebenfalls präzise, aber begrenzte Kontrollen. Secure beschränkt Rücksendung auf die sichere Verbindungsvorstellung des User Agents. HttpOnly begrenzt nicht-HTTP-Schnittstellen; der Browser kann ein anwendbares HttpOnly-Cookie dennoch mit einer HTTP-Anfrage senden. Die Werte sind damit oft gerade dann relevant, wenn ein Skript sie nicht auslesen kann. Das ist die von RFC 10025 benannte ambient authority: Eine fremd ausgelöste Navigation kann vorhandenen Zustand mitbringen.

SameSite reduziert bestimmte Cross-site-Fälle und ist sinnvoll. Lax wird im RFC aber als Defence in Depth gegen bestimmte CSRF-Fälle, nicht als allgemeiner robuster Schutz beschrieben; die Default-Kompatibilität kennt zudem Ausnahmen für kürzlich gesetzte Cookies. Sensible Aktionen brauchen deshalb eine eigene Kontextentscheidung und, je nach Risiko, gebundene Anti-forgery-Nachweise, erneute Anmeldung, Grenzen, Wartezeit oder Vier-Augen-Freigabe.

__Secure- und __Host- helfen schon bei der Ausstellung. Sie verlangen sichere Herkunft und Secure, bei Host zusätzlich Path=/ und keine Domain. Sie können keine Sitzung widerrufen, eine Rollenzuordnung prüfen oder eine Auszahlung abstimmen. Ihr Nutzen wächst, wenn man genau diese Abgrenzung nicht verwischt.

Die Serverentscheidung beginnt erst nach dem Parsen. Eine Session kann abgelaufen, nach einer Wiederherstellung ersetzt, widerrufen oder für einen erhöhten Vorgang ungeeignet sein. Gegen Session Fixation helfen Rotation und Ablehnung alter Kennungen beim Übergang der Autorität. Eine akzeptierte Session ist anschließend nur Voraussetzung, nicht Freigabe: Objekt, Rolle, Mandat, Wertgrenze, Aktualität und Bestätigung bleiben zu prüfen.

Auch eine erfolgreiche Antwort ist nicht automatisch die Wirkung. Sie kann einen Auftrag annehmen, eine lokale Buchung vornehmen oder asynchrone Arbeit einreihen. Ein prüfbarer Vorgang führt daher sichere Referenzen durch die Kette: Browserauswahl, Sessionannahme, Kontextprüfung, Richtlinienentscheidung, Commit, Zielsystembeobachtung. So kann eine Korrektur die richtige Schicht treffen, ohne frühere Tatsachen umzuschreiben.

Quellen