Eine sicherheitsorientierte Code-Review-Checkliste für Änderungen an Vertrauensgrenzen

Ziel

Sicherheitsmängel erfassen, die ein allgemeines Review übersieht, weil sie korrekter Code sind, der das Falsche tut: eine fehlende Autorisierungsprüfung, eine nicht escapete Ausgabe, eine aus Nutzereingaben abgerufene URL.

Voraussetzungen

Eine Änderungsbeschreibung, die die betroffenen Vertrauensgrenzen benennt, ein bereits durchgeführtes allgemeines Review für Design und Korrektheit, sowie die verlinkten Wiki-Artikel für die Details jeder Kontrolle. Der OWASP Code Review Guide (zitiert) ist die ausführliche Referenz für dieselbe Tätigkeit.

Schritte

1. Entscheiden, ob die Checkliste greift: Liest die Änderung Eingaben von ausserhalb des Prozesses, ändert sie, wer was darf, berührt sie eine Datenbank oder das Dateisystem, macht sie ausgehende Anfragen, behandelt sie Zugangsdaten oder Schlüssel, oder fügt sie eine Abhängigkeit hinzu? Trifft nichts davon zu, hier aufhören.
2. Eingabe: Für jeden neuen Einstiegspunkt herausfinden, wo die Daten validiert werden (Typ, Länge, Allowlist) und wo sie verwendet werden; jede Verwendung, die eine Abfrage, einen Befehl, einen Pfad, eine URL oder Markup erzeugt, muss über Parametrisierung oder Encoding laufen, nicht über String-Konkatenation.
3. Authentifizierung und Sitzungen: Jeder neue Endpunkt liegt hinter derselben Authentifizierung wie vergleichbare Endpunkte; Code für Login, Reset, MFA und Tokens erzeugt Kennungen und Ablaufzeiten neu, wo die bestehenden Artikel das verlangen.
4. Autorisierung: Für jedes Objekt, auf das über eine Kennung aus der Anfrage zugegriffen wird, die Prüfung ausfindig machen, dass die aktuelle Instanz auf genau dieses Objekt zugreifen darf, nicht nur auf den Endpunkt. Nach der fehlenden Prüfung auf dem zweiten Pfad suchen (Massenverarbeitung, Export, Admin, Webhook).
5. Datenzugriff und -speicherung: Abfragen parametrisiert; neue Spalten mit personenbezogenen Daten klassifiziert und von der Aufbewahrungsregelung erfasst; Dateien unter einem zufälligen Namen an einem nicht ausführbaren Ort geschrieben.
6. Ausgehend: Jede aus Eingaben gebaute URL läuft über die SSRF-Allowlist; Weiterleitungen zielen nur auf relative Pfade oder gelistete Hosts; XML, YAML und native Serialisierung werden mit dem sicheren Loader geparst.
7. Geheimnisse und Konfiguration: keine wörtlich im Code stehenden Zugangsdaten, keine Geheimnisse in Logs oder Fehlermeldungen, neue Konfiguration schlägt bei Fehlen sicher fehl (fail closed).
8. Abhängigkeiten: Ein neues Paket hat einen Grund, eine fixierte Version und ein gepflegtes Upstream; eine Änderung der Lockfile wird auf unerwartete Pakete geprüft.
9. Protokollierung und Fehler: sicherheitsrelevante Aktionen erzeugen ein Audit-Ereignis; Fehlerantworten geben keine Stack Traces oder internen Hosts preis.
10. Befunde als Fragen mit Verweis auf den relevanten Artikel festhalten; den Merge nur bei Punkten aus den Schritten 2, 4 und 6 blockieren, jenen, die ein Angreifer zuerst erreicht.

Erwartetes Ergebnis

Änderungen an Vertrauensgrenzen erhalten einen konsistenten zweiten Blick; Reviewende richten die sicherheitsbezogene Aufmerksamkeit dorthin, wo sie sich auszahlt, und sparen sie anderswo aus.

Grenzen und Prüfbasis

Ein Vorschlag, keine erprobte Praxis. Die Liste findet Auslassungen, nicht logische Fehler in Geschäftsregeln, die eine Bedrohungsmodellierung erfordern. Sie auf jede Änderung anzuwenden verwässert sie; sie nur anzuwenden, wenn die Autorenschaft eine Grenze kennzeichnet, hängt davon ab, dass diese sie bemerkt.