Teil 2 – Typische Beispiele für Broken Access Control

Sep. 12, 2025

—

von

in Broken-Access-Control, Cyber Security, Websecurity

Mehr als nur IDOR

Im ersten Teil haben wir gesehen, dass Broken Access Control (BAC) entsteht, wenn eine Anwendung nicht zuverlässig prüft, ob ein Nutzer für eine bestimmte Aktion berechtigt ist. Ein Spezialfall davon ist IDOR – aber BAC umfasst noch viele weitere Szenarien. In diesem Artikel schauen wir uns die typischen Formen an, die in der Praxis immer wieder auftauchen.

1. Klassischer IDOR

Das bekannteste Beispiel: Ein Nutzer ändert eine ID in einer URL oder einem Request und bekommt Zugriff auf fremde Daten.

GET /api/v1/orders/1001

Wenn man die 1001 auf 1002 ändert und plötzlich die Bestellung eines anderen Kunden sieht, liegt ein IDOR vor. Das ist nur eine Variante von Broken Access Control – aber wohl die bekannteste.

2. Fehlende Rollenprüfung (Role Bypass)

Ein Online-Portal hat verschiedene Rollen: User, Manager, Admin. Doch die Anwendung prüft nicht sauber, ob nur Admins auf Admin-Seiten zugreifen dürfen.

Beispiel:

https://portal.example.com/admin

Ein normaler Nutzer ruft diese URL direkt auf und sieht plötzlich das Admin-Dashboard. Der Grund: Die Anwendung blendet den Menüpunkt zwar im Frontend aus, prüft aber nicht serverseitig, ob der Nutzer auch wirklich Admin ist.

3. Methoden-Manipulation (HTTP Verb Tampering)

Manche Anwendungen erlauben bestimmte Aktionen nur für Admins, prüfen aber nur den Request-Typ.

Beispiel:

GET /api/v1/users/42   → erlaubt
DELETE /api/v1/users/42 → eigentlich nur für Admins

Wenn die Anwendung nicht prüft, ob der Nutzer Admin ist, reicht es, den Request-Typ zu ändern – und plötzlich kann jeder Nutzer Accounts löschen.

4. Ungeschützte Admin-Panels

Viele Systeme haben versteckte Admin-Seiten, die aber nicht wirklich abgesichert sind.

/admin
/manage
/config

Wenn kein Login oder keine Rollenprüfung vorgeschaltet ist, kann jeder, der die URL kennt, diese Seiten aufrufen. In Bug-Bounty-Programmen gehören ungeschützte Admin-Panels zu den beliebtesten Funden.

5. Zugriff auf sensible Dateien

Auch Dateizugriffe können fehlerhaft abgesichert sein. Beispiel:

https://app.example.com/download?file=report.pdf

Wenn man den Parameter einfach ändert auf backup.zip oder config.yml und die Anwendung liefert die Datei aus, hat man eine klassische BAC-Schwachstelle. Besonders kritisch wird es, wenn so interne Backups, Quellcode oder Konfigurationsdateien erreichbar sind.

6. Privilege Escalation

Manchmal erlaubt BAC nicht nur den Zugriff auf fremde Daten, sondern eine Rechteskalation. Das bedeutet: Ein normaler User kann sich zusätzliche Privilegien verschaffen.

Ein Beispiel:
Ein Formular enthält ein verstecktes Feld role=user.
Wenn der Nutzer es zu role=admin ändert und der Server das ungeprüft übernimmt, ist er plötzlich Administrator.

Reale Vorfälle

In einer bekannten Social-Media-App konnten Nutzer private Nachrichten anderer Personen lesen, weil die Rollenprüfung fehlerhaft war.
Ein Ticketportal erlaubte den Download fremder Eintrittskarten, indem man einfach die Ticket-ID in der URL veränderte.
Eine Bank-App prüfte nicht, ob eine Überweisungs-ID zum eingeloggten Kunden gehörte – so konnten Nutzer Details fremder Transaktionen sehen.

Was du mitnehmen solltest

Broken Access Control ist vielfältig: von simplen IDORs über fehlende Rollenprüfungen bis hin zu ungeschützten Admin-Panels. Alle diese Schwachstellen haben gemeinsam, dass sie zu viel Vertrauen in den Client oder in Annahmen über den Nutzer setzen.

Im nächsten Teil der Serie schauen wir uns an, wie man solche Schwachstellen systematisch entdeckt – mit manuellen Tests, cleveren Tricks und hilfreichen Tools wie Burp Suite oder Postman.