Sicherheitslücken dauerhaft schließen

Worum es geht

In vielen Projekten ist Sicherheit ein punktuelles Audit: einmal geprüft, einmal behoben, schnell wieder vergessen. Diese Schulung geht von einer anderen These aus: Eine Sicherheitslücke ist ein fehlender Test.

Du arbeitest in Spatium, der Buchungssoftware eines fiktiven Coworking-Spaces mit zwei Standorten: Raumsuche, Reservierungen, Tagespässe, Gutscheine, Rechnungen und eine Verwaltung für den Empfang. Ein kleines Team hat sie in reinem PHP geschrieben, ohne Framework, Feature für Feature und jedes mit Tests, die zeigen, dass es funktioniert. Tests dafür, dass es nur so funktioniert, gibt es keine. Die Lücken sehen aus wie echte Entwicklungsfehler, vergessenes Escaping, String-Konkatenation in SQL, ein fehlender Autorisierungs-Check, und kein Framework verdeckt sie. Als Gerüst dient die Common Weakness Enumeration (CWE): Jede Schwachstellenklasse wird zu einer Station, und an jeder Station durchläufst du denselben Zyklus.

• Capture the Flag. Du findest und exploitest die Lücke von Hand, um den Angriffsvektor wirklich zu verstehen.
• Reproduzieren. Du formulierst die Sicherheitsanforderung als PHPUnit-Test, der gegen den verwundbaren Code rot ist.
• Beheben und Absichern. Du änderst den Code, bis der Test grün ist, und der Test bleibt als Regressionsschutz in deiner Testsuite.

Die „Flagge“ ist hier kein Beweis eines Einbruchs, sondern ein grüner Test, der verhindert, dass dieselbe Lücke wiederkommt, auch wenn ein Coding Agent sie beim nächsten Refactoring wieder einbauen würde.

Ab der zweiten Sitzung hilft dir ein Coding Agent. Er durchsucht Code nach verdächtigen Stellen, entwirft den roten Test und schlägt den Fix vor. Das spart Zeit, aber ein Agent findet auch Lücken, die keine sind, übersieht echte und repariert manchmal nur das eine Beispiel statt der Ursache. Du lernst, wo er hilft und wo nicht, und wie du sein Ergebnis prüfst: Den Angriff hast du selbst verstanden, und der Test ist der Schiedsrichter.

So arbeitest du

Jede Sitzung folgt demselben Rhythmus. Zuerst siehst du den Zyklus an einer Station vorgeführt, vom Exploit über den roten Test bis zum Fix, zusammen mit dem Prinzip hinter der Lösung. Dann durchläufst du ihn selbst an den weiteren Stationen der Sitzung, und zum Schluss diskutiert ihr, welche Testebene ihr gewählt habt und was ein Scanner, die statische Analyse oder der Agent gefunden hätte. Weil du jede Station unabhängig von den anderen lösen kannst, machst du an der nächsten weiter, wenn du früher fertig bist.

Der Agent kommt bewusst erst in der zweiten Sitzung dazu: Wer den Angriff nicht selbst nachvollzogen hat, kann weder den Test des Agenten noch seinen Fix beurteilen. Danach gibt es für jeden Schritt des Zyklus eine Prüffrage. Ist der Kandidat, den der Agent gefunden hat, wirklich eine Lücke? Ist sein Test aus dem richtigen Grund rot, wegen der Lücke und nicht wegen eines Fehlers im Test? Behebt sein Fix die Ursache, hält er einem abgewandelten Angriff stand, und ist der Test unverändert geblieben? Der Agent arbeitet dabei ausschließlich im Container des Übungsprojekts.

Zwischen der ersten und der zweiten Sitzung richtest du deinen Agenten im Container des Übungsprojekts ein.

Ablauf

1. 1

   Sitzung 1: Der Zyklus und Injection

   Wie wird aus einem Exploit ein Test, der bleibt?

   • Sicherheit als Eigenschaft statt als Audit, und die CWE als Checkliste für Code, der Datenbank, Template, Shell, Dateisystem oder eine Autorisierungsentscheidung berührt
   • Der Zyklus: Capture the Flag, Reproduzieren (rot), Beheben und Absichern (grün)
   • SQL-Injection, Cross-Site Scripting und OS Command Injection (CWE-89, CWE-79, CWE-78): nicht vertrauenswürdige Eingaben verlassen ihren Datenkontext
   • Das Lösungsprinzip „Daten und Code trennen“: parametrisierte Queries, automatisches Output-Escaping, Argument-Escaping
   • Warum der erste Durchlauf ohne Coding Agent stattfindet

   Ergebnis: Die ersten drei Security-Tests, ohne Agent geschrieben und jeder ein Beweis für seine Lücke, dazu das Prinzip „Daten und Code trennen“ hinter allen drei Fixes

