Cookie-Flags mit Absicht

Dein Server beendet seine Sessions jetzt. Das Cookie, das die ID trägt, hat sich seit HTTP with Python nicht geändert. Eine Anmeldung antwortet immer noch mit diesem Header-Wert, wobei die ID 22 Zeichen hat:

session=<id>; HttpOnly; Max-Age=3600; Path=/

Diese Attribute lassen einem Browser die Freiheit, drei Dinge mit dem Cookie zu tun. Er darf es über einfaches HTTP senden, wo jeder auf dem Netzwerkweg es lesen kann. Er darf es mit einem Formular mitsenden, das eine Seite auf einer anderen Website an die Leseliste schickt. Und er darf ein zweites Cookie mit demselben Namen von einem benachbarten Host annehmen und auch dieses senden, und das war der erste Weg aus Lektion 1.

Vier Anweisungen

Ein Cookie-Attribut ist eine Anweisung an den Browser, der das Cookie speichert. Diese Lektion setzt vier davon mit Absicht.

„Eine andere Website“ hat eine genaue Bedeutung. Eine Site ist das Schema plus die registrierbare Domain, der Teil eines Hostnamens, den jemand registriert hat, hier reading.example. Also sind https://notes.reading.example und https://reading.example dieselbe Site. Deshalb tut SameSite nichts gegen den benachbarten Host aus Lektion 1. Das Präfix im nächsten Abschnitt tut es, und Kapitel 8 nimmt sich Anfragen von derselben Site vor.

SameSite hat zwei weitere Werte. Strict würde das Cookie auch zurückhalten, wenn ein Leser von einer anderen Website aus einem Link zur Liste folgt, sodass er abgemeldet ankäme. Dieser Dienst wählt es nicht. None verlangt gar keinen Schutz.

Das Präfix __Host-

Auch der Name des Cookies kann eine Regel tragen. Ein Browser weigert sich, ein Cookie zu speichern, dessen Name mit __Host- beginnt, es sei denn, das Cookie hat Secure, hat Path=/, hat kein Domain und kam über HTTPS. Ein Cookie, das eine Seite auf notes.reading.example für die ganze Domain setzt, braucht ein Attribut Domain, also kann es nie __Host-session heißen. Kein benachbarter Host kann der Leseliste ein Cookie mit diesem Namen unterschieben.

Der Server erledigt seinen Teil, indem er nur diesen Namen liest. Sobald SESSION_COOKIE "__Host-session" ist, bedeutet ein Cookie namens session für session_id_from nichts mehr, egal wer es untergeschoben hat.

Eine Ausnahme wird beendet

HTTP with Python hat Secure in Lektion 7.1 weggelassen, weil sein Server auf deinem eigenen Computer einfaches HTTP sprach. Diese Ausnahme endet hier. Ein Dienst, der hinter HTTPS laufen wird, setzt es immer.

pl_sec.py spricht weiterhin einfaches HTTP mit deinem Server auf 127.0.0.1. Über einfaches HTTP zu jeder anderen Maschine hält ein Browser ein Secure-Cookie zurück. Manche Browser machen eine Ausnahme für einen Server auf deinem eigenen Computer, die nur für die Entwicklung gedacht ist. Das Werkzeug ist kein Browser: Es baut den Header Cookie von Hand, und ab dieser Lektion sagt es das direkt unter seiner ersten Zeile:

pl_sec sends the __Host-session cookie by hand; a browser would not send it over plain HTTP

Wer gehorcht

Der Server schreibt nur Anweisungen. Ein Test kann prüfen, dass sie geschrieben werden. Ob sie befolgt werden, entscheidet der Browser, und nirgends auf dieser Website prüft ein Browser diese Flags. Ein Programm, das kein Browser ist, kann jeden beliebigen Header Cookie senden, über jede Verbindung. Kapitel 8 schreibt den Teil eines Browsers, der entscheidet, wann ein Cookie gesendet wird.

Das Cookie, auf das du hinarbeitest

Wenn max_age standardmäßig ABSOLUTE_LIMIT ist, vergisst ein Browser das Cookie, wenn das absolute Limit des Servers die Session ohnehin beenden würde. Sobald die Flags gesetzt sind, antwortet eine Anmeldung mit:

__Host-session=<id>; HttpOnly; Max-Age=28800; Path=/; SameSite=Lax; Secure

SimpleCookie schreibt die Attribute in alphabetischer Reihenfolge, egal in welcher Reihenfolge du sie setzt, und ein Flag wie Secure ist ein bloßes Wort ohne Wert.

import http.cookies

cookie = http.cookies.SimpleCookie()
cookie["__Host-session"] = "abc"
cookie["__Host-session"]["path"] = "/"
cookie["__Host-session"]["secure"] = True
cookie["__Host-session"]["samesite"] = "Lax"
print(cookie["__Host-session"].OutputString())

Die Abmeldung braucht keine Änderung. Das Cookie, das eine Session beendet, kommt aus derselben Funktion, session_cookie("", max_age=0), also hat es denselben Namen und dieselben Flags. Das muss es auch: Ein Browser ignoriert ein __Host--Cookie, dem sie fehlen, und das gilt auch für das, das löscht.

Schreib zuerst den Angriff

Der Angriff ist ein Browser, der tut, was das nackte Cookie erlaubt, also liest der Test die Anweisungen. Melde dich über reading_server.handle(...) als ana an, sichere den Status 200 zu und nimm den Text in response["headers"]["set-cookie"]. Sichere zu, dass er mit __Host-session= beginnt, dass Secure, HttpOnly, SameSite=Lax und Path=/ darin vorkommen und dass Domain nicht vorkommt. Führ python -m pytest -q aus: Es endet mit 1 failed, 10 passed.

Deine Aufgabe

1. Schreib in tests/test_attacks.py test_attack_session_cookie_carries_its_flags() und sieh zu, wie er fehlschlägt.

2. Setz SESSION_COOKIE = "__Host-session".

3. Setz in session_cookie secure auf True und samesite auf "Lax", auf dieselbe Weise, wie httponly und path gesetzt werden, und ändere den Standardwert von max_age auf ABSOLUTE_LIMIT. Setz keine Domain.

4. Nenne in Zeile F4 von SECURITY.md deinen Test und setz den Status auf closed in 4.4.

Führ python -m pytest -q noch einmal aus. Es endet mit 11 passed. Deine zwei früheren Tests dieses Kapitels brauchten keine Änderung, weil steps.cookie_pair den Namen des Cookies nie ausschreibt.

Klicke dann auf Check my work. Die drei Reparaturen dieses Kapitels sind an ihrem Platz. Die nächste Lektion setzt sie zu einer Richtlinie zusammen und kümmert sich um die Sessions, zu denen niemand zurückkommt.