CSRF zweite Anpassung

docs/m0/security-baseline.md

@@ -11,7 +11,7 @@ Testing, markiert aber die wichtigsten Risiken fuer die SaaS-Umstrukturierung.
 | --- | --- | --- | --- |
 | Hart codierte DB-Zugangsdaten | `jahresauswertung.php` Zeilen 4-8 | Secret-Leak, direkte Produktiv-DB-Gefahr | Zugangsdaten rotieren, Skript deaktivieren oder auf Env-Konfiguration umstellen |
 | Schreibende Seiten ohne eigene Rollenpruefung | `stricheintragen.php`, `einzahlung.php`, `mailversenden.php`, `exportKaffeeliste.php` | Direkter URL-Aufruf kann Aktionen erlauben | Jede Seite serverseitig mit `requireRole` absichern |
-| CSRF-Schutz nur teilweise vorhanden | viele POST-/Delete-Formulare; M2 hat `hinweise.php`, `mitarbeiterverwalten.php`, `namenanpassen.php` abgesichert | Ungewollte Buchungen, Loeschungen, Imports | CSRF fuer alle verbleibenden schreibenden Aktionen |
+| CSRF-Schutz nur teilweise vorhanden | viele POST-/Delete-Formulare; M2 hat `hinweise.php`, `mitarbeiterverwalten.php`, `namenanpassen.php`, `index.php`, `stricheintragen.php`, `einzahlung.php` abgesichert | Ungewollte Buchungen, Loeschungen, Imports | CSRF fuer alle verbleibenden schreibenden Aktionen |
 | Harte Deletes fuer Buchungen | `letzteneintraege.php` | Audit-Historie und Revisionsfaehigkeit gehen verloren | Storno-/Reversal-Modell statt Delete |
 | Upload in Webroot | `csvupload.php` Zeilen 131-138 | Dateiablage kann missbraucht werden | Upload ausserhalb Webroot, Dateityp/MIME/Name pruefen |
 | Kein Tenant-Scope | alle fachlichen Queries | Zentrales SaaS-Leak-Risiko | `tenant_id` verpflichtend und Query-Schicht testen |

docs/m2-technical-foundation.md

@@ -44,10 +44,12 @@ Erste Legacy-POST-Seiten sind opt-in abgesichert:
 - `mitarbeiterverwalten.php`: Mitglied anlegen, Bearbeitungsformular oeffnen,
   Mitglied speichern, aktivieren und deaktivieren.
 - `namenanpassen.php`: Anzeigenamen aktualisieren.
+- `index.php`: eigene Web-Striche eintragen.
+- `stricheintragen.php`: Sammelerfassung von Strichen.
+- `einzahlung.php`: Sammelerfassung von Einzahlungen.
 
 Noch offen:
 
-- Buchungsflows: `index.php`, `stricheintragen.php`, `einzahlung.php`.
 - Korrektur-/Loeschflows: `letzteneintraege.php`.
 - Uploads: `csvupload.php`.
 - Spezialprozesse: `mailversenden.php`, `jahresauswertung.php`.
@@ -104,6 +106,11 @@ Die Skripte erwarten die bekannten Dev-Umgebungsvariablen `DB_HOST`, `DB_NAME`,
 - CSRF positive Tests: gueltige Token funktionieren fuer Hinweis-Anlage,
   Mitglieder-Bearbeitungsformular und Namensanpassung. Der temporaere
   Testhinweis wurde wieder entfernt.
+- CSRF negative Tests fuer Buchungsflows: `index.php`, `stricheintragen.php`
+  und `einzahlung.php` liefern bei POST ohne Token HTTP 419.
+- CSRF positive Tests fuer Buchungsflows: gueltige Token funktionieren fuer
+  eigene Web-Striche, Sammelstriche und Sammeleinzahlungen. Die temporaeren
+  Testbuchungen wurden wieder entfernt.
 - Golden Master weiterhin gruen mit 104 Assertions.
 - HTTP-Smoke weiterhin gruen mit 14 sicheren Seiten.
 
@@ -117,7 +124,7 @@ Die Skripte erwarten die bekannten Dev-Umgebungsvariablen `DB_HOST`, `DB_NAME`,
 
 ## Naechste Schritte
 
-1. Buchungs- und Korrektur-POST-Seiten einzeln mit `app_csrf_field()` und
+1. Korrektur- und Loesch-POST-Seiten einzeln mit `app_csrf_field()` und
    `app_require_csrf()` absichern.
 2. CSV-Upload gesondert absichern und spaeter Uploads ausserhalb des Webroots
    verlegen.

docs/saas-umstrukturierungsplan.md

@@ -383,7 +383,7 @@ Schritte:
 - CSRF- und Session-Basis einziehen. Session und CSRF-Helper sind vorhanden;
   globale Erzwingung erfolgt schrittweise pro POST-Seite. Erste Seiten sind
   abgesichert: `hinweise.php`, `mitarbeiterverwalten.php`,
-  `namenanpassen.php`.
+  `namenanpassen.php`, `index.php`, `stricheintragen.php`, `einzahlung.php`.
 - Konfigurationswerte aus Code in Umgebung oder Settings verschieben.
 
 Ergebnis: