[P0] Registrierungs- und Reset-Tokens aus URL- und Zugriffslogs entfernen #8

Open
opened 2026-09-15 09:43:24 +00:00 by metalcircle-bot · 0 comments

Ziel

Einladungs-, Verifikations- und Passwort-Reset-Tokens dürfen nicht durch URL-Pfade in HTTP-Zugriffslogs oder andere leicht zugängliche Verlaufsspeicher gelangen.

Hintergrund

Solche Tokens gewähren vorübergehend Kontozugriff. Der aktuelle Code nimmt Einladungen unter /register/{token} und Passwort-Reset unter /password-reset/{token} entgegen. Der Container startet Uvicorn mit standardmäßigen Access-Logs; diese protokollieren üblicherweise den angefragten Pfad. Einladungstokens haben in der Erstellung derzeit keine gesetzte Ablaufzeit, obwohl das Schema ein Ablaufdatum vorsieht.

Ist-Zustand

Reset-Tokens sind gehasht gespeichert, einmalig und auf zwei Stunden befristet. Der Klartext wird für die Linknutzung in den URL-Pfad aufgenommen. Registrierungs-Invites werden ebenfalls gehasht gespeichert, aber der Erzeugungspfad setzt keine Ablaufzeit.

Anforderungen

  • Tokenübermittlung so gestalten, dass Klartext-Tokens nicht in Access-Logs, Referrer oder unnötigen Browser-Verläufen erscheinen; geeignete Variante (z.B. Query-String mit gezielter Redaktion, POST-Übergabe nach Landing-Page oder gezielte Access-Log-Redaktion) dokumentieren.
  • Für alle ausstellbaren Konto-Tokens kurze, definierte Ablaufzeiten, Einmalnutzung und sichere Speicherung erzwingen.
  • Tokenwerte, Session-Cookies und vollständige URLs mit Token weder in App-Logs noch in Fehlerantworten ausgeben.
  • Token-Seiten mit restriktiver Referrer-Policy und no-store ausliefern.

Akzeptanzkriterien

  • Automatisierter Test belegt, dass Invite-, Verifikations- und Reset-Tokens im Klartext nicht in Backend-Access-Logs erscheinen.
  • Tokens sind gehasht gespeichert, einmalig und zeitlich befristet.
  • Abgelaufene oder verbrauchte Tokens werden abgewiesen.
  • Token-Seiten setzen geeignete Cache-/Referrer-Header.
  • Fehlerpfade geben keine Tokenwerte aus.

Test / Verifikation

Testzugriff mit synthetischen Tokens ausführen und App-/Uvicorn-Logs sowie Response-Header prüfen; zusätzlich Mehrfachnutzung und Ablauf testen.

Abhängigkeiten

Betrifft bestehende Invite-/Reset-Links sowie die E-Mail-Verifikation aus dem Registrierungs-Issue.

## Ziel Einladungs-, Verifikations- und Passwort-Reset-Tokens dürfen nicht durch URL-Pfade in HTTP-Zugriffslogs oder andere leicht zugängliche Verlaufsspeicher gelangen. ## Hintergrund Solche Tokens gewähren vorübergehend Kontozugriff. Der aktuelle Code nimmt Einladungen unter `/register/{token}` und Passwort-Reset unter `/password-reset/{token}` entgegen. Der Container startet Uvicorn mit standardmäßigen Access-Logs; diese protokollieren üblicherweise den angefragten Pfad. Einladungstokens haben in der Erstellung derzeit keine gesetzte Ablaufzeit, obwohl das Schema ein Ablaufdatum vorsieht. ## Ist-Zustand Reset-Tokens sind gehasht gespeichert, einmalig und auf zwei Stunden befristet. Der Klartext wird für die Linknutzung in den URL-Pfad aufgenommen. Registrierungs-Invites werden ebenfalls gehasht gespeichert, aber der Erzeugungspfad setzt keine Ablaufzeit. ## Anforderungen - Tokenübermittlung so gestalten, dass Klartext-Tokens nicht in Access-Logs, Referrer oder unnötigen Browser-Verläufen erscheinen; geeignete Variante (z.B. Query-String mit gezielter Redaktion, POST-Übergabe nach Landing-Page oder gezielte Access-Log-Redaktion) dokumentieren. - Für alle ausstellbaren Konto-Tokens kurze, definierte Ablaufzeiten, Einmalnutzung und sichere Speicherung erzwingen. - Tokenwerte, Session-Cookies und vollständige URLs mit Token weder in App-Logs noch in Fehlerantworten ausgeben. - Token-Seiten mit restriktiver Referrer-Policy und `no-store` ausliefern. ## Akzeptanzkriterien - [ ] Automatisierter Test belegt, dass Invite-, Verifikations- und Reset-Tokens im Klartext nicht in Backend-Access-Logs erscheinen. - [ ] Tokens sind gehasht gespeichert, einmalig und zeitlich befristet. - [ ] Abgelaufene oder verbrauchte Tokens werden abgewiesen. - [ ] Token-Seiten setzen geeignete Cache-/Referrer-Header. - [ ] Fehlerpfade geben keine Tokenwerte aus. ## Test / Verifikation Testzugriff mit synthetischen Tokens ausführen und App-/Uvicorn-Logs sowie Response-Header prüfen; zusätzlich Mehrfachnutzung und Ablauf testen. ## Abhängigkeiten Betrifft bestehende Invite-/Reset-Links sowie die E-Mail-Verifikation aus dem Registrierungs-Issue.
kai added this to the MetalCircle 0.1 Beta milestone 2026-09-15 09:52:17 +00:00
Sign in to join this conversation.