M0 Einrichtung

2026-07-11 22:24:22 +02:00
parent 6f99e7246d
commit 2e6d79e896
21 changed files with 1246 additions and 22 deletions
@@ -0,0 +1,67 @@
+# M0 Sicherheitsbaseline
+
+Stand: 2026-07-11
+
+Diese Baseline ist eine statische Erstbewertung. Sie ersetzt kein Penetration
+Testing, markiert aber die wichtigsten Risiken fuer die SaaS-Umstrukturierung.
+
+## Kritische Sofortthemen
+
+| Risiko | Quelle | Auswirkung | Empfehlung |
+| --- | --- | --- | --- |
+| 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 |
+| Keine CSRF-Token | nahezu alle POST-/Delete-Formulare | Ungewollte Buchungen, Loeschungen, Imports | CSRF fuer alle 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 |
+
+## Weitere Befunde
+
+| Befund | Quelle | Empfehlung |
+| --- | --- | --- |
+| Direkte SQL-String-Verkettung mit Mailadresse | `functions.php` Zeilen 14, 25, 39, 55 | Parameterisierte Queries |
+| LDAP-Filter ohne Escaping | `functionsLDAP.php` LDAP-Suchen nach `samaccountname` | LDAP-Filter escapen |
+| Datumsformat `Y-d-m H:i:s` | `index.php`, `stricheintragen.php`, `einzahlung.php`, `hinweise.php` | ISO/DB-kompatibel `Y-m-d H:i:s` oder DB-Zeit verwenden |
+| Ausgabe von Namen/E-Mails teils unescaped | mehrere Tabellen, z.B. Mitgliederverwaltung | `htmlspecialchars` zentral erzwingen |
+| Fehlerausgabe mit `sqlsrv_errors()` an Nutzer | mehrere Dateien | Logging intern, neutrale Fehlermeldung extern |
+| CSV-Mitarbeitersuche mit mutmasslich falscher Parameteranzahl | `csvupload.php` `getMitarbeiterID` | Query pruefen und mit Tests abdecken |
+| Basis-Auth-Beispiel mit Platzhalter-Passwort | `umfrageergebnisse.php` Kommentarblock | Entfernen oder echte Auth-Middleware nutzen |
+| App-Navigation ist in `footer.php` | Layoutstruktur | Trennung in App-Shell und Public-Shell |
+| `headerline.php` enthaelt NUL-Zeichen | `headerline.php` | Datei pruefen/entfernen, wenn ungenutzt |
+| Massenmail ohne Versandlog | `mailversenden.php`, `jahresauswertung.php` | Job-Modell mit Dry-Run, Audit, Rate-Limit |
+
+## Rollen- und Zugriffsrisiken
+
+Aktuell gilt:
+
+- Sichtbare Admin-Navigation wird in `footer.php` per `checkKaffeelisteAdmin`
+  gesteuert.
+- Einige Admin-Zielseiten haben eigene Checks.
+- Einige schreibende oder sensible Dateien verlassen sich nicht durchgehend auf
+  eine eigene Rollenpruefung.
+
+Fuer SaaS gilt:
+
+- Menue-Ausblendung ist keine Berechtigungspruefung.
+- Jede Route braucht serverseitige Auth- und Rollenpruefung.
+- Jede fachliche Route braucht Tenant-Kontext.
+- IDs aus Requests muessen zum aktuellen Tenant gehoeren.
+
+## Empfohlene Reihenfolge fuer Sicherheitsarbeit
+
+1. Secrets rotieren und aus dem Code entfernen.
+2. Legacy-Schreibseiten bis zum Umbau hinter explizite Admin-Pruefung setzen.
+3. CSRF-Schutz in der neuen App-Basis einplanen.
+4. Finanzdaten im Zielmodell nur noch stornieren, nicht loeschen.
+5. Uploads ausserhalb des Webroots modellieren.
+6. Einheitliche Escape-/View-Helfer einfuehren.
+7. Tenant-Isolation mit Tests gegen zwei Tenants absichern.
+
+## Nicht im Repo speichern
+
+- Produktivpasswoerter.
+- Echte Nutzerlisten.
+- Bank-/PayPal-Exportdaten mit Personenbezug.
+- AD-/LDAP-Service-Account-Daten.
+- Vollstaendige Produktiv-Dumps.