leocrm/FIX-PLAN-V2.md

# LeoCRM Fix-Plan V2 — Gründliche Analyse & Maßnahmen

*Erstellt: 2026-07-26 — basierend auf externem Audit + eigener Code-Verifikation*

---

## Zusammenfassung

Von 16 zentralen Punkten des externen Audits wurden **alle 16 durch Code-Inspektion verifiziert**. Zusätzlich wurden **5 neue Probleme** gefunden (UploadFile-Bug, Redis-Default-Passwort, exponierte Ports, unauthentifizierter Error-Endpoint, fehlende Security-Headers).

**Gesamtstatus:** Alle Phasen implementiert (Stand 2026-07-27). M5 (Frontend-Integration) als letzte Phase abgeschlossen.

---

## Implementierungs-Status (Stand 2026-07-27)

Die folgenden Phasen wurden gemäß Git-Historie implementiert:

| Phase | Commit | Maßnahmen | Status |
|-------|--------|-----------|--------|
| **Phase 1** (B1-B10) | `5ec1fc9` | Kritische Release-Blocker: Redis-Singleton (B1), Plugin-Routen (B2), UploadFile response_model (B3), DMS-Streaming (B4), Outbox-Worker (B5), Passwort-Reset-Mail (B6), Webhook-SSRF (B7), RLS-DB-Role (B8), .env-Korrektur (B9), Redis-Ports (B10) | ✅ Implementiert |
| **Phase 2** (H1-H7) | `604a2b7` | Error-Endpoint (H1), Rate-Limiter (H2), CSRF-Redis (H3), WebSocket-Auth (H4), File-Upload (H5), Security-Headers (H6), Migration-Repair (H7) | ✅ Implementiert |
| **Phase 3** (M1-M4, M6) | `825d638` | Passwort-Komplexität (M1), Login-Response (M2), Permission-Cache (M3), ENVIRONMENT (M4), weitere (M6) | ✅ Implementiert |
| **Phase 4** | `b6e3afd` | Webhooks, Backup/Restore UI, Onboarding/Tutorial | ✅ Implementiert |
| **Plugin-System-Umbau** | `98eb1d0` | Plugin-Routen nur in create_app(), require_active_plugin() Dependency, WebSocket-Skip | ✅ Implementiert |

### Verifizierte P0-Behebungen

| P0 | Problem | Status | Beweis |
|----|---------|--------|--------|
| P0-1 | Auth-Bypass via X-Internal-Call | ✅ Behoben | `app/deps.py` hat keinen X-Internal-Call Code mehr. Auth nur via Session-Cookie. |
| P0-2 | Destruktive Migrationen | ✅ Behoben | Migration 0021 benennt Tabellen um (`*_old`). Migration 0044 repariert RLS. |
| P0-3 | Plugin-Upload RCE | ✅ Neutralisiert | Alle Upload-Endpoints deaktiviert (403). `_extract_plugin_from_zip()` ist Dead Code. |
| P0-4 | RLS nicht erzwungen | ✅ Behoben | Migration 0028 setzt FORCE RLS. Migration 0044 erstellt `crm_runtime` (NOSUPERUSER, NOBYPASSRLS). |
| P0-5 | Plugin-Doppelregistrierung | ✅ Behoben | Routen nur in create_app(). require_active_plugin() prüft Aktivierungsstatus. |
| P0-6 | Kein persistentes Volume | ✅ Behoben | docker-compose.yml hat volumes für PostgreSQL, Redis, App-Uploads, Worker. |
| P0-7 | Öffentliche Domain | ✅ Behoben | Keine crm.media-on.de Referenz mehr in docker-compose.yml. |

### Weitere verifizierte Behebungen
- **B1** (doppelte get_redis()): ✅ Nur eine Definition in `app/core/auth.py` Zeile 53
- **B3** (UploadFile response_model): ✅ `response_model=None` in dms, calendar, mail routes
- **B7** (Webhook SSRF): ✅ Private IP-Check, `follow_redirects=False`, Protokoll-Check
- **B9** (AUTH_SECRET vs SECRET_KEY): ✅ `.env.docker.example` verwendet `SECRET_KEY`
- **B10** (Redis-Default-Passwort + Ports): ✅ Ports auskommentiert, Redis-Passwort required
- **WebSocket Auth**: ✅ Beide WS-Endpunkte haben `verify_ws_origin()`, Session-Cookie-Validierung, `user_id` aus Session

