Türen ohne Türsteher
Stell dir vor, ein Bürogebäude hat zwar viele Türen, aber niemand prüft, wer welche Räume betreten darf. Jeder, der einmal ins Gebäude kommt, kann plötzlich ins Chefbüro, ins Archiv oder in die Personalakte.
Genau das passiert im digitalen Raum, wenn Anwendungen keine sauberen Zugriffskontrollen haben – und diese Schwachstelle trägt den Namen Broken Access Control (BAC).
Authentication vs. Authorization
Oft werden zwei Begriffe durcheinandergebracht:
- Authentication (Authentifizierung): Beweist, wer du bist (Login mit Benutzername/Passwort).
- Authorization (Autorisierung): Bestimmt, was du darfst (z. B. Admin-Funktionen oder Zugriff auf fremde Daten).
Viele Systeme implementieren zwar einen Login, vergessen aber die saubere Autorisierung. Ergebnis: Jeder eingeloggte Nutzer kann auf Funktionen oder Daten zugreifen, die nicht für ihn gedacht sind.
Was bedeutet Broken Access Control genau?
Eine Anwendung leidet unter Broken Access Control, wenn sie nicht zuverlässig prüft, ob ein Nutzer die Berechtigung für eine bestimmte Aktion oder Ressource hat.
Typische Folgen:
- Ein normaler User ruft
/admin
auf und bekommt Zugriff auf Admin-Features. - Ein Kunde kann Rechnungen anderer Kunden sehen.
- Ein Gast ohne Login kann sensible Dateien herunterladen.
Diese Fehler sind besonders gefährlich, weil sie fast immer zu massiven Datenlecks oder Privilegien-Eskalationen führen.
Ein erstes technisches Beispiel
Nehmen wir eine API einer Online-Bibliothek. Nutzer können ihre ausgeliehenen Bücher abrufen:
GET /api/v1/loans?user=42 HTTP/1.1
Host: library.example.com
Authorization: Bearer eyJhbGciOi...
Wenn der Server nur prüft, ob der Nutzer eingeloggt ist, aber nicht, ob der eingeloggte Nutzer wirklich die user=42 ist, kann er den Wert manipulieren:
GET /api/v1/loans?user=43
Plötzlich hat er Zugriff auf die Ausleihdaten eines anderen Mitglieds.
Warum ist BAC so kritisch?
Laut OWASP gehört Broken Access Control seit Jahren zu den Top 10 der gefährlichsten Web-Schwachstellen – und liegt oft auf Platz 1. Der Grund:
- Hoher Impact: Fremde Daten, Admin-Funktionen, kritische Systeme.
- Einfache Ausnutzung: Oft reicht es, eine URL oder einen Parameter zu ändern.
- Weite Verbreitung: Jedes System mit Nutzerrollen ist potenziell betroffen.
Beispiele aus der Praxis reichen von Social-Media-Apps, bei denen Nutzer fremde private Nachrichten einsehen konnten, bis zu Finanzsystemen, die es erlaubten, Transaktionen anderer Kunden einzusehen.
Unterschiede zu IDOR
Vielleicht klingt das vertraut: IDOR (Insecure Direct Object Reference) ist ein Spezialfall von Broken Access Control. Während IDOR sich auf Objekte mit IDs bezieht, umfasst BAC ein ganzes Spektrum von Problemen: fehlende Rollenprüfungen, fehlerhafte Rechtechecks, ungeschützte Admin-Features.
Was du mitnehmen solltest
Broken Access Control bedeutet: Es fehlen oder versagen die Mechanismen, die bestimmen, wer was darf. Das führt dazu, dass Angreifer einfache Tricks nutzen können, um mehr Rechte zu erlangen, fremde Daten abzugreifen oder sogar komplette Systeme zu übernehmen.
Im nächsten Teil der Serie schauen wir uns typische Beispiele aus der Praxis an – von klassischen IDOR-Schwachstellen bis hin zu ungeschützten Admin-Panels und gefährlichen Methoden-Fehlern.
Schreibe einen Kommentar