kaffeekasse-saas/docs/m0/security-baseline.md

M0 Sicherheitsbaseline

Stand: 2026-07-11

Diese Baseline ist eine statische Erstbewertung. Sie ersetzt kein Penetration Testing, markiert aber die wichtigsten Risiken für 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 Rollenprüfung	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, index.php, stricheintragen.php, einzahlung.php, letzteneintraege.php, csvupload.php abgesichert	Ungewollte Buchungen, Löschungen, Imports	CSRF für alle verbleibenden schreibenden Aktionen
Harte Deletes für Buchungen	letzteneintraege.php	Audit-Historie und Revisionsfähigkeit gehen verloren	Storno-/Reversal-Modell statt Delete
CSV-Upload nur teilweise gehärtet	csvupload.php; M2 speichert temporär unter var/uploads, prüft Dateityp und löscht nach Import	Ohne Importvorschau/Audit bleiben Fehlimporte schwer nachvollziehbar	Importvorschau, Batch-/Audit-Log und detaillierte Zeilenfehler in M6
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 mutmaßlich falscher Parameteranzahl	csvupload.php getMitarbeiterID; in M2 korrigiert	Mit Golden-Master weiter prüfen
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 enthält NUL-Zeichen	headerline.php	Datei prüfen/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 Rollenprüfung.

Für SaaS gilt:

• Menü-Ausblendung ist keine Berechtigungsprüfung.
• Jede Route braucht serverseitige Auth- und Rollenprüfung.
• Jede fachliche Route braucht Tenant-Kontext.
• IDs aus Requests müssen zum aktuellen Tenant gehören.

Empfohlene Reihenfolge für Sicherheitsarbeit

1. Secrets rotieren und aus dem Code entfernen.
2. Legacy-Schreibseiten bis zum Umbau hinter explizite Admin-Prüfung setzen.
3. CSRF-Schutz schrittweise auf alle verbleibenden Legacy-Schreibseiten ausrollen.
4. Finanzdaten im Zielmodell nur noch stornieren, nicht löschen.
5. CSV-Import mit Vorschau, Audit und Zeilenfehlern modellieren.
6. Einheitliche Escape-/View-Helfer einführen.
7. Tenant-Isolation mit Tests gegen zwei Tenants absichern.

Nicht im Repo speichern

• Produktivpasswörter.
• Echte Nutzerlisten.
• Bank-/PayPal-Exportdaten mit Personenbezug.
• AD-/LDAP-Service-Account-Daten.
• Vollständige Produktiv-Dumps.