---

## Phase 1: Kritische Release-Blocker (vor Produktivbetrieb)

### B1. Doppelte `get_redis()` entfernen
- **Datei:** `app/core/auth.py` Zeilen 53 + 94
- **Problem:** Zweite Definition überschreibt Singleton, erzeugt pro Aufruf neue Verbindung → Connection Leak
- **Fix:** Zweite `def get_redis()` (Zeile 94) löschen. Erste Definition (Zeile 53) beibehalten.
- **Aufwand:** 5 Min
- **Risiko:** Keines — erste Definition ist korrekt

### B2. Plugin-Routen-Registrierung reparieren
- **Datei:** `app/main.py` Zeilen 375-416
- **Problem:** Alle Plugin-Routen werden statisch in `create_app()` registriert, unabhängig vom Aktivierungsstatus. Deaktivierte Plugins bleiben erreichbar. Kommentar in Zeile 416 sagt das Gegenteil.
- **Fix:**
  1. Statische Registrierung aus `create_app()` entfernen
  2. In `lifespan()` nur Routen für `active=True` Plugins registrieren
  3. `Depends(require_active_plugin("name"))` als zentrale Prüfung ergänzen
  4. Bei Deaktivierung: Router entfernen oder 403-Dependency ergänzen
- **Aufwand:** 2-3 Std
- **Risiko:** Mittel — muss sicherstellen dass keine Route doppelt registriert wird

### B3. UploadFile Route-Registration Bug
- **Dateien:** `app/plugins/builtins/dms/routes.py`, `calendar/routes.py`, `mail/routes.py`, `kommunikation/routes.py`, `ai_assistant/routes.py`
- **Problem:** FastAPI kann `UploadFile` nicht als Response-Model auflösen → 5 Plugins failen beim Registrieren mit `Invalid args for response field`
- **Fix:** `response_model=None` zu allen Endpoints mit `UploadFile`-Rückgabe hinzufügen, oder Return-Type auf `Response`/`dict` ändern
- **Aufwand:** 30 Min
- **Risiko:** Keines — Routen sind aktuell gar nicht registriert

### B4. DMS-Upload auf echtes Streaming umstellen
- **Datei:** `app/plugins/builtins/dms/routes.py` Zeilen 444-472
- **Problem:** Chunks werden in `list[bytes]` gesammelt, dann `b"".join()` → 100MB Datei = 200MB+ RAM. `save_stream()` existiert aber wird nicht benutzt.
- **Fix:**
  ```python
  async def chunk_generator():
      while chunk := await file.read(CHUNK_SIZE):
          yield chunk
  await storage.save_stream(storage_path, chunk_generator())
  ```
  Hash und Größe während des Streams berechnen.
- **Aufwand:** 1 Std
- **Risiko:** Gering — save_stream() ist bereits implementiert

### B5. Outbox-Worker: Event-Handler registrieren
- **Datei:** `app/core/worker.py` `on_startup()`
- **Problem:** Worker liest Events aus Outbox, published an lokalen EventBus, aber es sind keine Handler registriert → Events werden als `published` markiert ohne Verarbeitung
- **Fix:**
  1. In `on_startup()`: Plugin-Event-Handler registrieren (wie in `lifespan()` der API)
  2. `webhook_dispatcher._dispatch_event` an EventBus subscriben
  3. Plugin-Participant-Handler registrieren
- **Aufwand:** 2 Std
- **Risiko:** Mittel — muss gleiche Handler wie API-Container registrieren

### B6. Passwort-Reset-Mailjob implementieren
- **Dateien:** `app/services/auth_service.py`, `app/core/jobs.py`, `app/core/job_registry.py`
- **Problem:** `send_password_reset_email` Job wird gequeued aber nie registriert → Mail wird nicht versendet. Token wird in Logs geschrieben (Zeile 240-241).
- **Fix:**
  1. `send_password_reset_email` Worker-Funktion implementieren (SMTP/IMAP)
  2. Mit `register_job()` registrieren
  3. `logger.warning("raw_token for development: %s", raw_token)` entfernen
  4. Token nur im Development-Mode loggen, nie in Production
