Sicherheitsupdates und Offenlegung #

Diese Seite ist für die Sicherheitsverantwortlichen und die Systemadministratoren eines Hosters, die viele Exponential-Websites aktuell halten, und für Support-Mitarbeitende, die eine Meldung über eine mögliche Schwachstelle erhalten. Sie sagt, welche Versionen unterstützt werden, wie eine Korrektur eine Website erreicht und wie Sie ein Problem melden. Die Richtlinie selbst ist die SECURITY.md des Repositorys; die Routine für Updates ist 13.15 Aktuell bleiben.

Inhalt #

1. Unterstützte Versionen
2. Wie Korrekturen veröffentlicht werden
3. Releases verfolgen
4. Updates ausrollen
5. Dateien nach einem Update prüfen
6. Alles andere, was Updates braucht
7. Eine Schwachstelle melden
8. Kunden informieren
9. Checkliste

Unterstützte Versionen #

Aus SECURITY.md:

Sicherheitskorrekturen werden auf main gemacht und mit dem nächsten Release 6.0.x veröffentlicht. Websites auf älteren Linien, einschließlich derer, die noch das Produkt betreiben, das sein Hersteller nach fast 18 Jahren eingestellt hat, erhalten keine Korrekturen; planen Sie ihre Migration (Kunden migrieren: Überblick).

Wie Korrekturen veröffentlicht werden #

Ein veröffentlichtes Tag wird nie geändert. Eine Korrektur für ein Problem in einem früheren Tag erreicht Sie als nächstes Release, nicht als korrigierte Kopie des alten. Releases sind unveränderliche Tags auf Packagist und GitHub, mit Changelogs. Für einen Hoster heißt das:

• Die Versionsnummer, die eine Website meldet, ist verlässlich: Dieselbe Version ist überall derselbe Code.
• Die Frage, ob eine Website gepatcht ist, wird beantwortet, indem Sie ihre Version mit dem Release vergleichen, das das Problem korrigiert hat.
• Jede Erweiterung ist ein eigenes Composer-Paket mit eigenen Releases; verfolgen Sie auch diese.

Releases verfolgen #

composer outdated                 # what is newer than the locked versions
composer audit                    # known vulnerabilities in the locked dependencies
composer show se7enxweb/exponential   # the version a site runs

Führen Sie diese pro Installation aus einem zentralen Job aus und sammeln Sie die Ergebnisse, oder nutzen Sie den Bildschirm Setup > Updates and packages der Erweiterung ezupdate, dessen Suche nach Updates nichts ändert (ezupdate, Automatische Updates mit ezupdate). Halten Sie composer.lock in der Versionsverwaltung jeder Website, damit das Ergebnis auf jeder Maschine dasselbe ist.

Updates ausrollen #

1. Lesen Sie den Changelog und die Hinweise zum Upgrade des Release (Upgrades, Kapitel 11).
2. Aktualisieren Sie zuerst eine Kopie (eine Staging-Kopie der Website des Kunden oder eine repräsentative Test-Website).
3. Dann die Live-Website: composer update <package>, die Datenbank-Updates, die das Release nennt, dann php bin/php/console exp:velocity deploy (oder Autoloads, Leeren des Caches und ein Neuladen von PHP-FPM von Hand).
4. Prüfen Sie die Konsistenz der Dateien (unten).
5. Machen Sie einen Rauchtest der Startseite und der Anmeldung der Administration.

Für viele Websites auf einmal: Kunden-Websites aktualisieren und Änderungen ausrollen. Nutzen Sie den Wartungsmodus, wo das Update Änderungen an der Datenbank braucht.

Hinweis Ob Sicherheitsupdates vom Hoster automatisch, in einem festen Zeitfenster oder nur mit Zustimmung des Kunden eingespielt werden, ist eine Entscheidung für jeden Tarif. Die Quellen setzen keinen Zeitrahmen; der Hoster wählt einen und nennt ihn in seiner Leistungsbeschreibung (SLA-Optionen).

Dateien nach einem Update prüfen #

Setup > Upgrade-Prüfung vergleicht jede Datei mit der share/filelist.md5 des Release (Überprüfe Dateikonsistenz) und das Schema mit dem des Release (Überprüfe Datenbankkonsistenz). Beide lesen nur. Dasselbe aus einer Shell, ohne Datenbank:

php bin/php/checkmanifest.php --all                 # exit 0 when nothing is modified or missing
php bin/php/checkmanifest.php --all --extensions    # also extensions with their own manifest

Eine veränderte Datei des Kernels, die niemand geändert hat, verdient einen Blick; siehe Kompromittierte Website (Die Upgrade-Prüfung).

Alles andere, was Updates braucht #

• PHP, der Datenbankserver und das Betriebssystem.
• Die Engine von Velocity (auch ihre Releases korrigieren Sicherheitsprobleme), dann exp:velocity deploy.
• Die Binärdatei von FrankenPHP: Version und Prüfsummen sind in [FrankenPHPSettings] Version und Sha256[] festgelegt; ändern Sie sie zusammen.
• Die eigenen Erweiterungen des Kunden: Prüfen Sie sie auf die Muster, die im Kernel korrigiert wurden (SQL aus Anfragedaten gebaut, Shell-Befehle ohne escapeshellarg(), Ausgabe ohne Maskierung), und erzeugen Sie Erweiterungen neu, die von den RAD-Assistenten vor deren Korrektur erstellt wurden (RAD-Werkzeuge: Sicherheit, Hinweise zur Härtung in 6.0.13).
• request-shield, wenn installiert, als eigenes Paket.

Eine Schwachstelle melden #

Melden Sie Sicherheitsprobleme vertraulich, nie in einem öffentlichen Issue-Tracker oder einer Diskussion:

• per Mail an [email protected] oder
• als vertraulichen Sicherheitshinweis auf GitHub: https://github.com/se7enxweb/exponential/security/advisories/new.

SECURITY.md sagt, dass eine erste Antwort innerhalb eines Werktags zu erwarten ist. Geben Sie an:

• die Version (composer show se7enxweb/exponential oder das Tag oder den Commit) und die PHP-Version;
• die Engine, die die Website ausliefert (Velocity, FrankenPHP, Apache oder nginx mit PHP-FPM), und die Datenbank;
• was ein Angreifer tun kann, und die Schritte, um es nachzustellen.

Lassen Sie Passwörter, Geheimnisse und personenbezogene Daten weg, auch die des Kunden, dessen Website das Problem gezeigt hat. Die meldende Person erfährt, ob die Meldung angenommen wird, und wird auf dem Laufenden gehalten, während eine Korrektur vorbereitet wird; ein angenommenes Problem wird auf main korrigiert und mit der nächsten Version 6.0.x veröffentlicht. Probleme in einer Erweiterung von Dritten gehen an deren Betreuer; die Seite zum Melden der Hilfe erklärt die Tracker.

Kunden informieren #

Wenn ein Release ein Sicherheitsproblem korrigiert, kann ein Hoster wählen:

• betroffene Kunden zu informieren, welche Websites wann aktualisiert wurden;
• für Websites, die nicht sofort aktualisiert werden können, die Lücke mit einem Datum zu dokumentieren, bis zu dem sie geschlossen wird, wie die Checkliste für die Sicherheitsprüfung es verlangt;
• nie Details eines nicht korrigierten Problems zu veröffentlichen, bevor das Projekt die Korrektur veröffentlicht hat.

Checkliste #

• To do: Jede Website auf der neuesten 6.0.x, oder die Lücke mit einem Datum dokumentiert.
• To do: composer outdated und composer audit regelmäßig für jede Installation ausgeführt; composer.lock in der Versionsverwaltung.
• To do: Updates zuerst auf einer Kopie getestet; Konsistenz der Dateien nach jedem Update geprüft.
• To do: PHP, Datenbankserver, Betriebssystem, die Engine von Velocity und Erweiterungen in der Routine enthalten.
• To do: Eine benannte verantwortliche Person, die Release-Hinweise liest und Sicherheitsmails empfängt.
• To do: Support-Mitarbeitende kennen den vertraulichen Meldeweg und nutzen nie einen öffentlichen Tracker für Sicherheitsmeldungen.

Verwandte Seiten #

• Sicherheit für Hoster: Überblick
• SECURITY.md
• Sicherheitshärtung: Eine Schwachstelle melden
• Mit dem Projekt und 7x zusammenarbeiten
• Kunden-Websites aktualisieren
• Freie Dokumentation: Diese Seite darf unter der GNU FDL 1.3 frei kopiert, übersetzt und verbessert werden.