Die 14 Angriffsszenarien

Technische Aussage Beleg: Test Stand: 28.10.2026

Worum geht es?

Ein Angriffsszenario stellt die Frage: Was passiert, wenn jemand dieses Konto übernimmt oder diesen Weg ausprobiert? Zu jedem der 14 Szenarien gibt es automatisierte Tests, deren Ergebnis im Monatsbericht steht. Manche Szenarien haben dokumentierte Grenzen, die wir offen nennen.

Schutzziel

Wir wollen nicht nur wissen, dass einzelne Schutzmaßnahmen funktionieren, sondern was passiert, wenn jemand sie gezielt zu umgehen versucht. Die Szenarien übersetzen typische Angriffe in prüfbare Fragen.

Funktionsprinzip

Jedes Szenario ist im Quelltext einer Gruppe von Testklassen zugeordnet. Der Monatsbericht entsteht aus einem echten Testlauf: Ein Szenario gilt nur dann als bestanden, wenn seine Tests im aktuellen Lauf vorkommen und bestehen. Fehlt ein Test oder schlägt er fehl, wird das Szenario nicht aus einem früheren Bericht übernommen, sondern als Rückschritt gemeldet.

Maßnahmen

Die Tabelle zeigt, was geprüft wird und ob der Bericht bei einem Szenario eine Grenze nennt (Stand: Oktober 2026). Die Bezeichnungen der Szenarien übernehmen wir aus dem Bericht.

Szenario	Was geprüft wird	Hinweis im Bericht
Compromised User	Ein angemeldeter Nutzer versucht, auf Daten anderer Projekte zuzugreifen.	–
Cross-Tenant IDOR	Ein Nutzer tauscht in Anfragen Kennungen aus, um fremde Projekte zu erreichen.	–
Compromised Co-Author	Ein Co-Autor-Konto ist übernommen: Reicht der Zugriff nur so weit wie vergeben, und werden gesperrte Konten bei jeder Anfrage ausgeschlossen?	–
Compromised Editor	Ein Lektorats-Zugang ist übernommen: Bleibt er auf das freigegebene Buch und seine Stufe begrenzt?	–
Compromised Admin	Ein Admin-Konto der Nutzerverwaltung ist übernommen: Kommt es an Buchinhalte?	dokumentierte Grenze
Session Hijacking	Eine gestohlene Sitzung wird von einem anderen Gerät genutzt.	dokumentierte Grenze
Race Conditions	Gleichzeitige Anfragen versuchen, Prüfungen zu überholen, etwa beim Speichern oder Beanspruchen eines Kapitels.	–
API Manipulation	Anfragen mit zusätzlichen Feldern versuchen, Werte zu setzen, die ein Nutzer nicht setzen darf.	–
Vault Policy Bypass	Jemand versucht, die Schlüsselverwaltung außerhalb ihrer Zugriffsregeln zu nutzen.	–
Authenticated Scraping	Ein angemeldeter Nutzer versucht, Daten massenhaft auszulesen.	–
Branch/Merge Manipulation	Beim Abzweigen und Zusammenführen von Zeitlinien wird versucht, Regeln zu umgehen.	–
Permission Escalation	Ein Gast oder Co-Autor versucht, sich höhere Rechte zu verschaffen.	–
Compromised Symfony Runtime	Der Anwendungsprozess läuft unter fremder Kontrolle: Was schützt die Schlüsselverwaltung?	dokumentierte Grenze
Deployment Integrity	Code auf dem Server wird nachträglich verändert oder die Auslieferung manipuliert.	bekannte verbleibende Maßnahme

Was wir nicht versprechen

Die 14 Szenarien sind eine Auswahl und keine abschließende Liste möglicher Angriffe.
„Compromised Admin“: Dass Admins der Anwendung keine Buchinhalte sehen, gilt nicht gegenüber Personen mit Root-Zugriff auf den Server.
„Session Hijacking“: Die Erkennung übernommener Sitzungen hat dokumentierte Grenzen und erkennt nicht jede Übernahme. Einzelheiten stehen im Bericht.
„Compromised Symfony Runtime“: Ein aktiv kompromittierter Anwendungsprozess kann zur Laufzeit Daten erreichen, die im Arbeitsspeicher liegen.
„Deployment Integrity“: Die Erkennung nachträglicher Code-Änderungen existiert und ist getestet. Weitere Härtung der Auslieferung ist offen, Einzelheiten stehen im Bericht.