- **Aufwand:** 2 Std
- **Risiko:** Gering

### B7. Webhook SSRF-Schutz + Secret-Behandlung
- **Dateien:** `app/services/webhook_service.py`, `app/schemas/webhook.py`
- **Problem:** Kein SSRF-Schutz — User können interne Dienste ansprechen (redis:6379, postgres:5432, 169.254.169.254). Webhook-Secret wird im Response zurückgegeben.
- **Fix:**
  1. SSRF-Prüfung: DNS auflösen, private IPs blocken (10.x, 172.16-31.x, 192.168.x, 127.x, 169.254.x, ::1)
  2. Redirects deaktivieren oder prüfen
  3. Protokoll-Allowlist (nur https)
  4. `secret` aus `WebhookResponse` entfernen
  5. Secret gehasht in DB speichern
- **Aufwand:** 3 Std
- **Risiko:** Gering

### B8. RLS: Separater DB-Runtime-User
- **Dateien:** `docker-compose.yml`, `alembic/versions/0044_db_roles.py` (neu)
- **Problem:** `POSTGRES_USER` (crm_user) ist Superuser → umgeht RLS auch mit FORCE. Spätere Tabellen (user_preferences, saved_filters, etc.) haben keine RLS-Policy.
- **Fix:**
  1. Neue Migration `0044_db_roles.py`: erstellt `crm_runtime` (NOSUPERUSER, NOBYPASSRLS)
  2. `crm_runtime` bekommt nur SELECT/INSERT/UPDATE/DELETE Rechte
  3. `docker-compose.yml`: API und Worker nutzen `crm_runtime`, Migrationen nutzen `crm_owner`
  4. Neue Migration `0045_rls_new_tables.py`: RLS für alle Tabellen mit `tenant_id` die nach 0028 hinzukamen
- **Aufwand:** 4 Std
- **Risiko:** Hoch — muss bestehende Datenbanken migrieren ohne Datenverlust

### B9. .env.docker.example korrigieren
- **Datei:** `.env.docker.example`
- **Problem:** Verwendet `AUTH_SECRET` statt `SECRET_KEY` (config.py erwartet `SECRET_KEY`)
- **Fix:** `AUTH_SECRET` → `SECRET_KEY` umbenennen
- **Aufwand:** 5 Min
- **Risiko:** Keines

### B10. Redis-Default-Passwort + exponierte Ports
- **Datei:** `docker-compose.yml`
- **Problem:** Redis-Passwort default `changeme`, PostgreSQL (5432) und Redis (6379) Ports exponiert
- **Fix:**
  1. Redis-Passwort als Required-Env ohne Default
  2. `ports:` Sektion für DB und Redis entfernen (nur internes Docker-Netzwerk)
  3. Falls Debug-Zugriff nötig: nur an 127.0.0.1 binden
- **Aufwand:** 15 Min
- **Risiko:** Gering — bestehende Setups müssen .env anpassen

---

## Phase 2: Hohe Priorität (kurz nach Release)

### H1. Unauthentifizierter Error-Endpoint absichern
- **Datei:** `app/routes/errors.py`
- **Problem:** `POST /api/v1/errors` ohne Auth, sendet Daten an Forgejo als öffentliches Issue. Context-Dict kann sensible Daten enthalten.
- **Fix:**
  1. Context-Felder filtern (keine Tokens, Passwörter, Headers)
  2. Forgejo-Issues nur in non-production erstellen
  3. Rate-Limit auf IP-Basis (bereits vorhanden, aber in-memory → bei Multi-Worker unzuverlässig)
  4. Optional: Auth erforderlich, aber dann funktioniert Frontend-Error-Logging nicht mehr → besser: nur sanitisierte Daten akzeptieren
- **Aufwand:** 1 Std

### H2. Rate-Limiter IP-Spoofing
- **Datei:** `app/core/rate_limit.py` Zeile 43
- **Problem:** Vertraut `X-Forwarded-For` blind → IP-Spoofing umgeht Rate-Limits
- **Fix:** Nur erste IP in X-Forwarded-For verwenden, oder `X-Real-IP` mit Proxy-Validation
- **Aufwand:** 30 Min

