Ein Token vor 101 prüfen

Eine Punktezählerseite kann ihr Token nur im Query-String tragen, ein Python-Client kann einen Bearer-Header senden, und heute liest der Server keins von beiden. Diese Lektion schreibt die Entscheidung: Darf dieser Client werten, gegeben den Pfad und die Header eines Handshakes? Die nächste Lektion bringt die Bibliothek dazu, diese Frage während des Handshakes zu stellen.

Vor 101 oder nie

Der Handshake ist ein HTTP-Austausch, und 101 Switching Protocols ist seine letzte HTTP-Nachricht. Danach spricht die Verbindung WebSocket-Frames, und der Handler läuft bereits. Eine Ablehnung an diesem Punkt könnte nur ein Close-Code sein, gesendet auf einer Verbindung, die der Server gerade angenommen hat. Eine Ablehnung davor ist ein gewöhnlicher HTTP-Status, und es entsteht nie eine WebSocket-Verbindung.

Du hast schon Upgrades abgelehnt. In Kapitel 2 hat check_upgrade ein fehlerhaftes Upgrade mit 400 und eine falsche Version mit 426 beantwortet, statt mit 101. Ein fehlendes Token ist dieselbe Art von Antwort: ein Status, entschieden anhand der Zeile und der Header der Anfrage, gesendet vor jedem Frame.

Wo das Token steckt

Die Regel für den Header ist die aus HTTP with Python: ein einziger Authorization-Wert, mit partition(" ") am ersten Leerzeichen geteilt, das Schema bearer in beliebiger Groß- und Kleinschreibung, und der Rest von Leerzeichen befreit.

print("bearer  tok".partition(" "))

Das Token kommt mit einem Leerzeichen davor zurück, und deshalb wird der Rest von Leerzeichen befreit, bevor er verglichen wird.

Ein Header kann in einer Anfrage mehr als einmal vorkommen, und das Headers-Objekt der Bibliothek behält jede Kopie. Sein get löst MultipleValuesError aus, wenn sich ein Name wiederholt, also lies den Header mit headers.get_all("authorization"), das eine Liste aller Werte zurückgibt (leer, wenn der Header fehlt). Zwei Werte werden abgelehnt, statt zwischen ihnen zu raten.

Gibt es überhaupt keinen Authorization-Header, schau in die Query. parse_qs, aus demselben Modul urllib.parse wie urlsplit, verwandelt einen Query-String in ein Dictionary, das jeden Namen einer Liste seiner Werte zuordnet, und decodiert dabei Prozent-Escapes und +:

from urllib.parse import parse_qs, urlsplit

print(urlsplit("/score?token=abc%2Fdef&x=1").path)
print(parse_qs("token=abc%2Fdef&token=2"))
print(parse_qs("token="))
print(parse_qs("token=a+b"))

Die erste Zeile gibt /score aus: den Pfad ohne seine Query. Die anderen geben {'token': ['abc/def', '2']} aus, mit %2F zu / decodiert und beiden Werten in der Liste; {}, weil ein leerer Wert verworfen wird; und {'token': ['a b']}, mit + zu einem Leerzeichen decodiert.

Die Query muss also genau einen token-Wert enthalten: Ein leeres token= lässt keinen übrig, und zwei Werte werden abgelehnt wie zwei Header. find_token(path, headers) gibt das gefundene Token oder None zurück, nach diesen Regeln:

Die mittlere Zeile ist wichtig. Ein schlechter Header fällt nicht auf die Query zurück: Ein Client, der einen Nachweis gesendet hat, wird nach diesem Nachweis beurteilt.

Vergleichen, ohne Zeit zu verraten

