Changes between Version 1 and Version 2 of WebDiensteNginxSecurityHeader

Timestamp:

Oct 24, 2026, 12:35:13 PM (2 weeks ago)

Author:

Johannes Lode

Comment:

--

WebDiensteNginxSecurityHeader

@@ -227 +227 @@
 Der ICANN-Draft zu `.internal` empfiehlt selbst die Subdomain einer eigenen
 Domain als erste Wahl und die reservierte TLD erst danach.
+
+== Content-Security-Policy fuer den Shop ==
+
+Status: noch nicht aktiv. Die Konfiguration steht auskommentiert in
+`conf.d/shop-headers.inc`.
+
+=== Wer sammelt die Reports? ===
+
+Der Browser erzeugt sie, legt sie aber nirgends ab. Ohne Reporting-Direktive
+erscheinen Verstoesse ausschliesslich in der Entwicklerkonsole des Browsers --
+NGINX bekommt davon nichts mit, es gibt kein Log. Mit Reporting-Direktive
+schickt der Browser einen POST mit JSON-Body an eine URL, die wir angeben.
+Den Empfaenger muessen wir selbst stellen.
+
+Zwei Mechanismen:
+
+ * `report-uri` -- der alte, CSP-eigene Weg, inzwischen deprecated
+ * `report-to` plus den Header `Reporting-Endpoints` -- der moderne Weg ueber
+   die allgemeine Reporting-API
+
+Browser mit `report-to`-Unterstuetzung ignorieren `report-uri` vollstaendig.
+Lange war `report-uri` unverzichtbar, weil Firefox und Safari die
+Reporting-API nicht umgesetzt hatten; seit Maerz 2026 unterstuetzen alle
+aktuellen Browser `report-to` (Firefox seit Version 149). Wir verwenden
+daher nur noch `report-to`.
+
+=== Dreistufiges Vorgehen ===
+
+ 1. '''Entwicklerkonsole.''' Solange der Shop nicht oeffentlich ist, nichts
+    aktivieren. Shop selbst durchklicken -- Katalog, Warenkorb, Checkout,
+    Zahlungsmodule, Admin -- und die Verstoesse in der Konsole abarbeiten.
+    Die zeigt sie sofort und mit Zeilennummer, ein Report-Endpunkt liefert
+    gebuendelt und mit bis zu einer Minute Verzoegerung.
+ 2. '''Report-Only mit Endpunkt.''' Erst wenn der Shop oeffentlich ist und
+    Felddaten aus echten Browsern gebraucht werden. Blockiert nichts.
+ 3. '''Scharf schalten.''' `Content-Security-Policy-Report-Only` durch
+    `Content-Security-Policy` ersetzen, Endpunkt beibehalten.
+
+=== Endpunkt in NGINX ===
+
+In `nginx.conf`, http-Kontext:
+
+{{{#!nginx
+log_format csp escape=json
+    '{"time":"$time_iso8601","ua":"$http_user_agent",'
+    '"report":$request_body}';
+
+limit_req_zone $binary_remote_addr zone=csp:1m rate=10r/m;
+
+# Dummy-Backend, das den POST quittiert
+server {
+    listen 127.0.0.1:8099;
+    location / { return 204; }
+}
+}}}
+
+Im server-Block des Shops:
+
+{{{#!nginx
+location = /_csp-report {
+    access_log /var/log/nginx/csp-report.jsonl csp;
+
+    client_body_buffer_size 64k;
+    client_max_body_size    64k;
+    limit_req zone=csp burst=5 nodelay;
+
+    proxy_pass http://127.0.0.1:8099;
+}
+}}}
+
+Und im Shop-Header:
+
+{{{#!nginx
+add_header Reporting-Endpoints 'csp="https://shop.vpn21.net/_csp-report"' always;
+add_header Content-Security-Policy-Report-Only "default-src 'self'; report-to csp" always;
+}}}
+
+'''Fallstricke:'''
+
+ * Der Umweg ueber `proxy_pass` ist noetig. NGINX liest den Request-Body nur
+   ein, wenn es ihn weiterreicht; bei einem schlichten `return 204;` bleibt
+   `$request_body` leer.
+ * `$request_body` ist nur gefuellt, wenn der Body in den Speicher passt.
+   Groesserer Body wandert in eine temporaere Datei, die Variable bleibt
+   leer -- daher `client_body_buffer_size` passend setzen.
+ * Die Endpunkt-URL muss HTTPS sein. Ueber HTTP verwirft der Browser sie
+   kommentarlos.
+ * `escape=json` im `log_format` gibt es ab NGINX 1.11.8.
+
+=== Logrotation ===
+
+'''NGINX kann nicht selbst rotieren.''' Es gibt keine Groessen- oder
+Zeitbegrenzung in der Konfiguration; NGINX schreibt in ein offenes
+File-Handle, bis jemand von aussen eingreift. Der vorgesehene Weg ist:
+Datei umbenennen, dann `SIGUSR1` an den Master-Prozess, woraufhin NGINX die
+Logs neu oeffnet. Genau das macht logrotate.
+
+Begrenzen laesst sich in der NGINX-Konfiguration nur der Zufluss --
+`client_max_body_size` pro Eintrag, `limit_req` pro Client. Beides ist oben
+gesetzt.
+
+Der Dateiname lautet bewusst `csp-report.jsonl` und nicht `.log`: die
+mitgelieferte logrotate-Konfiguration der Distribution greift ueblicherweise
+auf `/var/log/nginx/*.log` zu. Zwei Stanzas fuer dieselbe Datei quittiert
+logrotate mit "duplicate log entry" und bricht ab. Die eigene Endung haelt
+die CSP-Logs aus dem Standard-Glob heraus und erlaubt eine eigene Retention.
+
+`/etc/logrotate.d/nginx-csp`:
+
+{{{
+/var/log/nginx/csp-report.jsonl {
+    size 10M
+    rotate 5
+    compress
+    delaycompress
+    missingok
+    notifempty
+    create 0640 www-data adm
+    sharedscripts
+    postrotate
+        [ -f /var/run/nginx.pid ] && kill -USR1 `cat /var/run/nginx.pid`
+    endscript
+}
+}}}
+
+Zur Wirkung von `size`: die Direktive schaltet die zeitbasierte Rotation ab
+und rotiert nur noch bei Ueberschreiten der Groesse -- aber geprueft wird
+das erst, wenn logrotate laeuft, ueblicherweise einmal taeglich per
+systemd-Timer. Eine harte Obergrenze ist das also nicht; bei einem Ausbruch
+kann die Datei zwischen zwei Laeufen deutlich groesser werden. Wer das enger
+braucht, laesst logrotate oefter laufen (eigener Timer oder Cron-Eintrag mit
+`logrotate /etc/logrotate.d/nginx-csp`).
+
+Alternative `maxsize` statt `size`: rotiert nach Zeitplan '''oder''' bei
+Ueberschreiten der Groesse, je nachdem was zuerst eintritt. Sinnvoll, wenn
+die Datei auch bei wenig Verkehr regelmaessig umgebrochen werden soll.
+
+Benutzer und Gruppe in `create` an die Distribution anpassen -- auf einigen
+Systemen `nginx:nginx` statt `www-data:adm`.
+
+=== Rauschfilter -- noch zu entwickeln ===
+
+Sobald der Endpunkt oeffentlich erreichbar ist, besteht ein erheblicher Teil
+der Reports aus Muell: Browser-Erweiterungen, die Skripte injizieren,
+Virenscanner mit TLS-Interception, von Providern eingeschleuste Inhalte.
+Die Trennung von relevanten und irrelevanten Reports ist eine eigene
+Aufgabe.
+
+Prompt zum Kopieren, wenn es soweit ist:
+
+{{{
+Ich betreibe einen modified-eCommerce-Shop unter shop.vpn21.net hinter
+NGINX (Version siehe unten). Der Shop laeuft seit einiger Zeit mit
+Content-Security-Policy-Report-Only und einem Report-Endpunkt
+/_csp-report, der die Reports per report-to einsammelt.
+
+NGINX loggt die Reports mit log_format csp escape=json als eine JSON-Zeile
+pro Report nach /var/log/nginx/csp-report.jsonl, Format:
+{"time":"...","ua":"...","report":<Reporting-API-Payload>}
+
+Ich haenge einen Auszug der Logdatei an.
+
+Ich moechte mit dir zusammen einen Filter entwickeln, der die relevanten
+Reports -- also echte Verstoesse meines eigenen Shop-Codes und seiner
+Module -- von Rauschen trennt. Als Rauschen erwarte ich vor allem:
+Browser-Erweiterungen, Virenscanner mit TLS-Interception, von Providern
+eingeschleuste Inhalte, Bots.
+
+Bitte gehe so vor:
+1. Analysiere den Auszug und zeige mir, welche Report-Klassen tatsaechlich
+   vorkommen und wie haeufig. Rate nicht, zaehle.
+2. Schlage Unterscheidungskriterien vor und begruende sie. Nenne mir bei
+   jedem Kriterium, welche echten Verstoesse es faelschlich ausfiltern
+   koennte.
+3. Erst danach: ein Auswertungsskript. Sprache nach deinem Vorschlag,
+   begruende die Wahl. Es soll die Logdatei einlesen, Rauschen abtrennen
+   und die verbleibenden Verstoesse nach Haeufigkeit gruppiert ausgeben.
+4. Sag mir, welche CSP-Direktiven ich aus den verbleibenden Verstoessen
+   ableiten muesste, damit ich von Report-Only auf scharf umstellen kann.
+
+Frag nach, wenn etwas unklar ist, statt auf Annahmen aufzubauen.
+Code-Policy fuer C++ gilt hier vermutlich nicht, aber falls doch Code in
+C++ entsteht, halte dich daran.
+}}}
+
+Mitzubringen, wenn wir das angehen: ein Auszug aus `csp-report.jsonl` von
+einigen Tagen bis Wochen, moeglichst ungefiltert, und die dann aktive
+Report-Only-Policy.