security.txt: ein maschinenlesbarer Kanal zur Meldung von Schwachstellen

Worum es geht

RFC 9116 legt eine Textdatei fest, die Sicherheitsforschenden sagt, wie Schwachstellen zu melden sind. Für Webdienste muss sie unter /.well-known/security.txt liegen, über HTTPS abgerufen und als text/plain in UTF-8 ausgeliefert werden; eine veraltete Kopie auf oberster Ebene darf dorthin weiterleiten. Das Format besteht aus Zeilen der Form Field: value mit #-Kommentaren. Contact (eine oder mehrere mailto:, tel: oder https:// URIs, in Reihenfolge der Präferenz aufgeführt) und Expires (genau ein RFC-3339-Zeitstempel, empfohlen weniger als ein Jahr in der Zukunft) sind Pflicht. Optionale Felder: Encryption (wo ein OpenPGP-Schlüssel abzurufen ist), Canonical (die URIs, unter denen die Datei rechtmässig liegt), Policy (die Offenlegungsrichtlinie), Acknowledgments, Preferred-Languages und Hiring. Die RFC empfiehlt eine OpenPGP-Klartextsignatur über die Datei, zusammen mit Canonical, damit Lesende prüfen können, dass sie nicht untergeschoben wurde. Die Datei gilt nur für den Host, von dem sie abgerufen wurde, nicht für Subdomains oder übergeordnete Domains.

Warum es wichtig ist

Das OWASP-Cheat-Sheet zur Offenlegung von Schwachstellen fordert Organisationen auf, Kontaktangaben zu veröffentlichen, damit Meldungen einfach sind, Meldungen zu bestätigen und eine Frist für die Triage zu nennen, und führt eine security.txt-Datei am Well-Known-Pfad als eine der Möglichkeiten auf, diese Angaben zu veröffentlichen. Meldungen, die in einem Kontaktformular oder einem Marketing-Postfach landen, verzögern sich oder gehen verloren; eine veraltete Datei (abgelaufen, totes Postfach) ist schlimmer als keine, weil sie signalisiert, dass niemand zuständig ist. Für Scanner und Agenten ist der Well-Known-Pfad ein deterministischer Ort zum Nachsehen.

So wird es angewendet

• Zuerst das Postfach oder Formular einrichten und die Person benennen, die es liest; erst dann die Datei schreiben.
• Expires auf etwa ein Jahr im Voraus setzen und eine Erinnerung zur Erneuerung einrichten; Contact aktualisieren, wenn Personen wechseln.
• Eine Policy-Seite verlinken, die Umfang, akzeptable Testmethoden, erwartete Reaktionszeiten und Angaben zu Anerkennung oder Belohnungen nennt; wenig versprechen und es einhalten.
• Einen Encryption-Schlüssel nur veröffentlichen, wenn ihn jemand tatsächlich zum Entschlüsseln verwenden kann; ein Schlüssel, den niemand nutzt, ist eine Falle für Meldende.
• Die Datei von einem Pfad ausliefern, den Nutzer nicht beschreiben können, und sie signieren, wenn eine Schlüsselinfrastruktur vorhanden ist.
• Nach jedem Deployment curl -i https://example.org/.well-known/security.txt ausführen und Status sowie Content-Type prüfen.

Stolpersteine

Sie als text/html oder hinter einem Login auszuliefern. Ein Beispiel mit dessen Beispieldaten oder -adressen zu kopieren. Zu vergessen, dass die Datei pro Host gilt, sodass api.example.org eine eigene braucht oder eine Weiterleitung. Von Meldenden zu erwarten, eine Richtlinie zu befolgen, die nie veröffentlicht wurde.