Sicherheit im CMF

Passwörter werden mit bcrypt gehasht – dem aktuellen Standard für Passwort-Hashing. Selbst bei einem Datenleck sind die Klartext-Passwörter nicht rekonstruierbar.

Beim Login wird password_verify() verwendet – zeitkonstanter Vergleich, immun gegen Timing-Angriffe. Der Benutzername wird mit hash_equals() verglichen.

API-Tokens werden als SHA-256-Hash gespeichert. Der Klartext wird nur einmal beim Erstellen angezeigt – danach existiert er nirgends im System.

Bei jedem API-Request wird der mitgesendete Token gehasht und mit dem gespeicherten Hash verglichen. Kein Klartext-Vergleich, kein Timing-Leak.

Fehlgeschlagene Login-Versuche werden pro IP gezählt. Die Wartezeit steigt exponentiell: 5 Sekunden, 15, 30, 60 – bis maximal 1 Stunde.

Der Schutz ist dateibasiert (login_attempts.json), braucht keinen Redis oder Memcached. Nach erfolgreichen Login wird der Zähler zurückgesetzt.

Jede POST-Aktion im Backend erfordert einen CSRF-Token. Der Token wird pro Session generiert und in jedem Formular als Hidden-Field mitgesendet.

Ohne gültigen Token wird die Aktion abgelehnt. Das schützt vor Cross-Site-Request-Forgery – ein Angreifer kann keine Aktionen im Namen des eingeloggten Benutzers auslösen.

Text-Blöcke werden beim Rendern durch den Sanitizer geschickt. Er entfernt:

• Event-Handler – onclick, onerror etc.
• Gefährliche URLs – javascript: und data: in href/src
• Style-Attribute – verhindert CSS-Expressions
• Unerlaubte Tags – nur 15 sichere Tags bleiben

Der html-Block wird bewusst nicht sanitized – er ist für vertrauenswürdige Autoren gedacht.

JSON-Dateien werden nie direkt überschrieben. Stattdessen: in eine temporäre Datei schreiben, dann per rename() atomar ersetzen.

Dazwischen LOCK_EX für exklusiven Dateizugriff. Wenn der Strom ausfällt oder der Prozess abbricht, bleibt die alte Datei intakt. Kein halbbeschriebenes JSON, kein Datenverlust.

Sensible Dateien liegen außerhalb des öffentlichen Verzeichnisses:

• config/users.json – Benutzer und Token-Hashes
• config/site.json – Seitenkonfiguration
• config/styles.json – Design-Tokens
• app/ – gesamter PHP-Code

Nur public/ ist per Web erreichbar. Direkte Zugriffe auf PHP-Dateien außerhalb des Einstiegspunkts werden per .htaccess blockiert.

Die .htaccess konfiguriert:

• URL-Rewriting – alle Requests gehen durch index.php
• GZIP-Kompression – für CSS, JS und HTML
• Browser-Caching – statische Dateien werden gecacht
• Direktzugriff blockiert – keine .json, .env oder .php Dateien direkt aufrufbar

Kein manuelles Einrichten nötig – die Datei ist im System enthalten und funktioniert auf Apache-Webservern sofort.

Keine Datenbank bedeutet auch: keine datenbankspezifischen Angriffsvektoren.

• Keine SQL-Injection – es gibt kein SQL
• Kein DB-Passwort – keine Zugangsdaten die leaken können
• Keine offenen Ports – kein MySQL-Server der erreichbar sein muss
• Keine DB-Backups vergessen – es gibt nur Dateien

Auch ohne Datenbank gibt es Angriffsflächen. Das CMF adressiert sie alle:

• XSS → HTML-Sanitizing in Text-Blöcken, htmlspecialchars() überall
• CSRF → Token-basierter Schutz für alle POST-Aktionen
• Brute-Force → Exponentielle Wartezeit pro IP
• Session-Hijacking → ID-Regenerierung nach Login
• Path-Traversal → Keine User-Inputs in Dateipfaden

• Document Root auf public/ setzen
• Standard-Passwort sofort ändern
• HTTPS verwenden
• PHP und Webserver aktuell halten

• API-Tokens nur an vertrauenswürdige Systeme
• Eigenen Benutzer für Automatisierung anlegen
• Regelmäßige Backups per Export
• Token regelmäßig erneuern

• Admin-Bereich per IP einschränken
• Additional Security Headers setzen
• Rate-Limiting auf Webserver-Ebene
• Monitoring für Dateiänderungen