CMS-Sicherheit: CSRF, Rate Limiting, Verschlüsselung

Illustration der mehrschichtigen CMS-Sicherheit in AliothPress mit einem zentralen Schutzschild, umgeben von Symbolen für Authentifizierung, Verschlüsselung, Zugriffskontrolle und Audit Log.

AliothPress sichert jede Installation mehrschichtig ab: CSRF-Tokens auf allen zustandsändernden Anfragen, Rate Limiting mit automatischer Brute-Force-Sperre, optionale Zwei-Faktor-Authentifizierung mit mehrschichtiger Wiederherstellung, verschlüsselte Ablage von SMTP-Passwörtern und API-Keys, HTML-Sanitizing per Allow-List, serverseitige SVG-Bereinigung, strikte Security-Header auf jeder Antwort und ein dauerhaftes Audit-Log der Admin-Aktivität. Sessions werden in dem Moment ungültig, in dem sich ein Passwort ändert. All das ist ab Werk aktiv und braucht keine Konfiguration.

CSRF-Tokens und Rate Limiting

Jede POST-, PUT- und DELETE-Anfrage im Admin-Panel trägt einen CSRF-Token, der serverseitig geprüft wird. Eine fehlgeschlagene Prüfung liefert eine klare Meldung mit Weg zum erneuten Versuch.

Rate Limiting läuft obendrauf. Der Login-Endpunkt akzeptiert 10 Versuche pro Minute, öffentliche Formular-Übermittlungen und API-Endpunkte haben eigene Budgets pro Minute, und teure Operationen wie Update-Checks sind pro Stunde gedeckelt. Überschrittene Limits liefern eine freundliche Fehlerseite.

Brute-Force-Sperre

Fehlgeschlagene Logins werden pro IP-Adresse und Benutzername verfolgt. Fünf Fehlversuche für dieselbe Kombination aus IP und Benutzername oder zwanzig Fehlversuche von einer IP über beliebige Konten hinweg, innerhalb von 15 Minuten, sperren weitere Versuche dieser IP für 15 Minuten. Der paarbasierte Zähler hält die Sperre präzise: Ein Kollege, der sein eigenes Passwort vertippt, sperrt nicht das ganze Büro aus, während ein Angreifer, der von einer Adresse viele Konten durchprobiert, an die IP-Obergrenze stößt. Jeder Fehlversuch, jeder erfolgreiche Login und jedes Sperrereignis landet mit erfasster IP im Audit-Log. Alte Versuchsdatensätze werden automatisch aufgeräumt.

Optionale Zwei-Faktor-Authentifizierung

Konten können einen zweiten Anmeldeschritt mit zeitbasierten Einmalcodes (TOTP) hinzufügen. Jede Authenticator-App funktioniert: Die Implementierung folgt RFC 6238 und nutzt ausschließlich die Python-Standardbibliothek, es ist also kein externer Dienst beteiligt. Die Funktion ist ab Werk aus. Der Inhaber aktiviert sie in den Einstellungen für die ganze Website, und jeder Benutzer steigt danach im eigenen Profil ein: QR-Code scannen, einen live erzeugten Code bestätigen. Das Geheimnis wird verschlüsselt gespeichert, auf demselben Weg wie SMTP-Passwörter und API-Keys, und die Option „Diesem Browser vertrauen" überspringt den zweiten Schritt auf diesem Gerät für 30 Tage. Das Deaktivieren oder Zurücksetzen der 2FA macht alle vertrauten Browser auf einmal ungültig.

Die Wiederherstellung ist mehrschichtig, ein verlorenes Telefon bedeutet also kein verlorenes Konto. Bei der Einrichtung entstehen zehn Einmal-Wiederherstellungscodes, als Hashes gespeichert und mit der ersten Nutzung verbraucht. Ein Einmal-Anmeldecode kann an die E-Mail-Adresse des Kontos gehen. Inhaber und Administratoren setzen die 2FA anderer Benutzer auf der Benutzerseite zurück, wobei ein Administrator dem Inhaber den zweiten Faktor nicht entziehen kann. Und ein allein arbeitender Inhaber, der komplett ausgesperrt ist, legt neben der Anwendung eine leere Datei namens DISABLE_2FA an, die den zweiten Schritt überspringt, deutlich markiert im Interface und im Audit-Log, bis die Datei wieder entfernt ist. Einrichtung, fehlgeschlagene zweite Schritte, Resets und Umgehungen landen alle im Audit-Log.

Geheimnisse sind verschlüsselt gespeichert

SMTP-Passwörter, API-Keys der KI-Provider und Lizenzschlüssel werden symmetrisch mit Fernet verschlüsselt, bevor sie die Datenbank erreichen. Der Schlüssel leitet sich aus dem Anwendungsgeheimnis ab, das in der .env-Datei auf dem Server liegt. Ein Datenbank-Dump allein legt keine Zugangsdaten offen.

Inhalts-Sanitizing

