Nimm nur an, was du erwartest

Die Leseliste ist für dieses Kapitel gewachsen. Ein Buch kann jetzt drei weitere Felder haben: das Jahr, in dem es erschienen ist, wie weit du damit bist, und eine Liste von Tags. Ein Anfrage-Body kann so aussehen:

{
  "title": "Dune",
  "author": "Frank Herbert",
  "year": 1965,
  "status": "reading",
  "tags": ["desert", "classic"]
}

Um solche Felder zu speichern, hat sich auch create_book in reading_server.py geändert. Dieser Code ist neu und kam mit dem Projekt dieses Kapitels. Du hast ihn nicht geschrieben:

def create_book(request, state, owner):
    """Store the body as a new book owned by owner and return the 201 response."""
    data = json_body(request)
    book_id = state["next_id"]
    state["next_id"] += 1
    book = {"id": book_id, "owner": owner}
    for key in data:
        book[key] = data[key]
    state["books"][book_id] = book
    response = json_response(201, book)
    response["headers"]["location"] = f"/books/{book_id}"
    return response

Die Schleife kopiert jeden Schlüssel des Bodys in das Buch. Das ist bequem, weil ein neues Feld keinen neuen Code braucht. Es lädt aber auch zu einem Fehler ein. Der Server setzt zuerst id und owner, und die Schleife läuft danach, also ersetzt ein Schlüssel im Body, was der Server gewählt hat. replace_book, das PUT bedient, hat dieselbe Schleife.

Schreib zuerst den Angriff

Kapitel 6 hat den Eigentümer zu der einen Tatsache gemacht, gegen die jedes Lesen und jedes Schreiben geprüft wird. Also versuch, ihn zu wählen. Ben hat ein Konto, das schreiben darf, und ein eigenes Token. Er legt ein Buch an und fügt dem Body "owner": "ana" hinzu.

Schreib das als Test, test_attack_body_cannot_set_the_owner, unter den Kommentar für Kapitel 7 in tests/test_attacks.py:

1. Baue den Zustand mit steps.keyed_state() und hol dir Bens Authorization-Wert mit steps.bearer_for(state, "ben", "battery staple").

2. Sende mit diesem Token ein ehrliches Buch und stelle sicher, dass der Status 201 ist. Ohne diesen Schritt würde ein Server, der jedes Buch ablehnt, deinen Test bestehen.

3. Sende {"title": "Planted", "author": "Ben", "owner": "ana"} mit demselben Token. Stelle sicher, dass der Status 422 ist und dass kein Buch in state["books"] den Titel Planted hat.

Dann führe ihn aus. Die Option -k owner wählt die Tests aus, die owner im Namen haben:

python -m pytest -q -k owner

Der Lauf endet mit 1 failed, 21 deselected, und das ist die Zeile, die fehlgeschlagen ist:

E       assert 201 == 422

Der Server hat mit 201 geantwortet und das Buch mit "owner": "ana" gespeichert. Es taucht jetzt in Anas Liste auf, wenn sie GET /books anfragt. Ben, der es angelegt hat, bekommt dafür 404. Dieselbe Schleife lässt einen Body die id wählen, die ein Buch zeigt, oder ein Feld hinzufügen, das niemand geplant hat, etwa "is_admin": true.

Diese Schwachstelle heißt Mass Assignment: Der Server weist einem Datensatz in einem Schritt einen ganzen Body zu, und so bestimmt der Client Felder, die er nie bestimmen durfte.

Der Angriff braucht ein gültiges Token, das schreiben darf: Ben ist ein Benutzer des Dienstes, kein Fremder. In deinem Arbeitsbereich arbeitet sonst niemand, also spielt der Test beide Rollen.

Eine Liste dessen, was abgelehnt wird, vergisst immer etwas

Die erste Lösung, die einem einfällt, nennt den Schlüssel, der das Problem verursacht hat:

if "owner" in body:
    raise ValueError("owner is set by the server")

Das stoppt den Angriff des Tests und lässt id offen. Eine Liste dessen, was abgelehnt wird, heißt Denylist. Sie lässt alles durch, was sie nicht nennt, und dazu gehören auch Felder, die es noch gar nicht gibt.

