🏆Abschlussprojekt: Projekt: Tokens, denen der Server vertrauen kann

signing.py kann ein Token ausgeben, eins lesen und einen Schlüssel ersetzen. reading_server.py benutzt davon noch nichts: Die Schreibrouten akzeptieren immer noch zwei Strings aus sample_state(). Dieses Projekt verbindet beides und entfernt die Strings. Das muss der fertige Server tun:

Sieh nach, wo du stehst:

python pl_sec.py forged-token

Es meldet sich als ben an, bittet um ein Token und probiert dann Tokens aus, die nicht funktionieren dürfen. Heute erzählen zwei Zeilen die Geschichte:

ben asks for a token, with the cookie  POST /tokens  -> 404
a token that was once in the source code  POST /books -> 201  accepted

Woher ein Token jetzt kommt

Ein Leser meldet sich an, was ihm die Session aus Kapitel 4 gibt, und sendet dann POST /tokens mit dem Session-Cookie. Die Session beweist, wer er ist. Das Token ist das, was ein Programm danach sendet, ohne Cookie und ohne Passwort.

current_session(request, state) findet die Session. Eine Besucher-Session hat keinen Benutzer, also bekommt sie dieselbe 401 wie gar keine Session. Diese 401 trägt die Basic-Aufforderung von /login, weil ein Client durch die Anmeldung die Session bekommt, die ihm fehlt.

can_write stand früher neben jedem festen Token. Jetzt kommt es aus state["writers"], einem Set von Namen, das sample_state() schon hat: Das Token sagt user in state["writers"]. Ein Token trägt diese Antwort so, wie sie war, als das Token erzeugt wurde. Ein Benutzer, der aus dem Set entfernt wird, schreibt weiter, bis das Token abläuft.

Meilensteine

1. Schreib den Angriff. test_attack_token_from_the_source_is_refused baut seinen Zustand mit steps.keyed_state() auf, das ist sample_state() mit dem Testschlüssel in state["keys"]. Ein Test führt main nie aus, also würde sonst nichts Schlüssel dort hineinlegen. Die Vorbedingung ist eine Anmeldung, die funktioniert; der Angriff ist ein POST /books mit Bearer tok-ana-writes-7Qx2. Führ python -m pytest -q aus: 1 failed, 14 passed, weil der String die Route immer noch öffnet.

2. Tokens ausgeben. Schreib token_response, füge handle den Zweig für tokens hinzu und nimm tokens in die Regel für no-store auf: Ein Token ist ein Berechtigungsnachweis, und kein Cache darf eins behalten.

3. Tokens prüfen. Schreib token_claims und schreib write_error so um, dass es allein anhand der Claims entscheidet. Dein Test läuft durch.

4. Die Strings entfernen. Lösche den Eintrag "tokens" aus sample_state(). Nichts liest ihn mehr.

5. Zwei weitere Angriffe. Beide beginnen mit steps.bearer_for(state, user, password), das sich anmeldet, POST /tokens fragt und den ganzen Wert für Authorization zurückgibt, Bearer eingeschlossen. Sie werden unten beschrieben.

6. Sieh zu. Führ noch einmal python pl_sec.py forged-token aus.

7. Schreib es auf. Fülle und schließe F6 in SECURITY.md und füge F14 hinzu.

test_attack_changed_token_is_refused verwendet steps.keyed_state({"now": 1000000}), sodass die Uhr in einem Moment stillsteht, in dem ein exp von 2000000 noch in der Zukunft liegt. Dann kann nur das Tag das gefälschte Token ablehnen. Hol bens Wert mit bearer_for und teile ihn an den Punkten. Bau die Payload {"user": "ana", "can_write": True, "exp": 2000000}, mach daraus mit signing.b64u_encode(json.dumps(payload).encode("utf-8")) Text und verbinde den ersten Teil, diesen Text und den alten dritten Teil mit Punkten. Sichere zuerst zu, dass bens ehrliches Token als seins zurückgelesen wird: signing.read_token(state["keys"], bearer.split(" ")[1], now=1000000)["user"] ist "ben". Sende dann POST /books mit dem gefälschten Wert und sichere 401 zu.

test_attack_expired_token_is_refused behält seine Uhr: clock = {"now": 1000000}, dann steps.keyed_state(clock). Hol anas Wert, sende POST /books und sichere 201 zu. Addiere 16 * 60 zu clock["now"], sende dieselbe Anfrage noch einmal und sichere 401 zu.

Nach Meilenstein 5 sagt python -m pytest -q 17 passed. Das Szenario aus Meilenstein 6 zeigt dann, was in bens Token steckt, und drei Ablehnungen. Unter seinen Zeilen:

its payload, read without any key: {"user": "ben", "can_write": false, "exp": 1000900}
ben adds a book with his own token       POST /books -> 403  {"error": "this token may read the list but not change it"}
the changed payload with the old tag      POST /books -> 401  refused
a token that was once in the source code  POST /books -> 401  refused
ben's own token, 16 minutes old           POST /books -> 401  refused
3 of 3 bad tokens refused

Ein Befund bleibt offen

F6 zu schließen öffnet eine kleinere Lücke, und eine ehrliche Liste sagt das. Füge unter F7 die Zeile F14 hinzu:

• Exposed: was auch immer ein Token erlaubt, bis zu 15 Minuten lang.

• Attack: Ein Token, das geleakt wird, funktioniert, bis es abläuft. Eine Abmeldung beendet es nicht, und der Server führt keine Liste, auf der er es streichen könnte.

• Fix: ein kurzes Leben, was erledigt ist, und in einem echten Dienst eine gespeicherte Liste zurückgezogener Tokens, die nicht gebaut wird.

• Test: none yet. Status: open.

Klicke dann auf Check my work. Es prüft die Routen mit eigenen Benutzern, Schlüsseln und einer eigenen Uhr, ruft main auf wie die Prüfung von Lektion 4 und führt deine vier Tests dieses Kapitels gegen eigene Server aus, wo jeder Test an dem Fehler scheitern muss, um den es ihm geht.

Die festen Strings sind weg, und ein Token beweist jetzt, wer fragt. Es sagt noch nicht, welche Bücher diese Person anfassen darf: Das Token jedes Schreibers öffnet immer noch jedes Buch. Das ist Kapitel 6.