feat(security): Haertung nach OWASP Top 10 (#024)

Drei echte Luecken gefunden und geschlossen:

1. Die 27 Server Actions verliessen sich allein auf proxy.ts. Jede prueft die
   Sitzung jetzt selbst und schlaegt gegen die Datenbank nach, ob das Konto
   noch gilt - damit lassen sich Sitzungen ueberhaupt erst widerrufen.
2. Der Anmelde-Endpunkt prueft die Herkunft des Formulars; vorher war
   Login-CSRF moeglich.
3. Content-Security-Policy mit Nonce je Anfrage und strict-dynamic.

Dazu: npm audit ist ohne Befund (mysql2 und deepmerge-ts per overrides
angehoben statt Prisma zurueckzustufen), eine Benutzerverwaltung fuer die
Kommandozeile und docs/sicherheit.md mit allem, was bewusst offen bleibt -
keine Rollen, keine Zwei-Faktor-Anmeldung.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

docs/issues/024-owasp-haertung.md

@@ -0,0 +1,34 @@
+# #024 Härtung nach OWASP
+**Status:** erledigt
+**Meilenstein:** v0.15.0
+**Labels:** security, backend
+**Geschätzt:** 4 h   **Tatsächlich:** 0 h 45 min
+
+## Ziel
+Vor der Freigabe als fertiges Produkt eine Durchsicht gegen die OWASP Top 10 – und die gefundenen
+Lücken schließen, statt sie zu vermerken.
+
+## Aufgaben
+- [x] Zugriffskontrolle: jede Server Action prüft die Sitzung selbst, nicht nur der Proxy
+- [x] Sitzungen widerrufbar machen (gesperrtes Konto, neues Passwort)
+- [x] Login-CSRF: Herkunft der Anmeldung prüfen
+- [x] Content-Security-Policy mit Nonce je Anfrage
+- [x] Abhängigkeiten ohne bekannte Schwachstellen (`npm audit`)
+- [x] Benutzerverwaltung auf der Kommandozeile (sperren, entsperren, Passwort)
+- [x] `docs/sicherheit.md` mit der Zuordnung zu den OWASP Top 10
+- [x] Tests für Sitzungsurteil und Herkunftsprüfung
+
+## Gefunden und behoben
+1. **Server Actions waren nur durch `proxy.ts` geschützt.** Keine einzige Aktion prüfte selbst. Der
+   Proxy greift zwar auch bei POST, aber eine einzige Schicht ist zu wenig für 27 schreibende Endpunkte.
+2. **Login-CSRF möglich:** Der Anmelde-Endpunkt ist ein gewöhnliches Formular und prüfte die Herkunft
+   nicht. Eine fremde Seite hätte jemanden in ein untergeschobenes Konto anmelden können.
+3. **Keine CSP.** Jetzt mit Nonce und `strict-dynamic`.
+4. **Sitzungen ließen sich nicht beenden.** Ein gesperrtes Konto arbeitete bis zu zwölf Stunden weiter.
+5. **`npm audit`: 4 hohe Meldungen** in `mysql2` und `deepmerge-ts` – beides Beiwerk von Prisma. Über
+   `overrides` angehoben statt Prisma zurückzustufen; danach keine Meldung mehr.
+
+## Bewusst nicht umgesetzt
+- **Rollen:** Wer angemeldet ist, darf alles. Für ein internes Werkzeug vertretbar, in `docs/sicherheit.md` vermerkt.
+- **Zwei-Faktor-Anmeldung:** Wer sie braucht, nutzt OIDC.
+- Die Einschränkung der OIDC-Anmeldung (erlaubte Domänen, automatisches Anlegen) kommt mit #025.

docs/issues/README.md

@@ -27,4 +27,5 @@ Details und Architektur: [../architektur.md](../architektur.md). Zeiten werden a
 | [#021](021-geheimnisse-verschluesseln.md) | Zugangsdaten verschlüsselt speichern | erledigt | v0.13.1 | 2 h | 0 h 20 min |
 | [#022](022-cluster-abgleich.md) | Cluster-Abgleich | erledigt | v0.14.0 | 3 h | 0 h 25 min |
 | [#023](023-feldtest-pbs-pmg.md) | Feldtest auf PBS und PMG | offen | v1.0.0 | 2 h | 0 h 35 min (PBS erledigt, PMG offen) |
-| | **Summe** | | | **121 h** | **9 h 43 min** |
+| [#024](024-owasp-haertung.md) | Härtung nach OWASP | erledigt | v0.15.0 | 4 h | 0 h 45 min |
+| | **Summe** | | | **125 h** | **10 h 28 min** |

docs/sicherheit.md

@@ -0,0 +1,101 @@
+# Sicherheit
+
+Dieses Dokument hält fest, was ProxLedger gegen die üblichen Angriffe tut – und was es **nicht** tut.
+Die Gliederung folgt den OWASP Top 10 (2021).
+
+## A01 – Fehlerhafte Zugriffskontrolle
+
+- `src/proxy.ts` schickt jede Anfrage ohne gültige Sitzung zur Anmeldung. Öffentlich sind nur die
+  Anmeldung, die Agent-API (eigene Tokens), die Gesundheitsprüfung, die beiden Agent-Skripte und die Symbole.
+- **Jede Server Action prüft zusätzlich selbst** (`sitzungErforderlich()`). Server Actions sind eigene
+  Endpunkte; eine einzige Schutzschicht davor wäre zu wenig, falls der Musterausdruck im Proxy je
+  danebengreift.
+- Die Prüfung geht in die Datenbank: Ein gesperrtes Konto oder ein Widerruf beendet laufende Sitzungen
+  sofort (`npm run benutzer -- sperren <email>`), statt bis zum Ablauf des Tokens zu warten.
+- Die Anmeldung prüft den `Origin`, damit keine fremde Seite jemanden unbemerkt in ein untergeschobenes
+  Konto anmeldet (Login-CSRF). Für Server Actions erledigt das Next.js selbst.
+
+**Nicht vorhanden:** Rollen. Wer angemeldet ist, darf alles. Für ein Werkzeug, das ein Systemhaus intern
+betreibt, ist das vertretbar – für mehrere Mandanten wäre es das nicht.
+
+## A02 – Kryptografische Fehler
+
+- Passwörter: argon2id (`@node-rs/argon2`), keine eigene Krypto.
+- Sitzungen: signiertes JWT (HS256) aus `APP_SECRET`, 12 Stunden gültig, Cookie `httpOnly`, `sameSite=lax`
+  und `secure`, sobald `APP_URL` auf `https://` steht.
+- Zugangsdaten für SMTP und Webhooks liegen AES-256-GCM-verschlüsselt in der Datenbank
+  (`src/lib/geheimnisse.ts`); der Schlüssel wird aus `APP_SECRET` abgeleitet.
+- Agent- und Enrollment-Tokens werden nur als SHA-256-Hash gespeichert. Das ist hier richtig und nicht
+  zu schwach: Die Tokens sind 32 Byte Zufall, es gibt nichts zu raten.
+
+**Wichtig:** `APP_SECRET` ist der Generalschlüssel. Geht er verloren, sind alle Sitzungen ungültig und die
+gespeicherten Zugangsdaten unlesbar. Er gehört in die Sicherung.
+
+## A03 – Injektion
+
+- Datenbankzugriffe ausschließlich über Prisma mit gebundenen Werten; kein `$queryRawUnsafe` im Projekt.
+- Ausgaben maskiert React selbst.
+- Zusätzlich greift eine Content-Security-Policy mit frischem Nonce je Anfrage und `strict-dynamic`
+  (`src/proxy.ts`). Eingeschleustes `<script>` – etwa über einen manipulierten Hostnamen aus einer
+  Proxmox-Ausgabe – läuft damit nicht.
+- Der Agent baut sein JSON mit einer eigenen Maskierung; Sonderzeichen aus Proxmox-Ausgaben sind als
+  Testfall hinterlegt.
+
+## A04 – Unsicheres Design
+
+- Push-Modell: Das Dashboard braucht **keinen** Zugang zu den Proxmox-Hosts. Es gibt keine gespeicherten
+  root-Zugänge, die abhandenkommen könnten – die Hosts melden von sich aus.
+- Der Agent sendet nur Statusangaben (Subscription, Version, Sockel, IPs). Keine Gastliste, keine Daten.
+- Enrollment-Tokens sind befristet und in der Zahl der Nutzungen begrenzt.
+
+## A05 – Sicherheitsrelevante Fehlkonfiguration
+
+- Kopfzeilen: `X-Content-Type-Options`, `X-Frame-Options: DENY`, `Referrer-Policy`, `Permissions-Policy`,
+  `Strict-Transport-Security` (`next.config.ts`) sowie die CSP aus dem Proxy.
+- Die Anwendung startet nicht mit zu kurzem `APP_SECRET`.
+- Im Container läuft die Anwendung als unprivilegierter Benutzer; Anhänge werden mit Rechten 640 abgelegt.
+- Fehlermeldungen nennen keine Einzelheiten: Bei der Anmeldung steht dieselbe Meldung für „Adresse
+  unbekannt“ und „Passwort falsch“.
+
+## A06 – Verwundbare Komponenten
+
+- `npm audit --omit=dev` meldet **keine** bekannten Schwachstellen (Stand 18.09.2026).
+- Zwei Fassungen werden über `overrides` angehoben: `mysql2` und `deepmerge-ts` kommen als Beiwerk von
+  Prisma mit, obwohl wir Postgres nutzen. Ohne die Anhebung bliebe nur ein Rückschritt auf Prisma 6.
+- Die CI prüft bei jedem Push (#019).
+
+## A07 – Fehler bei Identifizierung und Authentifizierung
+
+- Ratenbremse: fünf Anmeldeversuche je Kennung und Viertelstunde.
+- Anmeldung wahlweise per Passwort oder OIDC (authentik, mit PKCE und `state`).
+- Jede Anmeldung – erfolgreich oder nicht – landet im Audit-Log.
+
+**Nicht vorhanden:** Zwei-Faktor-Anmeldung. Wer sie braucht, stellt OIDC davor und schaltet die
+Passwortanmeldung ab.
+
+## A08 – Datenintegrität
+
+- Der Agent prüft vor dem Selbstaktualisieren, ob die geladene Datei wie ein Bash-Skript beginnt.
+- Webhooks werden mit HMAC-SHA256 signiert, damit die Gegenstelle die Herkunft prüfen kann.
+- Hochgeladene Rechnungen werden nicht dem gemeldeten Typ nach beurteilt, sondern am Dateianfang
+  geprüft (`%PDF-`), auf 10 MB begrenzt und unter ihrer Prüfsumme abgelegt.
+
+## A09 – Protokollierung
+
+- Audit-Log für Anmeldungen, Änderungen an Kunden, Rechnungen, Tokens, Kanälen und Warnregeln –
+  einsehbar unter *Einstellungen → Protokoll*.
+- Der Agent protokolliert auf dem Host über `logger` ins Journal.
+
+## A10 – Server-Side Request Forgery
+
+- Die einzige ausgehende Verbindung, die sich einstellen lässt, ist der Benachrichtigungs-Webhook. Er
+  wird bewusst von einem Angemeldeten eingetragen und ist damit kein fremdgesteuerter Aufruf.
+- Sonst ruft das Dashboard keine Adressen auf, die aus Daten stammen.
+
+## Was ein Betreiber selbst tun muss
+
+1. HTTPS davorschalten (Beispiele unter `deploy/reverse-proxy/`) und `APP_URL` auf `https://` setzen.
+2. `APP_SECRET` und die Datenbank sichern (`deploy/backup.sh`).
+3. Das Dashboard nicht ins offene Internet stellen, wenn es nicht sein muss. Die Agent-API muss
+   erreichbar sein, die Oberfläche nicht.
+4. Enrollment-Tokens nach dem Ausrollen widerrufen.