security.txt hinzufügen #

Diese Seite richtet sich an Administratorinnen und Administratoren sowie Hosting-Teams. security.txt ist eine kleine Textdatei unter /.well-known/security.txt, die Sicherheitsforschenden mitteilt, wie sie eine Schwachstelle melden können; definiert ist sie in RFC 9116 (https://www.rfc-editor.org/rfc/rfc9116). Exponential liefert keine mit; das Projekt führt dies als Lücke, die der Betreiber schließen kann (Sicherheitsstandards: Offenlegung von Schwachstellen).

Warnung .htaccess bremst jede Anfrage. Sind .htaccess-Dateien erlaubt (AllowOverride alles außer None), geschweige denn genutzt, sucht Apache sie bei jeder Anfrage in jedem Verzeichnis des Pfads und liest und wertet sie aus, und die Ladezeiten der Seiten steigen drastisch (gemessen). Die einzige wirkliche Abhilfe ist, die Funktion für den virtuellen Host abzuschalten: AllowOverride None im virtuellen HTTPS-Host, und die Regeln in der Konfiguration des virtuellen Hosts selbst als mod_rewrite-Regeln. Das ist in Geschwindigkeitstests im Produktivbetrieb weit schneller und die Zeit für die Optimierung einer Produktivkonfiguration unbedingt wert. Stellen Sie sofort um: Übernehmen Sie die Regeln des Beispiels für einen virtuellen HTTPS-Host in Ihren virtuellen Host (mit dem statischen Cache auch staticcache_offload.conf), setzen Sie AllowOverride None, führen Sie apachectl configtest aus, laden Sie Apache neu und testen Sie die Website. Dieselben Regeln für andere Server: nginx, LiteSpeed, Caddy, IIS, Velocity (eingebaut); wohin Regeln für virtuelle Hosts in einem Control Panel gehören: Plesk, cPanel, DirectAdmin, ISPConfig. Unter LiteSpeed oder OpenLiteSpeed kann zusätzlich der Seiten-Cache des Servers anonyme Besucher und Crawler ohne PHP bedienen: Seiten-Caching mit LiteSpeed und OpenLiteSpeed.

Hinweis Diese Seite beschreibt Funktionen und übliche Praxis; sie ist keine Rechtsberatung. Prüfen Sie das für Ihre Organisation geltende Recht mit Ihrer Rechtsberatung.

Inhalt #

1. Die Datei schreiben
2. Die Datei ablegen
3. Den Webserver die Datei ausliefern lassen
4. Prüfen
5. Aktuell halten
6. Verwandte Seiten

Die Datei schreiben #

Eine minimale Datei mit den beiden Feldern, die RFC 9116 verlangt (Contact und Expires), und üblichen optionalen Feldern:

Contact: mailto:[email protected]
Expires: 2027-10-31T23:00:00.000Z
Policy: https://www.example.gov/vulnerability-disclosure
Preferred-Languages: en
Canonical: https://www.example.gov/.well-known/security.txt

• Contact: ein Postfach, das Ihr Sicherheitsteam liest (oder ein HTTPS-Formular). Nicht die Adresse des Exponential-Projekts: Diese ist für Schwachstellen in Exponential selbst gedacht.
• Expires: weniger als ein Jahr in der Zukunft, wie es der RFC empfiehlt.
• Policy: die Seite mit Ihrer Offenlegungsrichtlinie (siehe „Offenlegung von Schwachstellen“).
• Der RFC beschreibt auch das Signieren der Datei mit OpenPGP; folgen Sie der Praxis Ihrer Organisation.

Die Datei ablegen #

Legen Sie im Document-Root das Verzeichnis .well-known und darin die Datei an, im Besitz des Benutzers der Website und für den Webserver lesbar:

mkdir -p .well-known
$EDITOR .well-known/security.txt
chmod 0644 .well-known/security.txt

Nehmen Sie die Datei in Ihre Bereitstellung (Versionsverwaltung) auf, damit sie das nächste Release übersteht.

Den Webserver die Datei ausliefern lassen #

Apache mit den mitgelieferten Regeln. .htaccess_root beantwortet jeden Punkt-Pfad außer .well-known mit 404, aber seine letzte Regel schickt jede andere Anfrage an index.php, sodass /.well-known/security.txt bei Exponential ankäme und eine Seite „nicht gefunden“ erhielte. Fügen Sie neben der vorhandenen Regel für robots.txt, vor dem abschließenden RewriteRule .* index.php, eine Zeile hinzu:

RewriteRule ^\.well-known/security\.txt$ - [L]

Übernehmen Sie sie in Ihre .htaccess (oder den virtuellen Host) und in Ihre eigene Kopie der Regeln; wiederholen Sie das nach Upgrades, die .htaccess_root ändern.

nginx: Die abgeleitete Konfiguration in der Installationsanleitung hält .well-known erreichbar; stellen Sie sicher, dass eine location die Datei ausliefert, bevor die Anfrage an index.php weitergereicht wird (Kapitel 8: Die Website ausliefern).

Velocity liefert Dateien im Document-Root selbst aus; prüfen Sie es mit dem curl unten.

Prüfen #

curl -sI https://www.example.gov/.well-known/security.txt | head -5
curl -s  https://www.example.gov/.well-known/security.txt

Erwartet: Status 200, Content-Type: text/plain und Ihre Datei. Ein 404 oder eine HTML-Seite bedeutet, dass die Anfrage bei index.php angekommen ist.

Aktuell halten #

Tragen Sie das Expires-Datum einen Monat im Voraus in Ihren Kalender ein, zusammen mit der Überprüfung der Offenlegungsrichtlinie. Eine Datei nach ihrem Ablaufdatum sollen Forschende laut RFC als veraltet betrachten.

Verwandte Seiten #

• Offenlegung von Schwachstellen
• Eine brauchbare robots.txt ab Werk (wird genauso ausgeliefert)
• Sicherheitsstandards
• Freie Dokumentation: Diese Seite darf unter der GNU FDL 1.3 frei kopiert, übersetzt und verbessert werden.