### H3. CSRF-Middleware Redis-Verbindung
- **Datei:** `app/core/middleware.py` Zeile 69
- **Problem:** Erstellt pro unsafe Request neue Redis-Verbindung → Connection Leak
- **Fix:** `get_redis()` Singleton verwenden (funktioniert nach B1)
- **Aufwand:** 10 Min

### H4. WebSocket Auth + Origin-Verifikation
- **Dateien:** `app/plugins/builtins/kommunikation/websocket_manager.py`, `ai_ui_control/websocket_manager.py`
- **Problem:** `user_id` wird ohne Auth-Verifikation akzeptiert. Keine Origin-Prüfung bei WS-Upgrade.
- **Fix:**
  1. Session-Token aus Query-Param oder Header validieren
  2. Origin-Header gegen erlaubte Domains prüfen
  3. User-ID aus Session ableiten, nicht aus Client-Param
- **Aufwand:** 2 Std

### H5. File-Upload-Sicherheit
- **Datei:** `app/core/storage.py`
- **Problem:** Keine Path-Traversal-Prüfung, keine Type/Size-Limits, `get_url()` leakt Filesystem-Pfade
- **Fix:**
  1. Filename sanitizen (keine `../`, keine absoluten Pfade)
  2. MIME-Type-Allowlist
  3. Max-File-Size konfigurierbar
  4. `get_url()` gibt relative URL zurück, nicht Filesystem-Pfad
- **Aufwand:** 1 Std

### H6. Security-Headers
- **Datei:** `app/core/middleware.py` (neu)
- **Problem:** Keine Security-Headers (HSTS, X-Content-Type-Options, X-Frame-Options, CSP)
- **Fix:** Middleware ergänzen die diese Headers setzt
- **Aufwand:** 30 Min

### H7. Migration-Repair für bestehende Installationen
- **Datei:** `alembic/versions/0044_repair_contact_migration.py` (neu)
- **Problem:** Migrationen 0021 und 0027 wurden nachträglich geändert. Alembic führt sie nicht erneut aus.
- **Fix:**
  1. Neue Migration die `*_old` Tabellen erkennt und Daten nachmigriert
  2. Integritätsprüfung (Anzahl vergleichen)
  3. Bei Abweichungen hart abbrechen mit Fehlermeldung
- **Aufwand:** 3 Std

---

## Phase 3: Mittlere Priorität

### M1. Passwort-Komplexität
- **Datei:** `app/schemas/auth.py`, `app/schemas/user.py`
- **Problem:** Min-Length 8 bei Erstellung, Min-Length 1 bei Login. Keine Komplexitäts-Requirements.
- **Fix:** Passwort-Validator ergänzen (min 8 Zeichen, 1 Groß, 1 Klein, 1 Zahl)
- **Aufwand:** 30 Min

### M2. Login-Response: is_system_admin
- **Datei:** `app/routes/auth.py` Zeile 78
- **Problem:** `is_system_admin` Flag in Login-Response leakt interne Rolle
- **Fix:** Flag aus Response entfernen oder nur für Admin-User anzeigen
- **Aufwand:** 15 Min

### M3. Permission-Cache: Stale Data bei DB-Error
- **Datei:** `app/core/permissions.py` Zeile 337
- **Problem:** Bei DB-Error fällt Cache auf stale Daten zurück → widerrufene Rechte bleiben aktiv
- **Fix:** Bei DB-Error: Cache invalidieren und 503 zurückgeben statt stale Daten zu nutzen
- **Aufwand:** 30 Min

### M4. ENVIRONMENT=development vs SESSION_COOKIE_SECURE=true
- **Datei:** `.env` Zeilen 3-4
- **Problem:** Inkonsistent — development deaktiviert Prod-Safety-Checks, aber Cookie ist secure
- **Fix:** In .env.docker.example klar dokumentieren: production → `ENVIRONMENT=production` + `SESSION_COOKIE_SECURE=true`
- **Aufwand:** 10 Min

