fix(2.9.3): Der zweite Faktor war neben der Zeremonie umgehbar

Ergebnis einer beauftragten Sicherheitsbegutachtung. Die WebAuthn-
Zeremonie selbst ist nicht angefasst worden - sie war in Ordnung. Alle
Befunde lagen DANEBEN:

  Ein zweiter Faktor ist nur so stark wie der schwaechste Weg zum Konto,
  und Sitzungen, die aus ihm entstehen, erben seinen Schutz nicht.

KRITISCH
/api/setup/v1/login prueste auf totp_secret - eine Spalte, die kein
Anmeldeweg auswertet - und nicht auf dc_user_credentials. Ein
Administratorpasswort genuegte dort fuer ein setup:install-Token ohne
Hardwarekey. Neu: Konten mit zweitem Faktor abgewiesen, und die
Rollentrennung gilt symmetrisch. Der Docblock behauptete sie seit jeher;
erzwungen hat sie nichts.

HOCH
secondFactorRequired(), accountLockoutSeconds() und lockoutSeconds()
fingen jedes Throwable und fielen auf "kein Faktor" bzw. "nicht
gesperrt" zurueck. Gefangen wurden damit auch Verbindungsabbrueche und
Lock-Timeouts - jeder davon schaltete still fuer alle Konten auf
Passwort-allein. Toleriert werden jetzt nur noch 42S02 und 42S22.

HOCH
Fuenf Aktionen aenderten die Anmeldemittel ohne erneute Bestaetigung.
Eine uebernommene Sitzung konnte sich damit dauerhaft einnisten. Neu:
Authentifizierung aus den letzten zehn Minuten noetig, geprueft an
derselben Stelle, an der auch der Leerlauf sperrt.

WEITER
- Leerlauf 30 statt 120 Minuten, und GESPERRT statt beendet: AAL2 laesst
  zur Reaktivierung einen Faktor genuegen. Wer alle 30 Minuten den
  Hardwarekey vorzeigen muss, laesst ihn stecken.
- Migration 022: session_epoch. Ein Passwortwechsel beendet die uebrigen
  Sitzungen des Kontos, die eigene bleibt.
- Kontosperre wirkt auf der zweiten Stufe; Zaehler gegen unbegrenztes
  Raten im Zwischenzustand.
- Drosselung auf login.php (10/60s) und /api/auth/v1/ (30/60s).
- Anmeldefehler ununterscheidbar; die IP-Sperre darf benannt bleiben,
  sie sagt nichts ueber ein Konto.
- HSTS, TLS-Zwang VOR allen Routen, CSP. Die CSP traegt wegen 93
  Inline-Handlern nicht gegen XSS - das steht so im Kommentar.
- session.use_strict_mode, CSRF-Token bei der Anmeldung verworfen,
  Secure-Flag aus app.url statt aus $_SERVER['HTTPS'].
- rpId/expectedOrigin nicht mehr aus dem Host-Header. /api/health meldet
  unter checks.webauthn_anchor, ob der Anker steht.
- Notfalltoken laeuft nach 180 Tagen ab, geprueft nach dem Hashvergleich.
- config.example.php ohne echtes Passwort, verify_ssl auf true.
- Serverdaten.txt.bak mitgesperrt, dc_login_attempts raeumt auf.

BELEGT
188 von 188 Testfaellen gruen, darunter drei neue in der Gruppe
"haertung". Die Blockade einer veralteten Sitzung liess sich nicht in
der Suite pruefen - sie verlangt, das Zehn-Minuten-Fenster wirklich
abzuwarten. Dafuer gibt es ein Werkzeug ausserhalb; es belegt, dass der
Formularweg auf den Sperrbildschirm fuehrt, die Regel dabei unveraendert
bleibt, der JSON-Weg reauth_required meldet und das Passwort allein
wieder oeffnet.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

.htaccess

@@ -10,6 +10,24 @@ Options -Indexes
 <IfModule mod_rewrite.c>
     RewriteEngine On
 
+    # ------------------------------------------------------------------
+    # 0. TLS erzwingen - und zwar VOR jeder Route
+    # ------------------------------------------------------------------
+    # Die Stelle ist der Punkt. Alle Routen darunter tragen [L]; stuende die
+    # Umleitung dahinter, wuerde sie fuer genau die Adressen nie erreicht,
+    # die es betrifft - login.php, index.php, die gesamte API.
+    #
+    # Ergaenzt HSTS, ersetzt es nicht: HSTS wirkt erst, nachdem der Browser
+    # die Anlage einmal ueber TLS gesehen hat. Die erste Anfrage ist genau
+    # die, die abgefangen wuerde, und die faengt diese Regel ab.
+    #
+    # Die zweite Bedingung gilt TLS-terminierenden Zwischenstellen: Dort ist
+    # %{HTTPS} leer, obwohl der Besucher verschluesselt spricht. Ohne sie
+    # liefe die Umleitung im Kreis.
+    RewriteCond %{HTTPS} !=on
+    RewriteCond %{HTTP:X-Forwarded-Proto} !=https
+    RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
+
     # Bereits umgeschriebene Anfragen nicht erneut anfassen.
     RewriteRule ^public/ - [L]
 
