Sicherheit in Erweiterungen #

Teil 3, Kapitel 31. Eine Erweiterung läuft mit den vollen Rechten des Kernels. Ein Fehler darin ist ein Fehler in jeder Website, die sie installiert. Dieses Kapitel ist die Checkliste, der der eigene Code des Kernels folgt, mit dem Mechanismus zu jeder Regel.

1. Jede View hat eine Richtlinie #

$ViewList['admin'] = array( 'script' => 'admin.php', 'functions' => array( 'administrate' ) );
$FunctionList['administrate'] = array();

Eine View ohne 'functions' steht jedem offen, der die Website erreicht. Setzen Sie Einschränkungen in Ihrem Code durch, und verwenden Sie für Inhalte die eigenen Prüfungen der Inhaltsobjekte (canRead(), canEdit()). Siehe Richtlinienfunktionen und Zugriffsprüfungen.

2. Änderungen brauchen POST und das Formular-Token #

Cross-Site Request Forgery: Eine Seite anderswo bringt den Browser des Besuchers dazu, mit dessen Sitzung einen Request an Ihre Website zu senden. Abwehr:

• Ändern Sie Daten nur bei POST; ein GET-Request darf nie etwas ändern (ein <img src=".../delete/5"> würde es sonst tun).
• Die Erweiterung ezformtoken fügt jedem Formular in der Ausgabe ein verstecktes Feld ezxform_token hinzu und prüft es bei jedem POST (ezxFormToken::output() und ezxFormToken::input(), als Listener von response/output und request/input eingehängt). Lassen Sie sie aktiv. Ein POST ohne gültiges Token wird abgewiesen, bevor Ihre View läuft.
• Ajax: Exp.io sendet das Token bei seinen POST-Aufrufen mit (Ajax mit ezjscore-Serverfunktionen).

Einzelheiten: ezformtoken und CSRF-Schutz.

3. Die Ausgabe maskieren #

Wenden Sie in Templates |wash auf jeden Wert an, der von einer Person stammen kann: Namen, Titel, Suchbegriffe, View-Parameter, Attributwerte, die Sie als Text ausgeben. In PHP, das HTML erzeugt, verwenden Sie htmlspecialchars( $value, ENT_QUOTES, 'UTF-8' ). In einer JavaScript-Zeichenkette in einem Data-Attribut oder in JSON |wash( 'javascript' ) oder json_encode().

4. Sicheres SQL #

5. Eingaben sind nicht vertrauenswürdig, auch ihr Typ #

Ein gesendeter Wert kann ein Array sein (name[]=x), sehr lang sein oder fehlen. Prüfen Sie mit is_string(), bevor Sie ihn als Text behandeln, wandeln Sie Zahlen um, vergleichen Sie Auswahlwerte mit festen Listen und begrenzen Sie Längen. Die Datentypen des Kernels wurden im September 2026 auf dieselbe Weise gehärtet (Härtung der Datentyp-Eingaben).

6. Weiterleitungen führen nur dorthin, wo sie hinführen sollen #

Ein Weiterleitungsziel aus einem Formularfeld, der Sitzung oder der Adresse kann einen Besucher auf eine andere Website schicken. Verwenden Sie die Regeln des Kernels: eZRedirectManager (kernel/classes/ezredirectmanager.php) wählt ein sicheres Ziel für „zurück“ (redirectTo(), returnURI()), und seine Regeln gelten für jedes Ziel, das nicht aus dem Code selbst stammt. Siehe Sichere Weiterleitungen.

7. Dateien und Pfade #

• Bilden Sie nie einen Pfad aus einer Eingabe, ohne Verzeichnisbestandteile zu entfernen (mindestens basename()), und prüfen Sie, dass das Ergebnis innerhalb des gemeinten Verzeichnisses bleibt.
• Speichern Sie Uploads über die Datei- und Cluster-Handler des Kernels unter var/<site>/storage, nie im Web-Root.
• Senden Sie Downloads mit den Hilfsfunktionen des Kernels, die den Dateinamen sicher in Anführungszeichen setzen (eZFile::downloadHeaders()).

8. Geheimnisse #

Committen oder liefern Sie nie Schlüssel, Passwörter oder Tokens aus; lesen Sie sie aus Einstellungen, die die Installation in ihrem eigenen settings/override/ füllt, benennen Sie sie so, dass sie maskiert werden, und protokollieren Sie sie nie (.ini.append.php-Dateien und sichere Einstellungen).

9. Keine Inline-Skripte oder -Styles #

Die Content Security Policy der Administration lehnt Inline-Code ab; sie ist zugleich eine zusätzliche Verteidigungslinie gegen Cross-Site-Scripting. Siehe Content Security Policy für Autoren von Erweiterungen.

10. Erzeugter Code ist Code #

Erweiterungen, die die RAD-Assistenten schreiben, sind durch acht Schutzmechanismen gesichert (Werte können nicht aus Kommentaren oder INI-Zeilen ausbrechen, nichts wird außerhalb von extension/<name> geschrieben, erzeugte Templates maskieren die Ausgabe, erzeugte Views prüfen die Eingabe). Prüfen Sie, was jeder Generator schreibt, auch Ihre eigenen Skripte. Siehe RAD-Werkzeuge: Sicherheit.

Eine Sicherheitslücke melden #

Wenn Sie ein Sicherheitsproblem in einer Erweiterung finden, die Sie nicht geschrieben haben, melden Sie es vertraulich an deren Betreuer; für den Kernel und die se7enxweb-Erweiterungen nennt SECURITY.md die Adresse [email protected] und die vertrauliche Meldung von Sicherheitslücken auf GitHub (Die Community um Hilfe bitten).

Verwandte Seiten #

• Zurück: Kernel-Klassen-Overrides: das letzte Mittel
• Weiter: Content Security Policy für Autoren von Erweiterungen
• Eine alte Erweiterung bewerten, bevor Sie sie einsetzen
• Sicherheit und Audit
• Freie Dokumentation: Diese Seite darf unter der GNU FDL 1.3 frei kopiert, übersetzt und verbessert werden.