### M5. Frontend: Unresolved Items — ✅ Implementiert (2026-07-27)
- **Dateien:** `WelcomeDialog.tsx`, `SavedFilterBar.tsx`, `EntityHistoryPanel.tsx`, `TagBadge.tsx`, `TagSelector.tsx`
- **Status:** ✅ Implementiert — SavedFilterBar und TagSelector in ContactsList, Mail, Calendar integriert
- **Implementiert:**
  1. SavedFilterBar in ContactsList (entityType="contacts"), Mail (entityType="mail"), Calendar (entityType="calendar") integriert
  2. TagSelector in ContactsList (entityType="contact"), Mail (entityType="file"), Calendar (entityType="calendar_entry") integriert
  3. Frontend TypeScript: 0 Errors (`npx tsc --noEmit`)
- **Hinweis:** WelcomeDialog und EntityHistoryPanel bleiben für spätere Iteration offen

### M6. Frontend-Tests: QueryClientProvider
- **Datei:** `frontend/src/test/setup.ts` oder einzelne Tests
- **Problem:** ~29 Tests failen mit missing QueryClientProvider
- **Fix:** Globalen Test-Wrapper mit QueryClientProvider in setup.ts ergänzen
- **Aufwand:** 1 Std

---

## Phase 4: Niedrige Priorität

### L1. document.write() in print.ts
- **Datei:** `frontend/src/utils/print.ts` Zeilen 54, 127
- **Problem:** `document.write()` mit DOM-Clone — XSS-Risiko wenn Content nicht sanitized
- **Fix:** Statt `document.write()`: `iframe.srcdoc` oder `Blob URL` verwenden
- **Aufwand:** 1 Std

### L2. AI UI Control: Unbounded Feedback-Storage
- **Datei:** `app/plugins/builtins/ai_ui_control/websocket_manager.py` Zeile 94
- **Problem:** Feedback/Commands unbegrenzt im Memory gespeichert → Memory Exhaustion
- **Fix:** Max-Length Queue (z.B. 100 Einträge) mit FIFO
- **Aufwand:** 15 Min

### L3. Backup-Strategie dokumentieren
- **Problem:** Named Volumes in docker-compose aber keine Backup/Restore-Doku
- **Fix:** Backup-Script und Doku ergänzen
- **Aufwand:** 2 Std

---

## Implementierungs-Reihenfolge

```
Phase 1 (Release-Blocker):
  B1  → B3 → B9 → B10 → B2 → B4 → B5 → B6 → B7 → B8
  ↑    ↑    ↑    ↑      ↑    ↑    ↑    ↑    ↑    ↑
  5m   30m  5m   15m    3h   1h   2h   2h   3h   4h
  Gesamt: ~16 Std

Phase 2 (Hohe Priorität):
  H3 → H2 → H6 → H1 → H5 → H4 → H7
  Gesamt: ~8 Std

Phase 3 (Mittlere Priorität):
  M4 → M1 → M2 → M3 → M6 → M5
  Gesamt: ~6 Std

Phase 4 (Niedrige Priorität):
  L2 → L1 → L3
  Gesamt: ~3 Std
```

**Gesamtaufwand: ~33 Std**

---

## Was bereits sauber funktioniert

- ✅ Auth-Bypass entfernt (keine X-Internal-Call/X-Tenant-Id/X-User-Id Headers mehr)
- ✅ Plugin-Upload/URL-Installation deaktiviert (403)
- ✅ Worker in separatem Container
- ✅ Metrics adminbeschränkt
- ✅ DOMPurify für HTML-Komponenten
- ✅ ARQ-Verbindungspool zentralisiert
- ✅ Session-Widerruf nach Passwortänderung
- ✅ Permission-Cache-Versionierung
- ✅ Redis SCAN statt KEYS
- ✅ Rabatte von Float auf Numeric
- ✅ Event-Outbox als Grundlage vorhanden
- ✅ RLS FORCE + WITH CHECK in Migration 0028
- ✅ Migration 0021: Tabellen umbenennen statt löschen
- ✅ Frontend: TypeScript typecheck clean (0 errors)
- ✅ Frontend: ErrorBoundary, OfflineBanner, ErrorLogger implementiert
- ✅ Frontend: Print/PDF mit WeasyPrint funktioniert
- ✅ Dockerfile: Multi-stage, non-root User, Healthcheck
- ✅ Bcrypt Password-Hashing
- ✅ Session-Tokens: secrets.token_urlsafe(32)