Teil 1 – Was ist Insecure Design?

Ein Haus mit falschem Bauplan

Stell dir vor, du planst ein Haus. Die Türen sind stabil, die Fenster sind sicher, aber der Architekt hat vergessen, eine Wand zwischen Garage und Schlafzimmer einzuzeichnen. Egal wie solide die Handwerker später bauen – jeder, der durch die Garage kommt, steht plötzlich direkt im Schlafzimmer.
Genau so ist es mit Insecure Design: Das Problem liegt nicht in der Umsetzung, sondern schon im Bauplan.


Definition von Insecure Design

Unter Insecure Design versteht man Schwachstellen, die dadurch entstehen, dass Sicherheitsaspekte bereits in der Architektur oder Planung nicht berücksichtigt wurden.
Das bedeutet: Selbst wenn der Code technisch fehlerfrei ist, bleibt das System unsicher, weil das Grundkonzept Lücken hat.

Wichtig: Insecure Design unterscheidet sich von klassischen „Bugs“.

  • Implementation Bug: Ein Programmierfehler, z. B. fehlendes Escaping bei SQL Queries.
  • Insecure Design: Ein Planungsfehler, z. B. ein System ohne Rollenmodell oder ohne Begrenzung der Login-Versuche.

Beispiele aus der Praxis

Damit es greifbarer wird, hier ein paar typische Szenarien:

  • Fehlendes Rollenmodell
    Eine interne Plattform unterscheidet nicht zwischen normalen Nutzern und Administratoren. Ergebnis: Jeder eingeloggte User kann Einstellungen ändern, die eigentlich nur für Admins gedacht waren.
  • Kein Schutz gegen Brute Force
    Ein Login-Formular erlaubt unendlich viele Versuche. Ein Angreifer kann automatisiert Millionen Passwörter ausprobieren, bis er das richtige findet.
  • Preis-Manipulation im E-Commerce
    Ein Shop prüft Preise nur im Frontend. Wer mit den Browser-DevTools den Wert ändert, kann Produkte für „0 €“ kaufen – und der Server akzeptiert es, weil kein Server-Side-Check vorgesehen ist.
  • Unsichere Standardwerte
    Ein System kommt mit Default-Passwörtern wie admin/admin. Wenn diese nicht erzwungen geändert werden, hat jeder sofort Zugriff.

Warum Insecure Design so gefährlich ist

Das Besondere an Insecure Design:

  • Schwer zu fixen: Man kann nicht einfach ein paar Codezeilen ändern – oft braucht es ein neues Konzept.
  • Systemisch: Die Schwachstelle betrifft die gesamte Architektur, nicht nur ein Modul.
  • Leicht übersehbar: Entwickler konzentrieren sich oft auf den „Happy Path“ – also den idealen Ablauf – und vergessen Missbrauchsszenarien.

Genau deshalb hat OWASP „Insecure Design“ 2021 erstmals in die Top 10 der gefährlichsten Web-Schwachstellen aufgenommen.


Abgrenzung zu anderen Schwachstellen

  • Nicht das Gleiche wie Broken Access Control:
    Broken Access Control entsteht, wenn Rechte zwar vorgesehen, aber schlecht umgesetzt sind. Insecure Design heißt: Die Rechte wurden im Konzept gar nicht bedacht.
  • Nicht das Gleiche wie Misconfiguration:
    Fehlkonfigurationen entstehen oft im Betrieb (z. B. ein offener S3-Bucket). Insecure Design passiert schon beim Entwurf.

Was du mitnehmen solltest

  • Insecure Design bedeutet: Sicherheitslücken entstehen schon in der Planung.
  • Typische Beispiele: fehlende Rollen, keine Limits, unsichere Standardwerte.
  • Das macht es schwerer zu beheben als einen Bug – man muss die Architektur überdenken.
  • Sicherheit darf nicht „später“ hinzugefügt werden – sie gehört in den Bauplan.

Im nächsten Teil schauen wir uns konkrete Beispiele an, wie Insecure Design in der Praxis aussieht – von unsicheren Rollenmodellen über fehlendes Rate-Limiting bis zu E-Commerce-Manipulationen.


Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert