Sicherheits-Checkliste #

Diese Seite richtet sich an Entwickler, die Websites bauen und sie sicher übergeben müssen. Exponential ist an vielen Stellen standardmäßig sicher, und ein Projekt kann das trotzdem mit einer unbedachten Rolle, einem Template oder einer Einstellung zunichtemachen. Gehen Sie diese Listen während der Entwicklung und noch einmal vor dem Start durch; die Anleitung zur Härtung erklärt die Angriffe hinter jedem Punkt (Sicherheitshärtung).

Inhalt #

1. Inhaltsmodell und Zugriff
2. Templates und Ausgaben
3. Formulare und Uploads
4. Ihr eigener Code
5. APIs
6. Konfiguration und Bereitstellung
7. Konten
8. Härtung vor dem Live-Gang
9. Beobachten und Melden

Inhaltsmodell und Zugriff #

• To do: Die Rolle Anonymous liest nur, was Besucher lesen dürfen (content/read auf den öffentlichen Sektionen), und darüber hinaus nichts außer user/login und dem, was die Formulare der Website brauchen.
• To do: Inhalte nur für Mitglieder liegen in einer eigenen Sektion, die eine der Mitgliedergruppe zugewiesene Rolle liest, statt nur verborgen zu sein.
• To do: Redakteursrollen sind nach Klasse und Teilbaum eingeschränkt; keine Redakteursrolle hat setup/*, role/* oder user/* über den Bedarf hinaus.
• To do: Rollen sind Gruppen zugewiesen; Mitglieder und Personal sind in verschiedenen Gruppen.
• To do: Der Zugriff wurde mit Testkonten unter example.invalid getestet, und ./console exp:accesscheck erklärt jede Überraschung (Sektionen, Rollen und Richtlinien).

Templates und Ausgaben #

• To do: Jeder Wert, den Sie selbst ausgeben, läuft durch |wash(); Ausgaben von Datentypen kommen aus attribute_view_gui (Wash und Maskierung).
• To do: Keine <style>-Blöcke, style=""-Attribute, Inline-Skripte oder javascript:-Links in Templates, damit eine Content Security Policy durchgesetzt werden kann (CSP-sicheres Design, Content Security Policy).
• To do: Redakteure können kein Markup speichern: Rich Text hat kein Tag für Skripte; eigene Tags statt eingefügtem HTML (Rich Text).
• To do: Keine besucherbezogenen Daten in gemeinsamen Caches (Caching für CMS-Entwickler).

Formulare und Uploads #

• To do: ezformtoken ist aktiv, und jedes Formular behält die verborgenen Felder, die das Original-Template ausgibt.
• To do: Öffentliche Formulare haben einen Captcha-Datentyp; gesammelte Antworten werden nach Plan entfernt (Formulare und Informationssammlung).
• To do: Upload-Typen sind auf das beschränkt, was Redakteure brauchen; Dateiattribute haben eine Höchstgröße.
• To do: Die Selbstregistrierung ist nur dort eingeschaltet, wo sie nötig ist, mit Prüfung der E-Mail-Adresse (Benutzer und Registrierung).

Ihr eigener Code #

• To do: Jede Modul-View deklariert eine Richtlinienfunktion und prüft sie; Schreibzugriffe brauchen POST und das Formular-Token.
• To do: SQL läuft über eZPersistentObject oder eZDB mit maskierten Werten (escapeString()) und auf Ganzzahlen umgewandelten IDs (eZDB).
• To do: Weiterleitungen gehen nur zu Adressen der Website (Sichere Weiterleitungen).
• To do: Inhalte werden über die Kernel-API angelegt, als eigener Benutzer mit genau den nötigen Rechten (Inhalte aus PHP).
• To do: Die Regeln des Buchs sind erfüllt: Sicherheit in Erweiterungen.

APIs #

• To do: rest.ini [Authentication] RequireAuthentication=enabled (mitgeliefert) und RequireHTTPS=enabled.
• To do: Ein Konto je Client, mit einer auf den Bedarf eingeschränkten Rolle; API-Schlüssel mit Scopes und Ablaufdatum (Die REST-API, Persönliche API-Schlüssel).
• To do: Schlüssel und Tokens liegen in Umgebungsvariablen oder Geheimnisspeichern, nie in Repositorys.

Konfiguration und Bereitstellung #

• To do: Debug-Ausgabe auf Staging und Live aus oder auf Ihre Adresse beschränkt; PHP display_errors=Off.
• To do: settings/override/ liegt in keinem Repository und wird nicht zwischen Rechnern kopiert.
• To do: Code ist für den Benutzer der Website nur lesbar; Worker und Cronjobs laufen nie als root.
• To do: ManagedByDeployment=enabled, wo die Konfiguration aus der Versionsverwaltung kommt (Eine Website bereitstellen).
• To do: Die Rewrite-Regeln des Webservers verhindern, dass settings/, Interna von var/ und Quelldateien ausgeliefert werden (Sicherheitshärtung, Kapitel 13).

Konten #

• To do: Das Administratorpasswort des Installers geändert und var/log/initial-admin-password entfernt (Das Administratorpasswort ändern).
• To do: Ein persönliches Administratorkonto je Person; Zwei-Faktor-Anmeldung für Administratoren (Zwei-Faktor-Anmeldung).
• To do: Passwortregeln entschieden (MinPasswordLength, WeakPasswordCheck, [PasswordSettings]).
• To do: Demomodus aus (EXP_DEMO_MODE nicht gesetzt) (Demomodus).

Härtung vor dem Live-Gang #

• To do: Überall HTTPS, HSTS, sichere Cookies.
• To do: Die Administration auf einem eigenen Host oder per Netzwerk eingeschränkt.
• To do: Anfrageregeln oder der Request Shield davor, zuerst beobachtend, dann durchsetzend (Anfrageregeln).
• To do: Die Liste Einstellung für Einstellung: Checkliste für den Live-Gang.

Beobachten und Melden #

• To do: Audit-Warnungen gehen an eine Person, und der Trail verlässt den Rechner (Sicherheit und Audit).
• To do: Logs werden wöchentlich gelesen; Sicherungen liegen außerhalb des Rechners, und eine Wiederherstellung wurde getestet.
• To do: Aktualisierungen von Exponential und seinen Erweiterungen werden verfolgt und getestet.
• To do: Ihr Team weiß, wie eine Schwachstelle gemeldet wird (Eine Schwachstelle melden).

Verwandte Seiten #

• Sicherheitsstandards
• Checkliste zur Sicherheitsprüfung für Hoster
• Checkliste für den Projektstart
• Freie Dokumentation: Diese Seite darf unter der GNU FDL 1.3 frei kopiert, übersetzt und verbessert werden.