Teil 3 – Wie man Broken Access Control entdeckt

Sep. 12, 2025

—

von

in Broken-Access-Control, Cyber Security, Websecurity

Der erste Schritt: Rollen verstehen

Bevor man testet, muss man die Rollen und Berechtigungen der Anwendung kennen. Typische Rollen sind Gast, eingeloggter Nutzer, Moderator, Admin.
Ein guter Test beginnt damit, alle Rollen durchzuspielen und zu notieren, welche Aktionen eigentlich erlaubt sein sollten.
Das Ziel: Abweichungen finden zwischen dem, was die App vorgibt, und dem, was technisch tatsächlich möglich ist.

Rollenwechsel und Rechte testen

Ein Klassiker ist der Role Bypass. Beispiel:

Ein normaler User darf nur sein eigenes Profil ändern.
Ein Admin darf jedes Profil ändern.

Test:

Als normaler User ein Update-Request absenden.
Die User-ID im Request manipulieren.
Prüfen, ob die App den Update dennoch durchführt.

Wenn ja, hat man einen klaren BAC-Fund.

URL- und Parameter-Manipulation

Viele BAC-Schwachstellen lassen sich durch simples Herumprobieren entdecken:

https://portal.example.com/admin
https://portal.example.com/user/42
https://portal.example.com/user/43

Indikatoren:

403 oder 401 = Zugriff verweigert (gut).
200 = Zugriff gewährt (verdächtig).
Unterschiedliche Antwortgrößen oder Inhalte = Hinweis auf fremde Daten.

Auch API-Parameter sind verdächtig:

GET /api/v1/orders/1001
GET /api/v1/orders/1002

HTTP-Methoden variieren

Manchmal sperrt eine App nur bestimmte Funktionen im UI, aber der Endpunkt selbst bleibt offen.
Test: Statt nur GET-Requests zu senden, auch mal POST, PUT oder DELETE ausprobieren.

Beispiel:

DELETE /api/v1/users/42

Wenn das als normaler User funktioniert, obwohl nur Admins löschen dürften, ist das ein klarer BAC-Fall.

Tools für die Praxis

Browser-Entwicklertools

Für schnelle Tests reichen die DevTools: Netzwerkanalyse aktivieren, Requests beobachten, Parameter ändern, erneut senden.

Postman

Ideal für API-Tests. Requests lassen sich leicht duplizieren, Parameter ändern und die Antwort vergleichen.

Burp Suite

Das Standard-Tool vieler Pentester. Besonders hilfreich:

Proxy: Alle Requests mitschneiden und manipulieren.
Repeater: Einen Request immer wieder mit Variationen abfeuern.
Intruder: Systematisch Parameter durchprobieren (z. B. IDs von 1 bis 1000).

Mit Burp Suite lassen sich auch Rollenwechsel gut simulieren:

Session-Cookies von User A vs. User B speichern.
Dieselben Requests mit beiden Sessions abfeuern und Unterschiede beobachten.

Worauf man achten sollte

Statuscodes: 200, obwohl man keinen Zugriff erwartet, ist verdächtig.
Antwortgröße: Plötzliche Änderungen deuten auf unterschiedliche Inhalte hin.
Fehlermeldungen: „Access denied“ ist besser als „User not found“ – letzteres verrät Informationen.
Versteckte Features: Buttons im Frontend ausgeblendet ≠ Funktion abgesichert.

Systematisches Vorgehen

Mapping: Alle Endpunkte und Funktionen sammeln.
Baseline: Erwartetes Verhalten pro Rolle festlegen.
Testing: Requests mit verschiedenen Rollen, Sessions und Parametern abfeuern.
Dokumentation: Ergebnisse festhalten, Screenshots/Logs sichern.

Das hilft nicht nur beim Finden, sondern auch beim klaren Melden von Schwachstellen.

Was du mitnehmen solltest

Broken Access Control findet man, indem man neugierig ist: URLs ändern, Methoden ausprobieren, Rollen vergleichen. Mit Tools wie Postman und Burp Suite lässt sich das systematisch und effizient durchführen.

Im nächsten Teil der Serie schauen wir uns an, wie Entwickler*innen ihre Anwendungen schützen und absichern können – damit BAC von Anfang an vermieden wird.