ci(quick-261009-p0m): ZAP-Grundpruefung gegen alpha vor Freigaben, erster Lauf

- zap-baseline.sh: passive Aussenpruefung mit festgelegtem ZAP-Abbild, Ziel per ZAP_TARGET (Standard: oeffentliche Adresse von alpha), Anmeldedatei-Weg nur fuer den Ausnahmefall
- zap-hooks.py: Spinne fuellt keine Formulare aus und sendet keine (POST=0 lokal bewiesen)
- Sicherheitsprotokoll: Abschnitt Pruefung von aussen, erster Lauf direkt gegen die Anwendung (0 hoch, 2 mittel, 6 niedrig, 3 Info), Einordnung und Verlauf
- Betriebsanleitung Kapitel 9: Schritt Pruefung von aussen; Entwicklungsanleitung: Abschnitt ZAP; CHANGELOG

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

docs/sicherheitsprotokoll.md

@@ -14,6 +14,7 @@ Das Protokoll enthält bewusst keine Passwörter, keine Zugangsdaten und keine A
 - **Fremde Bausteine:** In den Bausteinen anderer Hersteller, die Tessera im Betrieb verwendet, sind 151 bekannte Schwachstellen verzeichnet, davon 5 kritische und 73 hohe. Für die allermeisten gibt es eine bereinigte Fassung innerhalb der aktuell verwendeten Versionslinie. Für zwei Bausteine (xlsx und node-forge) gibt es noch keine bereinigte Fassung; sie sind unter „Einordnung der Befunde“ eingeordnet.
 - **Eigener Quelltext:** Ein einziger echter Härtungspunkt wurde gefunden (die Längenprüfung bei der Entschlüsselung gespeicherter Geheimnisse, Schweregrad niedrig). Alles andere sind Fehlalarme oder bewusste, dokumentierte Entscheidungen.
 - **Automatische Prüfung:** Seit dem 9. Oktober 2026 läuft nach jedem Bau der Plattform automatisch eine Sicherheitsprüfung. Sie meldet nur und hält den Bau nie an.
+- **Prüfung von außen:** Vor jeder Freigabe wird der Testserver alpha wie ein Besucher ohne Konto angesehen, rein passiv und ohne Angriffe. Der erste Lauf am 9. Oktober 2026 (direkt gegen die Anwendung, ohne den vorgeschalteten Proxy) fand nichts Hohes, 2 mittlere und 6 niedrige Hinweise sowie 3 reine Informationen; alle betreffen fehlende Schutz-Kopfzeilen der Weboberfläche. Der Lauf über die öffentliche Adresse steht noch aus.
 - **Bisherige Prüfungen:** Acht Code-Prüfungen größerer Änderungen mit zusammen 89 Befunden; 76 davon sind behoben, die übrigen 13 sind Hinweise der niedrigsten Stufe. Alle kritischen Befunde und alle Warnungen sind behoben.
 - **Was noch zu tun ist:** Die Bausteine mit bereinigter Fassung werden aktualisiert, und die fertigen Abbilder sollen keine Entwicklungswerkzeuge mehr enthalten. Der Stand jedes einzelnen Punkts steht in der Tabelle „Einordnung der Befunde“.
 
@@ -70,6 +71,12 @@ Semgrep liest den von uns geschriebenen Quelltext und sucht nach Mustern, die er
 
 Zum Schluss prüft Trivy die beiden fertig gebauten Abbilder, `api` und `web`, so wie sie auf einem Server laufen würden. Dabei zählt es auch die Pakete des Betriebssystems im Abbild und alles, was im Abbild zusätzlich steckt, etwa Entwicklungswerkzeuge. Deshalb liegen die Zahlen hier über denen der Paketlisten.
 