HTML aus dem Editor durchläuft einen Allow-List-Sanitizer: Erlaubte Tags und Attribute bleiben, alles andere wird entfernt, Skript-Injektion eingeschlossen. Hochgeladene SVG-Dateien werden genauso bereinigt und verlieren Skript-Tags, Event-Handler, javascript:-URLs und externe Referenzen vor der Speicherung. Bild-Uploads sind auf eine explizite Liste von Dateiendungen beschränkt und werden bei der Verarbeitung neu kodiert.

Security-Header auf jeder Antwort

Jede Antwort trägt X-Frame-Options: SAMEORIGIN gegen Clickjacking, X-Content-Type-Options: nosniff, X-XSS-Protection, eine Referrer-Policy strict-origin-when-cross-origin und eine Permissions-Policy, die Kamera, Mikrofon und Geolokalisierung deaktiviert. Über HTTPS kommt HSTS mit einjähriger Laufzeit und Subdomain-Abdeckung hinzu.

Ein Passwortwechsel beendet jede Session

Jeder Benutzerdatensatz trägt eine Session-Version. Ein Passwortwechsel erhöht sie, und jede bestehende Session dieses Kontos funktioniert sofort nicht mehr. Ein gestohlenes Cookie stirbt mit dem alten Passwort.

Audit-Log

Wesentliche Admin-Aktionen werden aufgezeichnet: Logins, fehlgeschlagene Logins, gesperrte IPs, Inhaltsänderungen, Backup-Erstellung, Benutzerverwaltung. Jeder Eintrag speichert Benutzer, Aktion, IP-Adresse und eine Detailmeldung, die in der Admin-Sprache des Lesenden angezeigt wird. Alte Einträge werden nach Zeitplan entfernt, das Log bleibt also nützlich, ohne endlos zu wachsen.

Rollenbasierter Zugriff

Einstellungen, Benutzerverwaltung, E-Mail-Konfiguration und Wartungswerkzeuge sind den Rollen Inhaber und Administrator vorbehalten. Redakteure arbeiten ausschließlich mit Inhalten. Plugin-Installation und die Wiederherstellung von Plugins aus einem Backup sind dem Inhaber vorbehalten, weil Plugin-Dateien ausführbarer Code sind. Das vollständige Rollenmodell behandelt der Artikel Benutzer und Rollen.

Die wichtigsten Sicherheitsfunktionen in AliothPress

CSRF-Schutz auf allen Formularen, Rate Limits pro Endpunkt, eine automatische 15-Minuten-Sperre nach fünf Fehlversuchen pro Paar aus IP und Benutzername (oder zwanzig pro IP), optionale TOTP-Zwei-Faktor-Authentifizierung mit Wiederherstellungscodes und E-Mail-Ausweichweg, Fernet-verschlüsselte Zugangsdaten, HTML- und SVG-Sanitizing per Allow-List, strikte Security-Header mit HSTS, sofortige Session-Invalidierung bei Passwortwechsel und ein übersetzbares Audit-Log. Jede Schicht ist ab der ersten Anfrage nach der Installation aktiv.

Häufig gestellte Fragen

Schützt AliothPress vor Brute-Force-Angriffen auf den Login?

Ja. Fünf Fehlversuche für ein Paar aus IP und Benutzername oder zwanzig von einer IP insgesamt, innerhalb von 15 Minuten, lösen eine 15-Minuten-Sperre aus, zusätzlich zum Limit von 10 Versuchen pro Minute auf dem Login-Endpunkt. Alle Ereignisse werden mit IP im Audit-Log erfasst.

Werden SMTP-Passwörter und API-Keys im Klartext gespeichert?

Nein. Sie werden vor der Speicherung mit Fernet verschlüsselt, mit einem Schlüssel aus dem serverseitigen Anwendungsgeheimnis. Die Datenbank allein gibt sie nicht preis.

Was passiert mit aktiven Sessions bei einem Passwortwechsel?

Sie werden sofort ungültig. Jede Session trägt eine Versionsnummer, die nach dem Wechsel nicht mehr passt, und erzwingt überall eine neue Anmeldung.

Bereinigt AliothPress hochgeladene SVG-Dateien?

Ja. Skripte, Event-Handler, javascript:-URLs und externe Referenzen werden auf dem Server entfernt, bevor die Datei gespeichert wird.

Gibt es ein Protokoll der Admin-Aktivität?

Ja. Das Audit-Log erfasst Logins, Fehlversuche, Sperren, Inhaltsänderungen, Backups und Benutzerverwaltung, jeweils mit Benutzer, Aktion und IP, angezeigt in der Admin-Sprache des Betrachters.

Unterstützt AliothPress Zwei-Faktor-Authentifizierung?

Ja, als Option. Der Inhaber aktiviert sie für die ganze Website, danach schaltet jeder Benutzer sie im eigenen Profil mit einer beliebigen Authenticator-App ein. Die Wiederherstellung deckt Einmalcodes, Anmeldecodes per E-Mail, den Admin-Reset auf der Benutzerseite und eine Break-Glass-Datei für den ausgesperrten Allein-Inhaber ab.

CMS CMS Security