Was ist Broken Access Control?

Broken Access Control ist ein Sammelbegriff für Fehler in der Autorisierung. Eine Anwendung erkennt möglicherweise korrekt, wer ein Benutzer ist, prüft aber nicht, ob dieser Benutzer einen Datensatz lesen, eine Einstellung ändern oder eine administrative Funktion aufrufen darf. Das ist von der Authentifizierung zu unterscheiden: Ein gültiger Login ist keine Berechtigung für jede Ressource.

Ein typisches Beispiel ist eine Rechnungs-URL mit einer fortlaufenden ID. Zeigt die Änderung dieser ID die Rechnung eines anderen Kunden, vertraut der Server einer Benutzereingabe, statt den Besitz zu prüfen. Dieses konkrete Muster wird auch als IDOR bezeichnet.

Wie entsteht Broken Access Control?

Häufige Ursachen sind fehlende serverseitige Prüfungen, uneinheitliche Berechtigungsregeln, zu weit gefasste Rollen und Endpunkte, die nur in der Oberfläche versteckt wurden. Die Folgen reichen vom Lesen einzelner Datensätze bis zur Änderung von Rechten oder zur vollständigen Übernahme einer Anwendung.

Wie lässt sich Broken Access Control verhindern?

• - Zugriffe standardmäßig ablehnen und Berechtigungen bei jeder Anfrage serverseitig prüfen.
• - Autorisierungsregeln zentral pflegen und horizontale wie vertikale Berechtigungsgrenzen testen.
• - Nicht vorhersagbare IDs als zusätzliche Hürde nutzen, aber niemals als Ersatz für eine Rechteprüfung.
• - Abgelehnte Zugriffe protokollieren und sensible Abläufe in einem Penetrationstest prüfen.

Codebeispiel: Autorisierung an Objekt und Aktion binden

Verwundbar: Jeder angemeldete Benutzer erreicht die Funktion.

$document = Document::findOrFail($id);
return response()->download($document->path);

Sicherer: Eine zentrale Policy entscheidet für das konkrete Objekt.

$document = Document::findOrFail($id);
$this->authorize('download', $document);

return response()->download($document->path);

public function download(User $user, Document $document): bool
{
    return $user->tenant_id === $document->tenant_id
        && $user->hasPermission('documents.download');
}

Die Policy muss bei jedem Zugriffsweg greifen – auch bei API, Export, Vorschau und Hintergrundjobs. Das Laden über eine Mandantenbeziehung kann zusätzlich verhindern, dass fremde Objekte überhaupt in den normalen Datenzugriff gelangen.

Horizontale und vertikale Rechteausweitung

Bei einer horizontalen Rechteausweitung greift ein Benutzer auf Daten eines anderen Benutzers mit vergleichbarer Rolle zu, beispielsweise auf dessen Rechnung oder Support-Ticket. Eine vertikale Rechteausweitung führt dagegen in eine höher privilegierte Rolle: Ein normaler Benutzer kann etwa eine Administrationsfunktion aufrufen oder Berechtigungen verändern. Beide Varianten können auch mandantenübergreifend auftreten. In SaaS-Anwendungen ist deshalb zusätzlich die Zugehörigkeit zum richtigen Mandanten zu prüfen.

Ein typischer Angriffsablauf

Ein Angreifer beobachtet zunächst die Requests einer erlaubten Aktion und verändert anschließend Objekt-IDs, Rollenparameter, HTTP-Methoden oder nicht sichtbare API-Endpunkte. Liefert der Server fremde Daten oder führt die Aktion aus, fehlt eine serverseitige Autorisierungsentscheidung. Das Ausblenden eines Buttons schützt nicht: Browser, Skripte und Proxy-Werkzeuge können den Request weiterhin direkt senden. Auch kryptisch aussehende URLs sind keine Berechtigungsprüfung.

Wie wird Broken Access Control getestet?

Ein aussagekräftiger Test benötigt mehrere Konten, Rollen und möglichst auch Mandanten. Der Tester erstellt eine Matrix aus Objekten und erlaubten Aktionen und wiederholt Requests mit vertauschten Identitäten, IDs und Funktionen. Neben Lesen und Ändern sind Löschen, Exportieren, Freigeben und indirekte Zugriffe über Suchfunktionen oder Dateidownloads relevant. Automatisierte Scanner finden einfache Muster; komplexe Geschäftsregeln erfordern fast immer manuelle Prüfung.

Was gehört zu einer robusten Autorisierung?

Berechtigungen sollten zentral definiert, standardmäßig verweigert und bei jedem Request auf dem Server geprüft werden. Die Entscheidung muss Benutzer, Rolle, Mandant, konkretes Objekt und Aktion einbeziehen. Integrationstests sollten negative Fälle ausdrücklich abdecken. Protokollierung hilft, wiederholte abgelehnte Zugriffe zu erkennen. Zufällige IDs und getrennte Netzbereiche sind sinnvolle zusätzliche Hürden, ersetzen diese Prüfung jedoch nicht.