Sicherheitsprüfung 2 – CMS: Zusammenfassung des gesamten Verlaufs

1. Ausgangslage

Zu Beginn wurde das CMS allgemein sicherheitstechnisch bewertet, mit dem Fokus darauf, welche Punkte bereits gut umgesetzt sind und welche Bereiche noch kritisch oder unvollständig sind.

Als bereits positiv bewertet wurden unter anderem:

Helmet, CSP, sichere Session-Cookies für den Adminbereich, Session-Regeneration nach Login, parameterisierte SQL-Abfragen, HTML-Bereinigung vor der Ausgabe sowie die Trennung von Download-Dateien vom Webroot.

2. Session-Store produktionsfest gemacht

Als erster konkreter Punkt wurde der Session-Bereich überarbeitet.

Es wurde festgestellt, dass zwar bereits eine eigene Datei für einen MariaDB-Session-Store vorhanden war, diese aber nicht aktiv in der Session-Konfiguration verwendet wurde.

Daraufhin wurden folgende Änderungen umgesetzt:

server.js wurde angepasst, damit der MariaDbSessionStore tatsächlich als Session-Store genutzt wird.

src/middleware/sessionStore.js wurde vollständig auf eine persistente Session-Verwaltung mit Ablaufzeit und Cleanup-Intervall ausgelegt.

src/db/init.sql wurde um die Tabelle sessions erweitert.

Damit werden Sessions jetzt nicht mehr im unsicheren Standard-Memory-Store gehalten, sondern sauber in der Datenbank gespeichert.

3. IP-Ermittlung abgesichert

Im zweiten Schritt wurde die Client-IP-Ermittlung überarbeitet.

Vorher wurden an mehreren Stellen Werte direkt aus x-forwarded-for verarbeitet. Das ist problematisch, weil der Header manipulierbar ist, wenn die Anwendung nicht vollständig geschützt nur hinter einem sauberen Reverse Proxy betrieben wird.

Deshalb wurden folgende Punkte umgesetzt:

server.js wurde mit trust proxy sauber konfiguriert.

Eine neue zentrale Datei src/utils/clientIp.js wurde eingeführt.

src/middleware/rateLimit.js wurde auf die zentrale IP-Ermittlung umgestellt.

src/services/auditLogService.js wurde so vorbereitet, dass auch dort die IP zentral und normalisiert verarbeitet wird.

src/services/pageViewService.js wurde ebenfalls auf diese zentrale IP-Ermittlung umgebaut.

Dadurch laufen Rate-Limit, Tracking und spätere Audit-Einträge jetzt konsistenter und weniger manipulierbar.

4. Validierung zentralisiert und verschärft

Danach wurde die Eingabevalidierung als nächster Sicherheitsblock umgesetzt.

Dafür wurde zunächst eine zentrale Validator-Datei aufgebaut:

src/utils/validators.js

Darin wurden Funktionen für Pflichtfelder, optionale Strings, Slugs, URLs, Integer, Datumswerte, Inhalte, Benutzernamen und Passwörter definiert.

Anschließend wurde die Validierung auf die wichtigsten Services und Admin-Routen ausgerollt:

src/services/pageService.js

src/services/postService.js

src/services/projectService.js

src/services/downloadService.js

src/services/settingsService.js

src/routes/admin.js

Damit werden jetzt unter anderem:

leere oder zu kurze Titel verhindert

unsaubere Slugs abgefangen

URLs geprüft

zu große Inhalte begrenzt

unsichere oder zu schwache Passwörter blockiert

Formularfehler sauber an die Admin-Oberfläche zurückgegeben

5. Audit-Logging in MariaDB eingebaut

Als nächstes wurde das Audit-Logging umgesetzt.

Die Entscheidung fiel bewusst auf Datenbank statt .log-Datei, weil das für ein Livesystem sauberer, filterbarer und langfristig besser auswertbar ist.

Dafür wurden folgende Komponenten eingeführt bzw. erweitert:

src/db/init.sql wurde um die Tabelle audit_logs ergänzt.

src/models/auditLogModel.js wurde erstellt.

src/services/auditLogService.js wurde erstellt bzw. erweitert.

src/routes/admin.js wurde an allen wichtigen Stellen mit Audit-Schreibvorgängen versehen.

Geloggte Vorgänge sind jetzt zum Beispiel:

Admin-Setup erfolgreich oder fehlgeschlagen

Logout erfolgreich oder fehlgeschlagen

Seiten erstellen, bearbeiten, löschen

Beiträge erstellen, bearbeiten, löschen

Projekte erstellen, bearbeiten, löschen

Downloads erstellen, bearbeiten, löschen

Einstellungen und Logo-Änderungen

Zusätzlich wird die IP nicht im Klartext gespeichert, sondern gehasht.

6. Audit-Ansicht im Adminpanel ergänzt

Nachdem das Schreiben der Audit-Daten funktionierte, wurde anschließend auch die Ansicht dafür nachgezogen.

Dafür wurden ergänzt:

src/models/auditLogModel.js mit einer Lesefunktion für die letzten Einträge

src/services/auditLogService.js mit einer aufbereiteten Ausgabe für die Ansicht

src/routes/admin.js um die Route /admin/audit

views/admin/audit.hbs als Oberfläche zur Darstellung der letzten 100 Audit-Einträge

Damit ist das Audit-Logging jetzt nicht nur aktiv, sondern auch direkt im Adminpanel sichtbar.

7. Ergebnis des bisherigen Sicherheitsdurchlaufs

Bis zu diesem Punkt wurden die folgenden Hauptbereiche des CMS gehärtet:

Sessions wurden auf einen produktionsfähigen MariaDB-Store umgestellt.

IP-Verarbeitung wurde zentralisiert und sicherer gemacht.

Validierung wurde systemweit deutlich verschärft.

Audit-Logging wurde vollständig eingebaut und im Adminbereich sichtbar gemacht.

Die Änderungen wurden jeweils schrittweise eingespielt und nach jedem Block geprüft, ohne dass dabei laut Rückmeldung sichtbare Fehler aufgetreten sind.

8. Nächster empfohlener Sicherheits-Schritt

Als nächster sinnvoller Punkt wurde die Upload-Härtung empfohlen.

Begründung:

Uploads sind ein klassischer Angriffsvektor

Logo-Upload und Download-Upload laufen bereits produktiv

die bisherige Prüfung über MIME-Type und Dateiendung allein reicht nicht aus

Dafür wurden als kommende Maßnahmen vorgeschlagen:

echte Dateisignaturprüfung

harte Whitelists für erlaubte Formate

sofortiges Löschen fehlerhafter Uploads

engere Größenlimits

sauberer CSRF-Flow bei Multipart-Uploads

9. Gesamtfazit

Der Verlauf war kein oberflächlicher Check, sondern eine schrittweise Härtung des CMS im Livesystem.

Die wichtigsten Fundament-Punkte wurden bereits umgesetzt:

Session-Sicherheit, IP-Vertrauen, Eingabevalidierung, Nachvollziehbarkeit über Audit-Logs.

Das System ist damit deutlich stabiler und sicherer als zu Beginn des Verlaufs.

Der nächste logische Block ist jetzt die Absicherung des Upload-Bereichs.