Warum Erkennen so schwierig ist
Bugs wie SQL Injection oder XSS lassen sich oft durch automatisierte Scanner entdecken. Insecure Design dagegen ist schwerer zu fassen – es geht nicht um eine fehlerhafte Codezeile, sondern um grundsätzliche Architekturentscheidungen.
Das bedeutet: Um Insecure Design zu erkennen, muss man verstehen, wie das System funktionieren soll – und was passieren könnte, wenn jemand es missbraucht.
Threat Modeling – den Angreiferblick einnehmen
Ein bewährter Ansatz ist das Threat Modeling:
- Welche Assets (z. B. Kundendaten, Geldflüsse, interne Systeme) sind schützenswert?
- Welche Angreifer gibt es (Externe, Insider, Bots)?
- Welche Angriffsvektoren sind denkbar (z. B. Manipulation von Parametern, automatisierte Logins)?
Ein Framework dafür ist STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege).
Beispiel: Beim Checkout in einem Online-Shop könnte ein Angreifer versuchen, den Preis zu manipulieren (Tampering) oder das System mit tausenden Bestellungen lahmzulegen (Denial of Service).
Abuse Cases statt nur Happy Path
In klassischen Anforderungen denkt man an den „Happy Path“:
- User registriert sich.
- User bestellt Produkt.
- User bezahlt.
Doch Angreifer folgen keinem Happy Path. Deshalb braucht es Abuse Cases – Szenarien, wie ein böswilliger Nutzer die Funktionen missbrauchen könnte.
Beispiele für Abuse Cases:
- „Ein User versucht, 1 Million Login-Versuche in einer Minute zu machen.“
- „Ein Kunde ändert den Preis im Checkout auf 0 €.“
- „Ein Nutzer ruft API-Endpunkte auf, die eigentlich nur für Admins gedacht sind.“
Solche Szenarien helfen, im Design frühzeitig Schwachstellen zu erkennen.
Security Reviews im Designprozess
Security darf nicht erst beim Code-Review beginnen. Schon im Design Review sollten Security-Experten dabei sein und gezielt Fragen stellen:
- Sind Rollen und Berechtigungen klar definiert?
- Gibt es Limits (z. B. maximale Requests, maximale Beträge)?
- Sind sensible Daten sauber getrennt?
Eine einfache Methode: Architekturdiagramme mit Sicherheitsfokus.
Man markiert, wo Daten fließen, wo Grenzen (Trust Boundaries) liegen und welche Schutzmaßnahmen vorgesehen sind.
Werkzeuge und Methoden
- Attack Trees: Angriffsziele als Baum darstellen → Welche Schritte könnte ein Angreifer gehen?
- Secure Design Workshops: Entwickler, Architekten und Security-Spezialisten prüfen gemeinsam geplante Features.
- Checklisten: OWASP bietet Leitfäden wie das Security by Design Cheat Sheet, die helfen, systematisch vorzugehen.
- Prototyping: Schon frühe Versionen einer Anwendung gezielt auf Missbrauch testen.
Ein kleines Beispiel: Login-System
- Happy Path: User gibt Name + Passwort ein → Login klappt.
- Abuse Cases:
- User testet 10.000 Passwörter pro Minute → Brute Force.
- User versucht, Passwort-Reset-Link mehrfach zu nutzen → Replay.
- User ändert den Request, um Rollenparameter zu manipulieren.
Wenn diese Abuse Cases schon im Design geprüft werden, ist klar: Das System braucht Rate Limiting, Einmal-Token und serverseitige Rollenprüfung.
Was du mitnehmen solltest
- Insecure Design erkennt man nicht mit Scannern, sondern mit kritischem Denken und Planung.
- Threat Modeling hilft, Angriffsvektoren sichtbar zu machen.
- Abuse Cases zeigen, wie Systeme missbraucht werden könnten.
- Security Reviews im Design sind genauso wichtig wie Code Reviews.
Im nächsten Teil schauen wir uns an, wie man durch Best Practices und Security by Design solche Schwachstellen schon beim Entwurf verhindert.
Schreibe einen Kommentar