Wie wir das prüfen

Die Zuordnung der Szenarien zu Testklassen ist im Quelltext festgelegt, und ein Test stellt sicher, dass jede genannte Testklasse existiert. Die Ergebnisse stehen je Monat im Bericht. Die Nachweis-Tests unten zeigen, welche Tests welchem Szenario dienen.

Nachweis-Tests

Test	Das belegt der Test
`AuthorizationCoverageTest`	Compromised User, Compromised Admin: Jede Route der Anwendung hat eine ausdrückliche Entscheidung zur Zugriffsprüfung.
`IdSubstitutionCrossTenantTest`	Compromised User, Cross-Tenant IDOR: Anfragen mit ausgetauschten Kennungen erreichen keine Daten fremder Projekte.
`TenantFilterCoverageTest`	Compromised Co-Author: Jede Tabelle mit Projektbezug wird automatisch auf die erlaubten Projekte eingegrenzt.
`VoterUserStatusGateCoverageTest`	Compromised Co-Author: Jede Rechteprüfung berücksichtigt den aktuellen Kontostatus.
`GuestEditorialAccessTest`	Compromised Editor: Der Lektorats-Zugang reicht nur so weit wie vorgesehen.
`EditorialGrantInvitationTest`	Compromised Editor: Nur die Eigentümerin oder der Eigentümer kann Lektorats-Zugänge vergeben, ein Co-Autor nicht; Bücher aus anderen Projekten werden abgelehnt.
`EncryptionCoverageTest`	Compromised Admin: Textfelder wie der Kapitelinhalt sind als verschlüsselt eingetragen, nicht als Klartext.
`UserLegalDataVisibilityVoterTest`	Compromised Admin: Auch ein Admin der Nutzerverwaltung sieht die Rechtsdaten eines anderen Kontos nicht.
`SessionHijackDetectionTest`	Session Hijacking: Eine Sitzung, die plötzlich von einem anderen Browser genutzt wird, wird beendet und das Konto benachrichtigt.
`ChapterContentSaveRaceConditionTest`	Race Conditions: Gleichzeitiges Speichern desselben Kapitels überschreibt nichts still.
`ChapterClaimRaceConditionTest`	Race Conditions: Beanspruchen zwei Nutzer gleichzeitig dasselbe freie Kapitel, gewinnt nur einer.
`MassAssignmentProtectionTest`	API Manipulation: Eine Anfrage kann Systemfelder wie den Eigentümer eines Projekts nicht überschreiben.
`VaultLeastPrivilegePolicyTest`	Vault Policy Bypass, Compromised Symfony Runtime: Die Anwendung hat in der Schlüsselverwaltung nur die Rechte, die sie braucht.
`VaultFailClosedTest`	Compromised Symfony Runtime: Ist die Schlüsselverwaltung nicht erreichbar, wird abgelehnt statt weitergearbeitet.
`GenericAuthenticatedReadRateLimitTest`	Authenticated Scraping: Zu viele lesende Anfragen eines angemeldeten Kontos werden abgelehnt.
`TimelineBranchTest`	Branch/Merge Manipulation: Eine abgezweigte Zeitlinie lässt den Hauptstrang unverändert, fremde Kapitel werden abgelehnt.
`TimelineBranchMergeTest`	Branch/Merge Manipulation: Zusammenführen verlangt Bearbeitungsrecht und meldet einen Konflikt, wenn der Hauptstrang sich seit dem Abzweigen verändert hat.
`AccessGrantEditorialPermissionEscalationTest`	Permission Escalation: Ein Co-Autor kann eine Freigabe weder direkt noch per Änderung auf Lektorats-Rechte heben.
`IntegrityVerifyCommandTest`	Deployment Integrity: Geänderte, neue und entfernte Dateien werden erkannt.

Zum Bericht

Änderungsverlauf

28.10.2026: Erste Fassung.