PassOnce 1.0.1

Sicherheitshärtung und Betreiberhinweise aus einem manuellen Secret-Logging-Audit gegen 1.0.0.

CodeQL meldet 0 Alerts — ein statischer Scanner erkennt aber nicht, dass eine protokollierte URL bei genau diesem Produkt das Sicherheitsversprechen bricht. Deshalb der manuelle Durchgang.

Härtung (Verhaltensänderung)

Der Dienst verweigert jetzt den Start, wenn ALLOW_SERVER_ENCRYPT=true gesetzt ist und BASE_URL fehlt.

Vorher wurde die Herkunft der zurückgegebenen Links aus dem Host-Header der Anfrage gebaut — also vom Aufrufer bestimmt. Sichtbares Scheitern ist hier besser als stillschweigend falsche Links. ./setup.sh --server-encrypt trägt den Wert ohnehin ein; Einrichtungen über setup.sh sind nicht betroffen.

Dokumentation

• Warnblock zum Server-Encrypt-Modus. Dort erzeugt der Server den Schlüssel und gibt ihn als Teil der URL im Antwort-Body zurück. Genau da verliert ein Betreiber sein Zero-Knowledge, ohne es zu merken — nicht durch einen Angriff, sondern durch gewöhnliche Betriebspraxis: Body-Logging am Reverse-Proxy, APM- und Tracing-Agenten, Terminal-Scrollback, CI-Logs, eine Zeile log.error(body) im aufrufenden Programm.
• Umgang mit dem API_TOKEN. setup.sh gibt es einmal aufs Terminal aus (Scrollback, tee/script/CI); im Docker-Betrieb ist es über docker inspect und /proc/1/environ lesbar. env_file mit Rechten 600 oder Docker Secrets als engere Alternative.
• BASE_URL in ENV-Tabelle und .env.example als Pflicht gekennzeichnet.

Nicht betroffen

Der Zero-Knowledge-Weg über die Weboberfläche. Dort entsteht der Schlüssel im Browser, steht ausschließlich im URL-Fragment und erreicht den Server nie. Das Audit hat das gegen den veröffentlichten Stand bestätigt: kein localStorage, kein Beacon, kein location.href, das Fragment wird nach dem Abruf per replaceState aus der Adresszeile entfernt, serverseitig referrer-policy: no-referrer und keine Zugriffslogs.

Lizenz: Apache 2.0