Checkliste für Sicherheitsprüfungen #

Diese Seite ist eine Checkliste für den Sicherheitsteil eines Code-Reviews. Verwenden Sie sie zusammen mit der allgemeinen Checkliste für Code-Reviews. Jeder Punkt nennt die Regel, die er prüft; den Hintergrund finden Sie unter Sicherheitstechnik im Überblick.

Inhalt #

1. Zugriffskontrolle
2. Ein- und Ausgabe
3. Datenbank und Shell
4. Formulare, Weiterleitungen und Dateien
5. Geheimnisse, Logs und Datenschutz
6. HTTP-Schicht und Browser
7. Laufzeit und Abhängigkeiten

Zugriffskontrolle #

• To do: Jede neue View nennt ihre Richtlinienfunktionen in functions der module.php.
• To do: Kein neuer Eintrag in [RoleSettings] PolicyOmitList[] oder AnonymousAccessList[] ohne eine in der Änderung festgehaltene Begründung.
• To do: Über Zugriff entscheiden Richtlinien, nie der Vergleich einer Benutzer- oder Gruppen-ID.
• To do: Fetches und Listen wenden die Leseberechtigung des Benutzers an (die Inhalts-Fetches tun das; eigenes SQL darf sie nicht umgehen).
• To do: Eine neue Richtlinienfunktion erreicht bestehende Installationen über einen Installer oder ein Update-Skript.

Quelle: Module, Views und Zugriffskontrolle.

Ein- und Ausgabe #

• To do: Eingaben der Anfrage werden über eZHTTPTool gelesen, nicht über $_GET oder $_POST.
• To do: Eingaben werden dort geprüft, wo sie hereinkommen (ein Datentyp in validateObjectAttributeHTTPInput()).
• To do: Jede Variable in einem Template wird mit |wash ausgegeben oder über einen Operator, der maskiert.
• To do: In PHP erzeugtes HTML (ein Operator, eine View) wird dort maskiert.
• To do: Header-Werte enthalten kein CR oder LF aus Eingaben.

Quelle: Kernel-Architektur, Härtung von Datentypen und Eingaben.

Datenbank und Shell #

• To do: Jede Zeichenkette in SQL läuft über $db->escapeString(); jede Zahl wird mit (int) umgewandelt.
• To do: Spalten für ORDER BY kommen aus einer Whitelist.
• To do: Shell-Argumente laufen über escapeshellarg(); besser ist gar keine Shell.

Quelle: Sicherheitshärtung von 6.0.13, Portables SQL schreiben.

Formulare, Weiterleitungen und Dateien #

• To do: Jede zustandsändernde Anfrage ist ein POST mit dem Formular-Token (ezformtoken); keine Zustandsänderung bei GET.
• To do: Weiterleitungsziele laufen über den Weiterleitungsmanager und die erlaubten Hosts.
• To do: Downloads laufen über content/download, das den Lesezugriff prüft, oder prüfen ihn selbst.
• To do: Uploads werden auf Typ und Inhalt geprüft; SVG läuft durch die Bereinigung.
• To do: Aus Eingaben gebaute Pfade können ihr Verzeichnis nicht verlassen.
• To do: Ausgehende Anfragen an URLs aus Eingaben lehnen private, Loopback- und Link-Local-Adressen ab.

Geheimnisse, Logs und Datenschutz #

• To do: Keine Zugangsdaten, Schlüssel oder hostspezifischen Werte in committeten Dateien; Geheimnisse liegen in settings/override/ oder in der Umgebung.
• To do: Kein Passwort, Token, Schlüssel oder keine Session-ID in einem Log, im Audit-Trail, auf einer Fehlerseite oder in einer Debug-Meldung.
• To do: Neue Logzeilen folgen der Maskierung des Log-Betrachters und der Anfrage-Logs (Adressen, E-Mail, Abfragewerte).
• To do: Sicherheitsrelevante Aktionen werden im Audit-Trail festgehalten (Der Audit-Trail).

HTTP-Schicht und Browser #

• To do: Kein Inline-Skript ohne die CSP-Nonce; keine on...=-Attribute oder javascript:-URLs.
• To do: Keine <style>-Blöcke oder style=""-Attribute in Administrations-Templates.
• To do: Code, der die Client-Adresse oder das Schema liest, verwendet eZSys (das TrustedProxies[] beachtet), keine rohen Header.
• To do: Antworten für angemeldete Benutzer werden für Proxys nicht cachebar gemacht.

Quelle: HTTP-Sicherheit: Header, CSP, Anfrageregeln und Proxys.

Laufzeit und Abhängigkeiten #

• To do: Keine Geheimnisse oder Benutzerdaten einer Anfrage bleiben in Statics oder Globals eines langlebigen Workers zurück (Nebenläufigkeit, Statics und langlebige Prozesse).
• To do: Eine neue Composer-Abhängigkeit wird gepflegt, ist mit der GPL vereinbar lizenziert und auf eine veröffentlichte Version festgelegt (Abhängigkeitsverwaltung mit Composer).
• To do: Ein geänderter Standard, der die Sicherheit betrifft, ist mit dem Weg dokumentiert, ihn bewusst rückgängig zu machen (Richtlinie zur Rückwärtskompatibilität).
• To do: Eine bei der Prüfung gefundene Schwachstelle wird vertraulich gemeldet, wie SECURITY.md es sagt, nicht im Pull-Request.

Verwandte Seiten #

• Sicherheitstechnik im Überblick
• Checkliste für Sicherheitsprüfungen für Hoster
• Die Arbeit anderer prüfen
• Freie Dokumentation: Diese Seite darf unter der GNU FDL 1.3 frei kopiert, übersetzt und verbessert werden.