leocrm

Leopoldadmin/leocrm

Fork 0

Commit Graph

Author	SHA1	Message	Date
Agent Zero	47432651f1	fix(security): F03 (Astra P1) — Sitzungswiderruf in beiden Session-Stores durchsetzen Vorher (Astra-Finding): Widerruf war inkonsistent ueber vier Pfade: - Deaktivierung invalidierte nur den Berechtigungscache — Sessions liefen bis TTL (8h) weiter - Loeschung invalidierte GAR NICHTS - Passwortwechsel loeschte nur Redis-Sessions — PostgreSQL-Fallback- Sessions ueberlebten jeden Redis-Ausfall - Fehlende UserTenant-Mitgliedschaft wurde durchgewinkt statt abgewiesen Fix: - Neuer zentraler Helfer revoke_user_sessions_all_stores (app/core/auth.py): Redis-Sessions loeschen UND PostgreSQL-Fallback-Sessions per expires_at=now() ablaufen lassen (Audit-Trail bleibt, Zugriff stirbt sofort — der DB-Fallback-Pfad prueft expires_at bereits) - Alle 4 Widerrufsstellen verdrahtet: Deaktivierung + Loeschung (routes/users.py), Passwortwechsel (user_service.py), Passwort-Reset (auth_service.py) - Membership-Check in get_current_user fail-closed: None (fehlende Mitgliedschaft) wird abgewiesen statt durchgelassen Abnahme (Astra): Deaktivierung, Austritt und Passwortwechsel wirken unmittelbar — auch bei Redis-Ausfall (Unit-Test beweist die DB-Fallback-Abgelaufen-Rejection). Tests: test_s1_security_guards.py 10/10 (3 neue F03-Tests) + test_auth.py 11/11 + ruff clean.	2026-09-18 07:59:31 +02:00
Agent Zero	b8a556091e	fix(security): F10 (Astra P1) — Token-Scopes sind Obergrenze, kein Ersatz fuer User-Rechte Vorher: require_permission machte bei passendem Token-Scope ein early-return — die User-Rechte wurden NIE geprueft. Ein Token mit mail:write erlaubte mail:write selbst dann, wenn der Benutzer die Berechtigung nie hatte oder sie entzogen bekam (Astra-Repro isoliert bestaetigt). Fix: Nach bestandenem Scope-Check in den normalen User-Rechte-Check fallen. Effektives Recht = User-Rechte UND Token-Scope. Rechteentzug wirkt sofort auf bestehende Tokens. System-Admin-Bypass unveraendert. Tests: tests/test_s1_security_guards.py 7/7 (neue Suite): Scope-ohne-User-Recht 403, beide-present pass, Scope-fehlt-User-hat 403 insufficient_scope, Deny-Revocation wirkt, Session-Pfad unveraendert, :-Scope umgeht nicht, Admin-Bypass bleibt. ruff clean.	2026-09-18 07:52:23 +02:00

Author

SHA1

Message

Date

Agent Zero

47432651f1

fix(security): F03 (Astra P1) — Sitzungswiderruf in beiden Session-Stores durchsetzen

Vorher (Astra-Finding): Widerruf war inkonsistent ueber vier Pfade:
- Deaktivierung invalidierte nur den Berechtigungscache — Sessions
  liefen bis TTL (8h) weiter
- Loeschung invalidierte GAR NICHTS
- Passwortwechsel loeschte nur Redis-Sessions — PostgreSQL-Fallback-
  Sessions ueberlebten jeden Redis-Ausfall
- Fehlende UserTenant-Mitgliedschaft wurde durchgewinkt statt
  abgewiesen

Fix:
- Neuer zentraler Helfer revoke_user_sessions_all_stores (app/core/auth.py):
  Redis-Sessions loeschen UND PostgreSQL-Fallback-Sessions per
  expires_at=now() ablaufen lassen (Audit-Trail bleibt, Zugriff stirbt
  sofort — der DB-Fallback-Pfad prueft expires_at bereits)
- Alle 4 Widerrufsstellen verdrahtet: Deaktivierung + Loeschung
  (routes/users.py), Passwortwechsel (user_service.py), Passwort-Reset
  (auth_service.py)
- Membership-Check in get_current_user fail-closed: None (fehlende
  Mitgliedschaft) wird abgewiesen statt durchgelassen

Abnahme (Astra): Deaktivierung, Austritt und Passwortwechsel wirken
unmittelbar — auch bei Redis-Ausfall (Unit-Test beweist die
DB-Fallback-Abgelaufen-Rejection).

Tests: test_s1_security_guards.py 10/10 (3 neue F03-Tests) +
test_auth.py 11/11 + ruff clean.

2026-09-18 07:59:31 +02:00

Agent Zero

b8a556091e

fix(security): F10 (Astra P1) — Token-Scopes sind Obergrenze, kein Ersatz fuer User-Rechte

Vorher: require_permission machte bei passendem Token-Scope ein
early-return — die User-Rechte wurden NIE geprueft. Ein Token mit
mail:write erlaubte mail:write selbst dann, wenn der Benutzer die
Berechtigung nie hatte oder sie entzogen bekam (Astra-Repro isoliert
bestaetigt).

Fix: Nach bestandenem Scope-Check in den normalen User-Rechte-Check
fallen. Effektives Recht = User-Rechte UND Token-Scope. Rechteentzug
wirkt sofort auf bestehende Tokens. System-Admin-Bypass unveraendert.

Tests: tests/test_s1_security_guards.py 7/7 (neue Suite):
Scope-ohne-User-Recht 403, beide-present pass, Scope-fehlt-User-hat 403
insufficient_scope, Deny-Revocation wirkt, Session-Pfad unveraendert,
*:*-Scope umgeht nicht, Admin-Bypass bleibt. ruff clean.

2026-09-18 07:52:23 +02:00

2 Commits