2. 2

   Sitzung 2: Dateisystem, Testebenen und der Agent

   Wo sitzt die Lücke, und woran erkennst du, dass der Agent sie wirklich geschlossen hat?

   • Path Traversal (CWE-22) und unbeschränkter Datei-Upload (CWE-434)
   • Die passende Testebene: Unit-Test, wo die Lücke in einer Klasse sitzt, funktionaler Test an der Anwendungsgrenze
   • Der Agent im Zyklus: den roten Test aus deinem Exploit entwerfen und den Fix vorschlagen lassen, und die drei Prüffragen
   • Typische Fehler von Agenten: ein Test, der aus dem falschen Grund rot ist, ein Fix, der nur das Beispiel abwehrt, etwa eine Liste verbotener Zeichenfolgen statt einer Prüfung gegen das erlaubte Verzeichnis, und ein „angepasster“ Test

   Ergebnis: Security-Tests auf zwei Ebenen mit begründeter Wahl der Ebene, vom Agenten entworfen und behoben und von dir mit einem abgewandelten Angriff geprüft

3. 3

   Sitzung 3: Autorisierung

   Wo steht die Regel „Bob darf Alices Reservierung nicht stornieren“, außer im Test?

   • IDOR (CWE-639), fehlende Autorisierung (CWE-862) und fehlerhafte Autorisierung (CWE-285)
   • Der Bruch im Muster: Fehlerhafte Autorisierung ist ein Logikfehler, kein Problem der Eingabevalidierung, und der Test kodiert eine Geschäftsregel, die kein Werkzeug erraten kann
   • Beide Richtungen testen: Erlaubter Zugriff funktioniert weiter, unerlaubter wird abgewiesen
   • Der Agent beim Finden: Er liefert Kandidaten, etwa alle Aktionen, die eine ID aus der Anfrage verwenden; ob dort eine Regel fehlt, weiß nur, wer die Regel kennt
   • Der Agent beim Beheben: Beim Schließen einer IDOR-Lücke sperrt er oft zu viel oder prüft das Falsche, und dem Gegentest für den erlaubten Zugriff fällt das auf

   Ergebnis: Testpaare für erlaubten und verbotenen Zugriff, die die Geschäftsregel spezifizieren, und jeder Kandidat des Agenten per Exploit bestätigt oder verworfen

4. 4

   Sitzung 4: Vertrauensgrenzen und Transfer

   Wie wird die Sammlung zum dauerhaften Regressionsschutz in deinem eigenen Projekt?

   • Cross-Site Request Forgery (CWE-352), unsichere Deserialisierung (CWE-502) und SSRF (CWE-918)
   • Die Security-Tests als eigene Testsuite (phpunit --testsuite security): Bei jedem Commit prüft der Build erneut, ob eine der Schwachstellen vorhanden ist
   • Die Security-Testsuite als Leitplanke für Agenten, die dieselben Fehlerklassen einbauen wie Menschen: Eine Anweisung und ein Hook verhindern, dass ein Agent die Tests ändert
   • Was Tests leisten und was nicht: Sie ergänzen Scanner, statische Analyse, Agenten und Audits, ersetzen sie aber nicht
   • Einführung im Team: Wer TDD praktiziert, hat für Test-Driven Security schon alles außer der Gewohnheit

   Ergebnis: Eine Security-Testsuite, die bei jedem Build läuft und die kein Agent verändern darf, und eine geprüfte Liste der CWE-Klassen, die du in deinem eigenen Code als Nächstes absicherst

Für wen

• Erfahrene PHP-Entwicklerinnen und -Entwickler, die Sicherheit als festen Bestandteil ihrer automatisierten Testsuite verstehen wollen
• Teams, die Sicherheit bisher vor allem über Scanner und Audits abdecken
• Teams, in denen dieselbe Schwachstelle nach einem Refactoring zurückgekehrt ist
• Teams, die Coding Agents einsetzen und sicherstellen wollen, dass deren Code keine Lücken öffnet

Voraussetzungen

• Solide PHP-Kenntnisse und Erfahrung mit objektorientiertem Code
• Du hast schon Tests mit PHPUnit geschrieben
• Eine lokale Umgebung mit PHP und Composer, oder Podman bzw. Docker für den mitgelieferten Container
• Ab der zweiten Sitzung ein Coding Agent deiner Wahl, etwa Claude Code, Copilot Agent Mode, Cursor oder Junie, der im Projekt Dateien schreiben und Kommandos ausführen darf; Kosten und Kontingent für deinen Agenten trägst du selbst
• Wenn du in deinem Unternehmen keinen Agenten einsetzen darfst, arbeitest du mit einer anderen teilnehmenden Person zusammen
• Vorwissen in Security ist nicht nötig, Neugier auf den Blick der Angreifenden schon

Das nimmst du mit

• Du erkennst Schwachstellen, weil du den Angriffsvektor selbst nachvollzogen hast
• Du übersetzt Sicherheitsanforderungen in automatisierte Tests, statt auf einmalige Audits zu vertrauen
• Du wählst für jede Lücke die passende Testebene und kannst die Wahl begründen
• Du testest Autorisierung in beide Richtungen: Erlaubter Zugriff funktioniert weiter, unerlaubter wird abgewiesen
• Du setzt einen Coding Agent beim Finden und Beheben ein und prüfst sein Ergebnis mit dem Test
• Du hältst jede behobene Lücke mit einem grünen Test dauerhaft geschlossen, auch wenn später ein Agent den Code ändert
• Du nimmst eine Sammlung von Security-Tests mit, die du für dein Projekt adaptieren kannst

Verwandte Schulungen

Diese Schulung ist Teil des Lernpfads Sicherheit.