Eine Liste dessen, was angenommen wird

Dreh die Liste um. Eine Allowlist nennt, was angenommen wird, und alles andere wird abgelehnt. Dein Projekt hat eine, als Set:

ALLOWED_FIELDS = {"title", "author", "year", "status", "tags"}

Der Test lautet key not in ALLOWED_FIELDS. Ein Feld, das Büchern später hinzugefügt wird, bleibt aus Anfragen draußen, bis jemand entscheidet, es hereinzulassen.

validate_book(body) wendet die Liste an. Für einen Body, der kein Dict ist, löst es ValueError("the body must be a JSON object") aus. Dann sieht es sich jeden Schlüssel des Bodys an, in der Reihenfolge des Bodys:

• für owner oder id löst es ValueError(f"{key} is set by the server") aus;

• für jeden anderen Schlüssel, der nicht in ALLOWED_FIELDS steht, löst es ValueError(f"{key} is not a field of a book") aus.

Wenn kein Schlüssel abgelehnt wurde, baut es ein neues Dict, kopiert die Schlüssel und Werte des Bodys hinein und gibt das neue Dict zurück. Es gibt nie den Body selbst zurück, also kann ein Schlüssel, den der Validator nicht gelesen hat, das Buch nicht erreichen.

Diese Verteidigung hast du schon gesehen. In HTTP with Python, Kapitel 11, Lektion 3, hat ein Pydantic-Modell die Felder verworfen, die es nicht nennt, „also kann ein Client die ID eines Buchs nicht wählen“. Dieses Verwerfen war eine Allowlist, und es war die Verteidigung gegen Mass Assignment.

Das Modell hat diese Felder stillschweigend verworfen. Deine Funktion lehnt sie ab, aus zwei Gründen. Ein ehrlicher Client, der einen falsch geschriebenen Schlüssel sendet, erfährt von seinem Fehler. Und ein Manipulationsversuch wird zu einer 422, die das Log aus Kapitel 6 mit dem Namen des Benutzers festhält. Auch ein Modell kann ablehnen: Pydantics Einstellung dafür ist extra="forbid".

Deine Aufgabe

Der Test ist geschrieben und rot. Jetzt, in reading_server.py:

1. Schreib validate_book(body) wie oben beschrieben.

2. Rufe in book_request_error(request) nach den vorhandenen Prüfungen validate_book(json_body(request)) innerhalb von try auf. Wenn es ValueError auslöst, ist der zurückzugebende Fehler json_error(422, str(problem)). Lass book_error stehen: Es meldet weiterhin einen fehlenden Titel.

3. Lass die Schleife in create_book und in replace_book statt über den Body über validate_book(json_body(request)) laufen.

Die zweite Änderung bedient POST und PUT gleichermaßen, also werden in dieser Lektion beide Schreib-Routen geschlossen. Der Status folgt HTTP with Python, Kapitel 5, Lektion 5. Eine 400 sagt, dass der Body nicht gelesen werden konnte, und dieser wurde gelesen. Eine 415 sagt, dass sein Medientyp falsch ist, und dieser ist als application/json gekennzeichnet. Eine 403 sagt, dass das Konto nicht schreiben darf, und Bens Konto darf. Der Body wurde verstanden, und eine Sache darin ist nicht annehmbar: Das ist 422.

Führe python -m pytest -q -k owner noch einmal aus: 1 passed, 21 deselected. Ohne -k owner endet die ganze Datei mit 22 passed.

Diese Lektion ändert absichtlich einen Vertrag. In HTTP with Python wurde ein Buch-Body mit einem zusätzlichen Feld angenommen und das Feld ignoriert. Von jetzt an bekommt ein solcher Body eine 422, die das Feld nennt.

Klicke dann auf Check my work. Jetzt kommen die richtigen Schlüssel an, und sonst nichts. Was unter diesen Schlüsseln steht, ist noch ungeprüft: ein Titel beliebiger Länge, ein Jahr beliebigen Typs. Darum geht es in der nächsten Lektion.