token == expected liefert die richtige Antwort, aber == auf zwei Strings hört beim ersten Zeichen auf, das sich unterscheidet. Ein falscher Versuch, dessen erste zehn Zeichen stimmen, braucht etwas länger bis zur Ablehnung als einer, der von Anfang an falsch ist. Über viele Versuche gemessen kann dieser Unterschied einem Angreifer verraten, wie viel von einem Versuch richtig war, und ihn das Token Zeichen für Zeichen aufbauen lassen. Solche Timing-Angriffe über ein Netzwerk sind schwierig, aber real, und die übliche Abwehr kostet eine Zeile: hmac.compare_digest(a, b) braucht dieselbe Zeit, egal welcher Teil der Werte übereinstimmt. (Das Timing kann weiterhin die Länge der Werte zeigen, aber nicht, welche Zeichen richtig waren.) Der Kurs verwendet dieses Werkzeug, statt darüber nachzudenken, wann der Angriff funktionieren würde.

Ein Detail: compare_digest lehnt str-Werte ab, die Zeichen außerhalb von ASCII enthalten.

import hmac

hmac.compare_digest("café", "cafe")

Ein Token aus der Query kann so ein String sein, nachdem parse_qs es decodiert hat (caf%C3%A9 wird zu café), und ein Header-Wert ebenso. Vergleiche stattdessen Bytes: hmac.compare_digest(token.encode("utf-8"), expected.encode("utf-8")) funktioniert für jeden Text. Rufe es über das Modul auf, als hmac.compare_digest, mit der Zeile import hmac, die schon oben in scoreboard_server.py steht.

401, und warum nicht 403

HTTP with Python hat die Grenze gezogen: 401, wenn der Server nicht weiß, wer du bist, 403, wenn er es weiß und trotzdem nein sagt. Die Anzeigetafel hat ein Token und eine Berechtigung, das Werten. Ein Client ohne Token oder mit einem falschen ist jemand, den der Server nicht identifizieren kann, also ist jede Ablehnung auf /score eine 401. Eine 403 triffst du in Lektion 4, aus einer anderen Prüfung. /watch braucht kein Token, also vergleicht check_request(path, headers, expected) zuerst urlsplit(path).path mit "/score" und gibt für alles andere None zurück; ein Query-String kann den Pfad so nicht verstecken.

Die Token-Datei

Das erwartete Token steht in token.txt in deinem Arbeitsbereich. Die Datei enthält ein erfundenes Übungstoken, kein Geheimnis: Ein echtes Token liegt nie in einem Quellcodebaum, wo jede Kopie des Codes es mit sich trägt. Echte Dienste laden es aus der Umgebung oder aus einem Geheimnisspeicher. read_token(path) öffnet die Datei mit encoding="utf-8" in einem with-Block und gibt ihren Text ohne den Zeilenumbruch und ohne umgebende Leerzeichen zurück.

Deine Aufgabe

Schreibe in scoreboard_server.py read_token, find_token und check_request so, wie ihre Docstrings und diese Lektion sie beschreiben. Noch ruft nichts check_request während eines Handshakes auf.

Klicke auf Run. Der Abschnitt zu Lektion 2 baut fünf Anfragen mit den Headers der Bibliothek und gibt für jede aus: den Pfad ohne seine Query, ob ein Authorization-Header gesendet wurde, ob die Query ein Token enthielt und was check_request geantwortet hat. Er gibt nie ein Token aus. Eine fertige Version hat auf der Seite ausgegeben:

Lesson 2: who may score?
    /watch, no Authorization header, a token in the query: False -> None
    /score, no Authorization header, a token in the query: False -> 401
    /score, an Authorization header, a token in the query: False -> None
    /score, no Authorization header, a token in the query: True -> None
    /score, an Authorization header, a token in the query: False -> 401

Der Zuschauer kommt ohne alles durch. Der Punktezähler ohne alles bekommt 401. Die dritte und die vierte Anfrage tragen das erwartete Token der Demo, eine in einem Header und eine in der Query. Die letzte sendet einen geratenen Wert in einem Header. Klicke dann auf Submit.

Die nächste Lektion übergibt check_request an die Bibliothek, damit statt einer 101 eine 401 hinausgeht.