+### Prüfung von außen vor einer Freigabe (OWASP ZAP)
+
+Vor jeder Freigabe sieht sich Claude den Testserver alpha von außen an, so wie ein Besucher ohne Konto: Startseite, Anmeldeseite, die mitgelieferten Kopfzeilen, Cookies und die ausgelieferten Dateien. Dafür wird das frei verfügbare Werkzeug OWASP ZAP in einem Container gestartet. Es arbeitet **nur passiv**: Es ruft Seiten ab und wertet aus, was der Server zurückschickt. Es füllt keine Formulare aus, sendet keine Daten an die Anwendung und probiert keine Angriffe aus. Ein Probelauf gegen eine eigens dafür gebaute Testseite mit Anmeldeformular hat bewiesen, dass dabei kein einziges Absenden (POST) stattfindet.
+
+Der Zugangsschutz (Basic Auth) vor alpha bleibt, wie er ist. Die Prüfung läuft vom internen Entwicklungsrechner aus, für den der Zugangsschutz keine Anmeldung verlangt. Falls alpha diesen Rechner einmal doch nach einer Anmeldung fragt, kann das Skript die Zugangsdaten aus einer Datei außerhalb des Projekts lesen. Das Ergebnis jedes Laufs wird in diesem Protokoll festgehalten (Abschnitt „Prüfung von außen gegen alpha“ und „Verlauf“). Den Ablauf beschreibt der Schritt „Eine Version freigeben“ in der [Betriebsanleitung](anleitung-betrieb.md#9-zwei-kanäle-live-und-beta); die technischen Einzelheiten stehen in der [Entwicklungsanleitung](anleitung-entwicklung.md#sicherheitsprüfungen).
+
 ### Prüfung durch Menschen und Künstliche Intelligenz
 
 Neben den Werkzeugen gibt es Prüfungen, die durch Lesen und Nachdenken entstehen:
@@ -164,6 +171,7 @@ Die Tabelle zeigt für jedes Werkzeug zwei Zahlen. „Rohwert“ ist der erste L
 | Eigener Quelltext (Semgrep) | 58 Treffer (9 Fehler, 46 Warnungen, 3 mittlere); 59 Scanfehler | 34 Treffer (2 Fehler, 29 Warnungen, 3 mittlere); 4 Scanfehler | Die Treffer sind unter „Einordnung der Befunde“ beurteilt: ein echter Härtungspunkt, sonst Fehlalarme und Entscheidungen. Die Ausnahmeliste nahm Testschlüssel, Tests und Notizen heraus |
 | Abbild `api` (Trivy) | Bausteine: 6 kritisch, 116 hoch, 98 mittel, 7 niedrig; Betriebssystem 1 mittel | 6 kritisch, 116 hoch, 99 mittel, 7 niedrig | Das Server-Abbild enthält Entwicklungswerkzeuge und einen Paketverwalter, die im Betrieb nichts tun, aber mitgezählt werden |
 | Abbild `web` (Trivy) | Bausteine: 2 kritisch, 19 hoch, 21 mittel, 1 niedrig; Betriebssystem 1 mittel | 2 kritisch, 19 hoch, 22 mittel, 1 niedrig | Die kritischen Funde sind dieselben des Webframeworks wie oben; dazu kommen Pakete des mitgelieferten Paketverwalters npm |
+| Prüfung von außen (ZAP, direkt gegen die Anwendung auf alpha) | 0 hoch, 2 mittel, 6 niedrig, 3 Informationen | keine Ausnahmelisten | Nur fehlende Schutz-Kopfzeilen der Weboberfläche und Hinweise zum Zwischenspeichern; Einzelheiten im Abschnitt „Prüfung von außen gegen alpha“ |
 
 **Gegenprobe:** Um zu beweisen, dass die Ausnahmelisten nichts Echtes verdecken, wurde in einer Wegwerfkopie des Projekts ein erfundener Zugangscode (ein „Köder“) abgelegt. gitleaks und Trivy haben ihn gefunden. Die Kopie und der Köder wurden danach gelöscht.
 
@@ -199,11 +207,42 @@ Die Tabelle beurteilt jeden Befund der ersten vollständigen Prüfung. Sie wird
 | Einstellungen zum Absichern der Paketverwaltung (drei Werte) | Arbeitsbereich-Datei | Niedrig | offen | Diese Einstellungen stärken die Lieferkette. Ob sie in der eingesetzten Fassung 9.15 des Paketverwalters wirken, ist noch nicht geprüft |
 | Fehlende Gesundheitsprüfung im Bauplan des Server-Abbilds | Abbild `api` | Niedrig | bewusst akzeptiert | Die Gesundheitsprüfung liegt in der Compose-Datei, die den Server startet und seine Erreichbarkeit überwacht |
 | Fehlende Gesundheitsprüfung im Bauplan des Web-Abbilds | Abbild `web` | Niedrig | offen | Weder Bauplan noch Compose-Datei prüfen die Weboberfläche; ein hängender Web-Container würde nicht automatisch erkannt |
+| Fehlende Inhaltsrichtlinie und fehlender Schutz gegen Einrahmen (Außenprüfung 9. Oktober 2026) | Weboberfläche, alle Seiten | Mittel | offen | Die Anwendung selbst schickt diese Kopfzeilen bisher nicht mit. Ein vorgeschalteter Proxy kann sie ergänzen; ob er das tut, kann nur der Lauf über die öffentliche Adresse zeigen. Aufgabe des Proxys, beim öffentlichen Lauf erneut prüfen. Fehlen sie dort auch, werden sie in der Anwendung gesetzt. Das tatsächliche Risiko ist gering bis mittel: Es braucht eine fremde Seite, die Benutzer zu Klicks verleitet, oder bereits eingeschleusten Code |
+| Weitere fehlende Schutz-Kopfzeilen (Dateityp-Umdeutung, Berechtigungsrichtlinie, drei Cross-Origin-Richtlinien) | Weboberfläche | Niedrig | offen | Reine Vorsorge ohne unmittelbare Gefahr. Teilweise Aufgabe des Proxys (beim öffentlichen Lauf erneut prüfen), sonst kommen sie in die Konfiguration der Weboberfläche |
+| Kopfzeile „X-Powered-By“ nennt das Webframework | Weboberfläche | Niedrig | offen | Das Webframework schickt diese Angabe standardmäßig mit. Sie verrät nur den Namen des Frameworks, den Angreifer ohnehin leicht erraten. Wird bei der Härtung der Kopfzeilen mit abgeschaltet |
+| Verschlüsselte Verbindung (HTTPS) und deren Absicherung der öffentlichen Adresse | Proxy vor alpha | nicht beurteilt | offen | Der erste Lauf ging über eine unverschlüsselte, interne Verbindung direkt zur Anwendung und konnte das nicht sehen. Aufgabe des Proxys, beim öffentlichen Lauf erneut prüfen |
+| Drei Informationen der Außenprüfung (Dateityp bei Umleitungen, Zwischenspeicherung) | Weboberfläche | Information | bewusst akzeptiert | Es sind Beschreibungen, keine Schwächen: Anmeldeseiten sind nicht speicherbar, die öffentlichen Programmdateien sind es. Daran ist nichts zu ändern |
+
+## Prüfung von außen gegen alpha
+
+Jede Zeile ist ein Lauf der passiven Außenprüfung (OWASP ZAP 2.17.0). Gezählt werden Meldungsarten, nicht einzelne Fundstellen; dieselbe Meldung auf mehreren Seiten zählt einmal.
+
+| Datum | Version | Weg | Hoch | Mittel | Niedrig | Info |
+|-------|---------|-----|------|--------|---------|------|
+| 9. Oktober 2026 | v1.10.1-80-gd15a470 (Beta) | direkt gegen die Anwendung, ohne Proxy | 0 | 2 | 6 | 3 |
+
+**Zum ersten Lauf.** Die öffentliche Adresse von alpha war an diesem Tag vom Prüfrechner aus nicht erreichbar (die Verbindung lief in eine Zeitüberschreitung). Der erste Lauf ging deshalb direkt gegen die Anwendung auf alpha, über die interne Adresse des Testservers und ohne den vorgeschalteten Proxy. Das ist ein Lauf mit denselben Regeln (passiv, keine Formulare, keine Angriffe), aber er sieht nur, was die Anwendung selbst ausliefert. Alles, was der Proxy beisteuert, etwa die verschlüsselte Verbindung (HTTPS) und deren Absicherung, konnte dieser Lauf nicht beurteilen. **Der Lauf über die öffentliche Adresse folgt, sobald diese vom Prüfrechner erreichbar ist.** Gefunden wurden 28 Seiten und Dateien; es gab keine Anmeldung und keine Datenänderung.
+
+Was die einzelnen Meldungen bedeuten:
+
+- **Fehlende Inhaltsrichtlinie (Content Security Policy), mittel.** Mit dieser Kopfzeile sagt eine Webseite dem Browser, von wo sie Skripte und andere Inhalte laden darf. Sie bremst Angriffe, bei denen fremder Code in eine Seite eingeschleust wird. Ohne sie gilt keine solche Einschränkung. Es ist eine fehlende Vorsorge, keine ausgenutzte Lücke.
+- **Fehlender Schutz gegen Einrahmen (Clickjacking), mittel.** Ohne passende Kopfzeile könnte eine fremde Seite die Anmeldeseite unsichtbar in einen Rahmen legen und Besucher zu Klicks verleiten. Zu sehen war das auf der Anmeldeseite und der Seite zum Zurücksetzen des Passworts.
+- **Fehlende Kopfzeile gegen das Umdeuten von Dateitypen, niedrig.** Sie hindert Browser daran, eine Datei als etwas anderes zu behandeln, als der Server sagt.
+- **Fehlende Berechtigungsrichtlinie, niedrig.** Damit lässt sich festlegen, auf welche Geräte-Funktionen (zum Beispiel Kamera oder Standort) eine Seite zugreifen darf.
+- **Drei fehlende Kopfzeilen zur Trennung von Seiten untereinander (Cross-Origin-Embedder-, -Opener- und -Resource-Policy), niedrig.** Sie sollen verhindern, dass fremde Seiten Inhalte der Anwendung einbinden oder beobachten. Für eine Anwendung ohne eingebettete Fremdinhalte ist der Nutzen klein.
+- **Kopfzeile „X-Powered-By“, niedrig.** Der Server nennt das Webframework, mit dem er gebaut ist. Das hilft einem Angreifer nur beim Raten, welche Schwachstellen er probieren könnte.
+- **Drei Informationen.** „Content-Type fehlt“ trifft Umleitungen und leere Antworten ohne Inhalt. „Nicht speicherbar“ und „speicherbar und zwischenspeicherbar“ beschreiben nur, ob Browser und Zwischenspeicher eine Antwort behalten dürfen: Anmeldeseiten sind zu Recht nicht speicherbar, die öffentlichen Programmdateien sind es.
+
+Die Beurteilung jeder Meldung steht in der Tabelle „Einordnung der Befunde“.
 
 ## Verlauf
 
 Der neueste Eintrag steht oben.
 
+### 2026-10-09 — Erste Prüfung von außen gegen alpha (OWASP ZAP)
+
+Passiver Erstlauf gegen alpha in der Fassung v1.10.1-80-gd15a470 (Beta), direkt gegen die Anwendung und ohne den vorgeschalteten Proxy, weil die öffentliche Adresse vom Prüfrechner nicht erreichbar war. Ergebnis: 0 hoch, 2 mittel, 6 niedrig, 3 Informationen; alle Meldungen betreffen fehlende Schutz-Kopfzeilen der Weboberfläche oder beschreiben Zwischenspeicherung. Vor dem Lauf bewies ein Probelauf gegen eine Testseite, dass das Skript keine Formulare absendet. Beurteilung: siehe „Prüfung von außen gegen alpha“ und „Einordnung der Befunde“. **Offen:** der Lauf über die öffentliche Adresse; dort werden auch die Kopfzeilen und die Verschlüsselung des Proxys sichtbar.
+
 ### 2026-10-09 — Erste vollständige Prüfung und automatische Prüfung eingerichtet
 
 Zum ersten Mal wurde das gesamte Projekt mit allen fünf Werkzeugen geprüft: Zugangsdaten in der Geschichte, Bausteine anderer Hersteller, eigener Quelltext und die beiden fertigen Abbilder. Ergebnis: keine echten Geheimnisse, 151 bekannte Schwachstellen in Bausteinen im Betrieb (5 kritisch, 73 hoch), ein echter Härtungspunkt im eigenen Quelltext und ein Server-Abbild, das Entwicklungswerkzeuge enthält. Die Einzelheiten stehen in den Abschnitten „Erste vollständige Prüfung“ und „Einordnung der Befunde“. Gleichzeitig wurde die automatische Sicherheitsprüfung nach jedem Bau eingerichtet und mit einer Gegenprobe (erfundener Köder-Code) im echten Bau-Umfeld geprüft; sie meldet nur und hält nie etwas an. Danach wurde die Liste der Ausnahmen für geprüfte Fehlalarme angelegt.