Source Code Security Review Checklist

Diese Checkliste bietet eine strukturierte Grundlage für die Durchführung und Dokumentation von Secure-Code-Reviews im Rahmen technischer Sicherheitsprüfungen. Sie wird von binsec verwendet, um Softwareprojekte nach anerkannten Standards wie PCI DSS und OWASP Top 10 zu bewerten. Die Checkliste kann sowohl für eigenständige Code-Reviews als auch ergänzend zu Web- oder API-Penetrationstests eingesetzt werden.

Prüfobjekt 1 – Kommunikation

▢ T1-1: Werden eingehende und ausgehende sensible Daten (z. B. Zugangsdaten) ausschließlich über verschlüsselte Kanäle übertragen?

▢ T1-2: Werden sichere, dem Stand der Technik entsprechende kryptografische Algorithmen verwendet?

▢ T1-3: Werden X.509-Zertifikate ausgehender Verbindungen auf Authentizität und Gültigkeit überprüft?

Prüfobjekt 2 – Authentifizierung

▢ T2-1: Müssen Benutzer ihre E-Mail-Adresse während der Registrierung bestätigen?

▢ T2-2: Werden nur starke Passwörter (mindestens 12 Zeichen, Buchstaben und Zahlen) akzeptiert – bei Registrierung und Passwort-Zurücksetzung?

▢ T2-3: Können Benutzer keine der letzten vier Passwörter erneut verwenden?

▢ T2-4: Wird zum Zurücksetzen des Passworts ein einmaliger Link per E-Mail versendet?

▢ T2-5: Ist eine Passwortänderung nur mit Angabe des alten Passworts möglich?

▢ T2-6: Werden Benutzerkonten nach sechs fehlgeschlagenen Anmeldeversuchen für mindestens 30 Minuten gesperrt?

Prüfobjekt 3 – Sitzungsverwaltung

▢ T3-1: Besteht die Session-ID aus mindestens 128 Bit (16 Byte)?

▢ T3-2: Enthält die Session-ID keine statistischen Informationen über den Benutzer?

▢ T3-3: Wird die Session-ID ausschließlich in einem HTTP-Cookie übertragen?

▢ T3-4: Sind die Flags HttpOnly und Secure gesetzt?

▢ T3-5: Müssen Benutzer sich nach 15 Minuten Inaktivität erneut authentifizieren?

▢ T3-6: Wird bei jeder autorisierten Anfrage ein zufälliger Token mitgesendet und überprüft (CSRF-Schutz)?

▢ T3-7: Wird die Session-ID beim Logout gelöscht?

Prüfobjekt 4 – Autorisierung

▢ T4-1: Sind verschiedene Benutzerrollen gemäß der Geschäftslogik definiert?

▢ T4-2: Sind Berechtigungen nach den Prinzipien „Need-to-Know“ und „Least Privilege“ umgesetzt?

▢ T4-3: Ist Cross-Origin Resource Sharing (CORS) nur für ausgewählte Domains aktiviert?

Prüfobjekt 5 – Fehlerbehandlung

▢ T5-1: Sind alle potenziell fehlerauslösenden Codeblöcke durch try-catch-Anweisungen abgesichert?

▢ T5-2: Werden nur generische Fehlermeldungen angezeigt (keine technischen Details)?

Prüfobjekt 6 – Datenvalidierung

▢ T6-1: Wird nur fachlich zulässige Eingabe (z. B. gültiges Ablaufdatum einer Kreditkarte) verarbeitet?

▢ T6-2: Wird sämtliche Eingabe – auch innerhalb vertrauenswürdiger Grenzen – serverseitig validiert?

▢ T6-3: Werden Sonderzeichen ordnungsgemäß escaped oder maskiert?

▢ T6-4: Werden Prepared Statements verwendet, um SQL-Injections zu verhindern?

Prüfobjekt 7 – Datenspeicherung

▢ T7-1: Werden nur für den Betrieb notwendige Daten gespeichert oder verarbeitet?

▢ T7-2: Werden PCI DSS-Anforderungen für die Speicherung von Kreditkartendaten eingehalten (z. B. keine CVV-Speicherung)?

▢ T7-3: Werden Benutzerpasswörter ausschließlich in gehashter Form gespeichert?

▢ T7-4: Werden kryptografisch starke Hash-Funktionen und individuelle Salts verwendet?

Prüfobjekt 8 – Protokollierung

▢ T8-1: Werden Benutzeraktionen protokolliert (Audit-Trails)?

▢ T8-2: Werden fehlgeschlagene Eingabevalidierungen protokolliert?

▢ T8-3: Werden erfolgreiche und fehlgeschlagene Authentifizierungsversuche geloggt?

▢ T8-4: Werden Autorisierungsfehler geloggt?

▢ T8-5: Werden Fehler im Sitzungsmanagement (z. B. fehlgeschlagene CSRF-Prüfungen) geloggt?

▢ T8-6: Werden rechtliche Zustimmungen (z. B. Opt-ins, Altersverifikation) geloggt?

▢ T8-7: Werden Ausnahmedetails (Exceptions) geloggt?

▢ T8-8: Werden sensible Daten in Logs maskiert?

Prüfobjekt 9 – Softwarekomponenten

▢ T9-1: Sind eingesetzte Softwarekomponenten (z. B. Bibliotheken oder Frameworks) aktuell?

▢ T9-2: Sind die Paketquellen vertrauenswürdig und wurde die Integrität der Software überprüft?

Prüfobjekt 10 - API-Sicherheit

▢ T10-1: Werden alle API-Endpunkte strikt authentifiziert und autorisiert, inklusive schreibender und lesender Routen?

▢ T10-2: Besteht serverseitiger Schutz gegen Missbrauch, z. B. Rate Limiting, Anti-Automation, Request-Size-Limits?

Prüfobjekt 11 - Kryptographie

▢ T11-1: Werden ausschließlich aktuelle, sichere kryptografische Algorithmen verwendet (z. B. AES-GCM, ChaCha20-Poly1305, SHA-256/512, bcrypt/argon2)?

▢ T11-2: Werden Initialisierungsvektoren (IVs) sicher erzeugt, nicht wiederverwendet und korrekt gehandhabt?

▢ T11-3: Werden kryptografische Schlüssel, Tokens und Secrets nicht im Quellcode gespeichert und stattdessen über sichere Mechanismen verwaltet (z. B. Key Vault, KMS)?

▢ T11-4: Werden kryptografisch sichere Zufallszahlengeneratoren eingesetzt (CSPRNG statt Pseudo-RNG)?