Das Passwort war nie in der Datenbank zu sehen. Trotzdem findet es sich klar lesbar in der Protokolldatei wieder.
Wie eine Login-Anfrage durch den Server läuft und so in die Logzeile gelangt. Das Request-Log ist die Zeile, die der Server für jede eingehende Anfrage schreibt. Wer dort ungefiltert Methode, URL und Body protokolliert, schreibt auch die Zugangsdaten mit, die Nutzer gerade senden.
Zuerst trifft die Anfrage auf die Systemgrenze. Das ist die Stelle, an der Daten von außen ins Programm gelangen, etwa der Body einer HTTP-Anfrage oder ein Query-Parameter in der URL. Ab dort gilt jeder Wert als fremd, auch das Passwort im Body eines Login-Requests. Deren Felder gibt ein Logger gerne aus: Body, Authorization-Header, Session-Cookies.
Dann verarbeitet die Anwendung die Werte. Passwörter werden nach anerkannter Regel nur mit langsamen, gesalzenen Verfahren wie Argon2id gespeichert, nie im Klartext. Doch diese Vorsorge schützt nur die Datenbank. Liest der Code das Klartext-Passwort aus dem Body und schreibt den Body mit, entsteht das Leck eine Zeile weiter oben.
Danach filtert die Ausgabe, bevor die Logzeile entsteht. Bewährt hat sich eine Allowlist statt einer Blocklist: Der Logger benennt die wenigen erlaubten Felder, etwa Nutzer-ID, Statuscode und Pfad. Alles Unbekannte, auch Passwörter und API-Schlüssel, fällt dadurch automatisch weg.
Zuletzt landet die fertige Zeile in zentralen Sammelstellen, Backups und Auswertungen. Dort haben viel mehr Personen Zugriff als auf die Anwendung selbst. Ein einmal protokolliertes Passwort lässt sich kaum aus allen Kopien entfernen.
Das Logging umgeht jede sorgfältige Passwort-Speicherung, wenn es den ungefilterten Body mitschreibt. Deshalb wird gefiltert, bevor die Zeile entsteht, nicht danach.
📌 Allowlist · Redaction · Systemgrenze
📚 Webentwicklung von Grund auf · Tag 22 von 30
#WebSecurity #backend #NodeJS #webdev
Wie eine Login-Anfrage durch den Server läuft und so in die Logzeile gelangt. Das Request-Log ist die Zeile, die der Server für jede eingehende Anfrage schreibt. Wer dort ungefiltert Methode, URL und Body protokolliert, schreibt auch die Zugangsdaten mit, die Nutzer gerade senden.
Zuerst trifft die Anfrage auf die Systemgrenze. Das ist die Stelle, an der Daten von außen ins Programm gelangen, etwa der Body einer HTTP-Anfrage oder ein Query-Parameter in der URL. Ab dort gilt jeder Wert als fremd, auch das Passwort im Body eines Login-Requests. Deren Felder gibt ein Logger gerne aus: Body, Authorization-Header, Session-Cookies.
Dann verarbeitet die Anwendung die Werte. Passwörter werden nach anerkannter Regel nur mit langsamen, gesalzenen Verfahren wie Argon2id gespeichert, nie im Klartext. Doch diese Vorsorge schützt nur die Datenbank. Liest der Code das Klartext-Passwort aus dem Body und schreibt den Body mit, entsteht das Leck eine Zeile weiter oben.
Danach filtert die Ausgabe, bevor die Logzeile entsteht. Bewährt hat sich eine Allowlist statt einer Blocklist: Der Logger benennt die wenigen erlaubten Felder, etwa Nutzer-ID, Statuscode und Pfad. Alles Unbekannte, auch Passwörter und API-Schlüssel, fällt dadurch automatisch weg.
Zuletzt landet die fertige Zeile in zentralen Sammelstellen, Backups und Auswertungen. Dort haben viel mehr Personen Zugriff als auf die Anwendung selbst. Ein einmal protokolliertes Passwort lässt sich kaum aus allen Kopien entfernen.
Das Logging umgeht jede sorgfältige Passwort-Speicherung, wenn es den ungefilterten Body mitschreibt. Deshalb wird gefiltert, bevor die Zeile entsteht, nicht danach.
📌 Allowlist · Redaction · Systemgrenze
📚 Webentwicklung von Grund auf · Tag 22 von 30
#WebSecurity #backend #NodeJS #webdev
7 Std vor
