Die Karte und wohin es weitergeht

Kapitel 11 war die letzte Bewertung. Diese Lektion bringt keine Arbeit. Sie ordnet das, was du getan hast, auf einer Karte ein, die auch andere Leute benutzen, sagt, was die Site bewiesen hat, und hilft dir zu wählen, wohin du als Nächstes gehst.

Das kannst du jetzt, was du zu Beginn des Kurses nicht konntest. Du schreibst einen Befund als Zeile mit einem Test, der den Angriff ausführt. Du speicherst ein Passwort als gesalzenen scrypt-Datensatz und wendest für einen Namen, den es nicht gibt, dieselbe Arbeit auf. Du führst Sessions, die enden, auf dem Server, durch zwei Limits. Du signierst ein Token, legst seinen Ablauf in den signierten Teil und lädst den Schlüssel aus der Umgebung oder weigerst dich zu starten. Du gibst jedem Buch einen Eigentümer, lehnst ab, außer eine Regel erlaubt es, und zählst Anmeldeversuche. Du validierst einen Body auf dem Weg hinein gegen eine Allowlist und schützt auf dem Weg hinaus vier Stellen, an denen Text geschrieben wird. Du hast die Browserregeln hinter Cross-Site-Anfragen als Modell geschrieben und CORS anhand einer einzigen exakten Liste beantwortet. Du hast Kontexte gebaut, die ein Zertifikat verifizieren, und die Header, die einem Browser Anweisungen geben, über eine einzige Funktion gesendet.

Die Karte

Die OWASP Top Ten sind eine Rangliste von Kategorien von Schwächen in Webanwendungen, die alle paar Jahre überarbeitet wird. Sie sind eine Karte für Gespräche, keine Checkliste.

Die Tabelle ordnet diesen Kurs in die Ausgabe 2025 ein. Die mittlere Spalte sagt, wo du an einer Kategorie gearbeitet hast. Die letzte Spalte sagt, was der Kurs nur gestreift oder gar nicht berührt hat.

Zwei Einordnungen, die man leicht übersieht

Zwei Dinge, die du gebaut hast, gehören zu A10, der Kategorie für falsch behandelte Ausnahmesituationen. In 5.4 weigert sich dein Server zu starten, wenn er keinen Schlüssel hat, wo ein schwächerer Server auf einen Standardwert zurückfällt. In 6.6 antwortet dein Server mit einem festen 500-Body, wenn sein eigener Code versagt, wo ein schwächerer Server den Traceback sendet. Beide schlagen geschlossen fehl („fail closed“).

Server-Side Request Forgery heißt, einen Server dazu zu bringen, eine URL abzurufen, die der Angreifer gewählt hat, sodass die Anfrage aus dem eigenen Netzwerk des Servers kommt. In dieser Ausgabe steht sie unter A01, Broken Access Control. Dieser Kurs hat sie nicht geübt, weil die Leseliste nie eine URL abruft, die ein Client nennt.

Was die Site bewiesen hat, und was nicht

Jede Prüfung, die du bestanden hast, hat deine Funktionen mit Benutzern, Büchern, Schlüsseln und Zeiten aufgerufen, die du nicht gesehen hattest, oder deine Tests gegen andere Server laufen lassen, um zu sehen, ob sie etwas bemerken. Die Läufe von pl_sec.py auf 127.0.0.1 waren zum Zuschauen da. Keine Bewertung hing von ihnen ab.

Manches hat dieser Kurs absichtlich nie berührt. Kein echter Browser hat deine Seite geladen. Was ein Browser mit einem Cookie, einem Header Origin oder einer CORS-Antwort macht, war ein Modell, das du geschrieben hast, kein Browser auf der Site. Keine öffentliche Zertifizierungsstelle hat irgendetwas ausgestellt: Der Test-Zertifizierungsstelle wurde nur vertraut, weil dein Client ihre Datei bekommen hat. Nichts wurde deployt, und kein Proxy und kein vorgeschalteter Server stand vor deinem Code. Nichts wurde gemessen, also hat keine Prüfung gezeigt, wie lange ein Vergleich oder ein Hash dauert.

Und ein Befund ist noch offen. F14 sagt, dass ein signiertes Token, das durchsickert, funktioniert, bis es abläuft. Du hast seine Lebensdauer auf 15 Minuten verkürzt und keine Liste zurückgezogener Tokens gebaut.

Wähl einen Weg

Jeder Weg unten ist optional und wird nicht bewertet. Wähl einen, nicht sechs.

Build a Web API with FastAPI. Ziel: dieselben Abwehrmaßnahmen dort, wo ein Framework sie liefert. Erster Schritt: Lies, wie seine CORSMiddleware konfiguriert wird, und vergleich das mit deinem cors_headers(). Fertig, wenn du sagen kannst, welche Funktionen dieses Kurses ein Framework ersetzt und welche deine bleiben.

Anmeldeprotokolle: OAuth, OpenID Connect, Passkeys. Ziel: Anmeldung ohne ein Passwort, das dein Dienst speichert. Erster Schritt: Lies die Beschreibung des Authorization Code Flow bei einem OpenID-Connect-Anbieter und finde darin das ID-Token. Ein ID-Token ist ein JWT, das Token-Format, das 5.1 genannt hat. Fertig, wenn du sagen kannst, wo das exp, die Schlüssel-ID und die Signatur aus Kapitel 5 in einem ID-Token vorkommen.

Angewandte Kryptografie. Ziel: Verschlüsselung und Public-Key-Signaturen, die dieser Kurs nur genannt hat. Erster Schritt: Lies die Seite des Pakets cryptography über authentifizierte Verschlüsselung. Fertig, wenn du sagen kannst, was authentifizierte Verschlüsselung einem Tag mit Schlüssel wie sign() aus Kapitel 2 hinzufügt, und wann du sie brauchen würdest.

Sicherheit im Browser. Ziel: das echte Ding, für das das Modell stand. Erster Schritt: Öffne die Entwicklerwerkzeuge eines Browsers auf einer Site, auf der du ein Konto hast, melde dich an und finde den Header Origin bei der Anmeldeanfrage und die Attribute des Cookies, das zurückkommt. Fertig, wenn du eine Entscheidung nennen kannst, bei der sich ein echter Browser von mini_browser.py unterscheidet.

Deployment. Ziel: ein echtes Zertifikat, ein vorgeschalteter Server und HSTS, das etwas bedeutet. Erster Schritt: Lies, wie eine kostenlose Zertifizierungsstelle die Kontrolle über einen Namen nachweist. Fertig, wenn du zeichnen kannst, wo TLS endet und wo state["https"] gesetzt würde.

Working with Real APIs. Ziel: die Perspektive des Clients bei Schlüsseln, Limits und Tokens. Erster Schritt: Finde heraus, wo die Client-Bibliothek eines Anbieters ihren Schlüssel aufbewahrt. Fertig, wenn ein Client von dir seinen Schlüssel aus der Umgebung liest und sich ohne ihn weigert zu starten.

Welchen Weg du auch nimmst, vier Gewohnheiten aus diesem Kurs gehen mit dir. Ein Befund hat einen Test. Lehne ab, außer eine Regel erlaubt es. Validiere auf dem Weg hinein und schütze auf dem Weg hinaus. Ein Schlüssel lebt nie im Quellcode.