Ein Blick in die Realität
Insecure Design klingt theoretisch – aber in der Praxis begegnet man diesen Fehlern ständig. Es sind oft keine komplizierten Exploits, sondern simple Architekturentscheidungen, die von Anfang an unsicher waren. Hier ein paar typische Szenarien, die zeigen, wie vielfältig Insecure Design auftreten kann.
Fehlende Rollen- und Rechtekonzepte
Ein häufiges Problem: Systeme unterscheiden nicht klar zwischen Nutzerrollen.
Beispiel: Ein internes CRM-System hat zwar ein Login, aber alle Benutzer können alle Funktionen sehen und ausführen – inklusive Admin-Funktionen wie „User löschen“ oder „Reports exportieren“.
Das ist kein Bug, sondern ein Planungsfehler: Schon im Design hätte man Rollen wie „Mitarbeiter“, „Manager“ und „Admin“ definieren müssen.
Kein Schutz gegen Brute-Force-Angriffe
Stell dir ein Login-Formular ohne Begrenzung vor. Jeder kann beliebig oft falsche Passwörter ausprobieren. Ein Angreifer startet ein Script und testet in kurzer Zeit Millionen Kombinationen.
Ohne Rate Limiting, Captcha oder Account-Lockout war der Angriff im Design nie berücksichtigt – und damit ist das System von Anfang an verwundbar.
Preis-Manipulation in E-Commerce-Systemen
In vielen Shops wird der Preis im Frontend angezeigt – logisch. Aber manchmal fehlt im Design die serverseitige Validierung.
Beispiel:
Ein Produkt kostet 49,99 €. Der Preis wird im HTML-Formular als Hidden-Field übertragen:
<input type="hidden" name="price" value="49.99">
Mit den Entwicklertools im Browser ändert ein Angreifer den Wert auf 0.01.
Wenn der Server den Wert übernimmt, weil er nur im Frontend geprüft wurde, verkauft der Shop Produkte für 1 Cent.
Unsichere Standardwerte
Viele Systeme werden mit Standardpasswörtern ausgeliefert, z. B.:
- Benutzername:
admin - Passwort:
admin
Wenn im Design nicht vorgesehen ist, dass diese erzwingend geändert werden müssen, bleiben sie oft bestehen. Ergebnis: Jeder, der das Standardpasswort kennt, kann das System übernehmen.
Keine Abuse-Case-Betrachtung
Insecure Design entsteht oft, weil man nur den „Happy Path“ betrachtet:
- User registriert sich.
- User bestellt Produkt.
- User bezahlt.
Doch was, wenn ein User das System missbrauchen will?
- Unlimitierte API-Requests: Ein Bot kann tausende Requests pro Sekunde absetzen.
- Manipulierte Eingaben: Negative Preise, überlange Strings oder unerwartete Werte.
- Replay-Angriffe: Ein Nutzer sendet denselben Request mehrfach und löst so mehrfach Zahlungen aus.
Wenn solche Szenarien im Design nicht bedacht werden, sind Lücken unvermeidlich.
Fehlende Trennung sensibler Daten
Ein Beispiel aus der Praxis: Eine Anwendung speichert Kunden- und Admin-Daten in derselben Tabelle, ohne klare Trennung.
Folge: Wenn ein User Daten abruft, kann er unter Umständen auch Admin-Datensätze sehen – weil das Design keine Separation vorsieht.
Reale Vorfälle
- Ein großes Ticketportal musste tausende Bestellungen stornieren, weil Angreifer Preise im Checkout manipulieren konnten.
- In einer Banking-App war kein Limit für Überweisungen vorgesehen – so konnten Testnutzer unbegrenzte Summen an sich selbst schicken.
- Mehrere Bug-Bounty-Berichte zeigen, wie fehlendes Rate Limiting es erlaubte, Millionen Logins pro Stunde zu testen.
Was du mitnehmen solltest
- Insecure Design äußert sich in fehlenden Schutzmechanismen – nicht in kaputtem Code.
- Typische Beispiele: keine Rollenmodelle, unlimitierte Logins, Preismanipulation, Standardpasswörter.
- Solche Probleme lassen sich nicht „patchen“, sondern erfordern eine Überarbeitung des Konzepts.
Im nächsten Teil schauen wir uns an, wie man Insecure Design frühzeitig erkennt – durch Threat Modeling, Abuse-Case-Analysen und strukturierte Sicherheitsreviews.
Schreibe einen Kommentar