@@ -74,7 +92,11 @@ Options -Indexes
     # 5. Alles Uebrige sperren: Anwendungscode, Konfiguration, Skripte
     # ------------------------------------------------------------------
     RewriteRule ^(config|src|sql|scripts|cli|var|client-dotnet|client-php|mcp)(/|$) - [F,L]
-    RewriteRule ^Serverdaten\.txt$ - [F,L]
+    # Auch die Sicherungskopie. deploy.py schliesst beide aus, die Datei
+    # sollte also nie hier liegen - aber die zweite Verteidigungslinie muss
+    # zur ersten passen, sonst deckt sie genau den Fall nicht ab, fuer den es
+    # sie gibt.
+    RewriteRule ^Serverdaten\.txt(\..*)?$ - [F,L]
 </IfModule>
 
 # ----------------------------------------------------------------------
@@ -85,12 +107,47 @@ Options -Indexes
     Header always set X-Frame-Options "SAMEORIGIN"
     Header always set Referrer-Policy "strict-origin-when-cross-origin"
     Header always set Permissions-Policy "geolocation=(), microphone=(), camera=()"
+
+    # HSTS: Nach dem ersten Besuch spricht der Browser diese Adresse nur noch
+    # ueber TLS an - auch dann, wenn jemand einen http-Link unterschiebt. Die
+    # Umleitung weiter unten schuetzt erst ab der zweiten Anfrage; die erste
+    # ist genau die, die abgefangen wird.
+    #
+    # Ohne preload und ohne includeSubDomains waere es die halbe Wirkung; mit
+    # includeSubDomains gilt es fuer jede Unteradresse von mhdf.de. Wer hier
+    # eine Unteradresse ohne TLS betreibt, macht sie damit unerreichbar - das
+    # ist der Preis und der Grund, warum die Zeile bewusst hier steht und
+    # nicht in einer Vorlage.
+    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
+
+    # ------------------------------------------------------------------
+    # Content-Security-Policy - und was sie hier NICHT leistet
+    # ------------------------------------------------------------------
+    # 'unsafe-inline' steht in script-src, und das ist keine Nachlaessigkeit,
+    # sondern eine Tatsache ueber den Bestand: index.php enthaelt 93 Inline-
+    # Handler (onclick, onsubmit, onchange) und mehrere tausend Zeilen
+    # Inline-Skript. Ohne 'unsafe-inline' funktioniert die Oberflaeche nicht -
+    # mit ihr schuetzt die Richtlinie nicht gegen eingeschleustes Skript.
+    #
+    # Das ehrlich hinzuschreiben ist wichtiger, als es zu verschweigen: Eine
+    # CSP im Header laedt sonst dazu ein, XSS fuer erledigt zu halten. Was
+    # sie hier WIRKLICH leistet:
+    #   - kein Skript von fremden Adressen (Exfiltration ueber <script src>)
+    #   - keine Einbettung in fremde Seiten (frame-ancestors)
+    #   - kein umgebogenes <base> (base-uri)
+    #   - keine Formularziele ausserhalb der Anlage (form-action)
+    #   - keine Plugins (object-src)
+    #
+    # Eine Richtlinie mit Nonce, die auch gegen XSS traegt, verlangt das
+    # Herausloesen aller Inline-Handler. Das ist ein eigenes Vorhaben und
+    # kein Header.
+    Header always set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; font-src 'self' https://fonts.gstatic.com; img-src 'self' data:; connect-src 'self'; form-action 'self'; frame-ancestors 'none'; base-uri 'none'; object-src 'none'"
 </IfModule>
 
 # ----------------------------------------------------------------------
 # Dateischutz auch ohne mod_rewrite
 # ----------------------------------------------------------------------
-<FilesMatch "^(Serverdaten\.txt|\.env.*|composer\.(json|lock)|deploy_config\.json)$">
+<FilesMatch "^(Serverdaten\.txt(\..*)?|\.env.*|composer\.(json|lock)|deploy_config\.json)$">
     <IfModule mod_authz_core.c>
         Require all denied
     </IfModule>