Broken Access Control

Nahezu jede Anwendung kennt Benutzer mit unterschiedlichen Rechten: Ein Kunde sieht seine eigenen Rechnungen, ein Mitarbeiter die aller Kunden, ein Administrator ändert Rollen. Broken Access Control ist der Sammelbegriff für alle Fälle, in denen diese Trennung nicht an der einzig entscheidenden Stelle durchgesetzt wird, nämlich auf dem Server. Im Folgenden lesen Sie, wie der Fehler entsteht, was ein Angreifer damit erreicht und wie Sie ihn strukturell vermeiden.

Was ist Broken Access Control?

Broken Access Control, auf Deutsch fehlerhafte Zugriffskontrolle, ist die Schwachstellenklasse, bei der ein Benutzer Daten abrufen oder Aktionen ausführen kann, die außerhalb seiner Berechtigungen liegen, weil die Anwendung diese Grenze nicht oder nicht an der richtigen Stelle durchsetzt. Die Klasse steht seit 2021 auf Platz eins der OWASP Top 10 und bildet das Dach über mehreren bekannteren Begriffen: IDOR (Insecure Direct Object Reference), Privilege Escalation und Forced Browsing sind allesamt Ausprägungen davon.

Stellen Sie sich ein Hotel vor, in dem jede Schlüsselkarte jede Tür auf dem Flur öffnet. An der Rezeption erfahren Sie, welches Zimmer Ihres ist, aber das Schloss selbst prüft nur, ob Sie eine Karte besitzen, nicht welche. Solange sich alle an die Schilder halten, fällt nichts auf.

Zugriffskontrolle versagt in zwei Richtungen. Bei der horizontalen Ausweitung bleibt der Angreifer auf seiner eigenen Stufe, erreicht aber Daten eines anderen Benutzers mit derselben Rolle: Er zählt die Rechnungsnummer in der URL hoch und bekommt die Rechnung eines anderen Kunden zu sehen. Das ist der klassische IDOR-Fall. Bei der vertikalen Ausweitung gewinnt er Rechte hinzu. Ein gewöhnlicher Benutzer ruft eine Administrationsfunktion auf, genehmigt seinen eigenen Antrag oder weist sich selbst eine Rolle zu, die er nie hätte erhalten dürfen.

Daneben steht Forced Browsing: Ein Angreifer ruft unmittelbar einen Pfad oder Endpunkt auf, der in der Oberfläche nirgends auftaucht, etwa eine Exportfunktion unter einem Administrationspfad oder eine alte API-Version, die nie abgeschaltet wurde. Wer die Schaltfläche nicht sieht, kann die dahinterliegende Route trotzdem aufrufen. Eine Oberfläche, die Menüpunkte ausblendet, betreibt Darstellung; Zugriffskontrolle ist das nicht.

Wie funktioniert ein Angriff auf die Zugriffskontrolle?

Nehmen wir ein Rechnungsportal. Kunden melden sich an und sehen ihre eigenen Rechnungen, Administratoren dürfen Rollen ändern. Der Entwickler prüft sauber, ob jemand angemeldet ist, aber nicht, worauf dieser Jemand Anspruch hat.

Verwundbar:

// requireLogin prüft ausschließlich, ob eine gültige Sitzung besteht
app.get("/api/invoices/:id", requireLogin, async (req, res) => {
  const invoice = await db.invoices.findById(req.params.id);
  res.json(invoice);
});

// Die Schaltfläche gibt es nur im Adminbereich, daher wirkt die Route sicher
app.post("/api/users/:id/role", requireLogin, async (req, res) => {
  await db.users.update(req.params.id, { role: req.body.role });
  res.sendStatus(204);
});

Der Angreifer besitzt ein gewöhnliches Kundenkonto. Er öffnet seine eigene Rechnung, sieht die Nummer 10431 in der URL und probiert die benachbarte Nummer:

GET /api/invoices/10432 HTTP/1.1
Host: portal.example.com
Cookie: session=eyJhbGciOi

Der Server sucht die Rechnung, findet sie und liefert sie aus. An keiner Stelle wurde geprüft, ob Rechnung 10432 zu diesem Benutzer gehört. Ein kurzes Skript arbeitet den gesamten Nummernbereich ab, und binnen einer Stunde besitzt der Angreifer die vollständige Rechnungshistorie samt Namen, Adressen und Beträgen.

Die zweite Route geht weiter. Sie ist in der Kundenoberfläche nirgends verlinkt, steht aber im JavaScript-Bundle, das jeder Besucher herunterlädt. Der Angreifer stellt die Anfrage selbst zusammen:

POST /api/users/8891/role HTTP/1.1
Host: portal.example.com
Content-Type: application/json
Cookie: session=eyJhbGciOi

{"role":"admin"}

Die Anwendung stellt lediglich fest, dass eine Sitzung existiert, und führt die Änderung durch. Das ist vertikale Rechteausweitung mit einer einzigen Anfrage.

Die strukturelle Lösung besteht aus zwei Teilen. Erstens verweigern Sie standardmäßig: Eine Route ohne ausdrückliche Autorisierungsentscheidung kommt an der Middleware nicht vorbei. Zweitens prüfen Sie nicht nur die Rolle, sondern auch die Beziehung zwischen dem Benutzer und dem konkreten Objekt.

Sicher:

// Deny by Default: Jede Route muss ein Recht ausdrücklich einfordern
app.use(requireLogin);
app.use(denyUnlessAuthorized); // weist alles ohne authorize() ab

app.get("/api/invoices/:id", authorize("invoice:read"), async (req, res) => {
  const invoice = await db.invoices.findById(req.params.id);

  // Objektebene: Gehört diese Rechnung zu diesem Benutzer?
  if (!invoice || invoice.ownerId !== req.user.id) {
    return res.sendStatus(404);
  }
  res.json(invoice);
});

// authorize liest die Rechte aus der serverseitigen Sitzung, nie aus der Anfrage
app.post("/api/users/:id/role", authorize("user:manage"), async (req, res) => {
  await db.users.update(req.params.id, { role: req.body.role });
  res.sendStatus(204);
});

Der Abruf von Rechnung 10432 endet nun mit einem 404, und die Rollenänderung wird jedem verweigert, dem das Recht user:manage fehlt. Entscheidend ist, woher authorize seine Informationen bezieht: aus der serverseitigen Sitzung oder aus einem geprüften Token, niemals aus einem Header, einem versteckten Formularfeld oder einem Parameter mit einer Benutzerkennung. Alles, was der Client mitschickt, kann der Client auch ändern.

Welche Auswirkungen hat Broken Access Control?

Die Einstufung reicht von hoch bis kritisch und hängt davon ab, was hinter der fehlenden Prüfung liegt. Am leichteren Ende steht das Auslesen fremder Daten: Personendaten, Rechnungen, Akten, Nachrichten. Das ist fast immer eine meldepflichtige Datenschutzverletzung, und eine fortlaufende Nummernreihe liefert den gesamten Datenbestand statt eines einzelnen Datensatzes.

Am schwereren Ende steht die vertikale Ausweitung. Ein Angreifer, der sich selbst zum Administrator macht, kann Daten ändern oder löschen, fremde Konten übernehmen, Exporte anstoßen und häufig auch Funktionen erreichen, die das System weiter öffnen. Betrug über die Geschäftslogik gehört in dieselbe Kategorie: einen Rabatt gewähren oder ein Limit anheben, das einer anderen Rolle vorbehalten ist. Weil eine gewöhnliche HTTP-Anfrage genügt, ist die Hürde niedrig, und die Spuren in Ihren Protokollen lassen sich kaum von normalem Verhalten unterscheiden.

Wie erkennen Sie Broken Access Control?

Diese Klasse lässt sich nicht zuverlässig automatisieren, denn ein Scanner weiß nicht, wer was sehen darf. Die Prüfung beginnt daher mit einer Rechtematrix: Welche Rollen existieren, welche Aktionen soll jede Rolle ausführen können, und welche Endpunkte setzen das um.

Das praktische Vorgehen nutzt mindestens zwei Konten. Sie zeichnen die Anfragen des Kontos mit den weitreichendsten Rechten auf, spielen sie mit der Sitzung des Kontos mit den geringsten Rechten erneut ab und beobachten, ob sich die Antwort ändert. Danach ersetzen Sie Kennungen in URLs, in JSON-Feldern und in Headern durch die des anderen Benutzers. Hinzu kommen die Varianten: dieselbe Route mit einer anderen HTTP-Methode oder ein Pfad, den Sie nur aus dem JavaScript-Bundle oder veralteter API-Dokumentation kennen.

Automatisierung hilft durchaus beim Aufspüren ungeschützter Administrationspfade, die Bewertung bleibt jedoch Handarbeit. AssistSec prüft die Zugriffskontrolle im Rahmen eines Penetrationstests mit mehreren Konten je Rolle und weist je Befund nach, welche Anfrage welche Daten zurückgegeben hat.

Wie verhindern Sie Broken Access Control?

• Verweigern Sie standardmäßig. Lassen Sie das Framework jede Anfrage abweisen, solange keine ausdrückliche Autorisierungsentscheidung vorliegt. Eine neue Route ist dann geschlossen, bis jemand sie bewusst öffnet, statt umgekehrt.
• Autorisieren Sie serverseitig an jedem Einstiegspunkt. Jede Route, jede API, jeder Hintergrundjob und jeder GraphQL-Resolver. Prüfungen im Frontend sind Bedienkomfort, keine Sicherheit.
• Prüfen Sie das Objekt, nicht nur die Rolle. Stellen Sie bei jeder Anfrage die Frage, ob dieser Benutzer Anspruch auf genau diesen Datensatz hat, und verankern Sie diese Eigentumsbedingung in der Abfrage statt danach.
• Vertrauen Sie keiner Identität und keiner Rolle aus der Anfrage. Leiten Sie Benutzer und Rechte aus der serverseitigen Sitzung oder einem geprüften Token ab, niemals aus einem Parameter, einem Cookie-Feld oder einem versteckten Eingabefeld.
• Zentralisieren Sie die Entscheidung. Eine einzige Autorisierungskomponente, die überall aufgerufen wird, lässt sich prüfen und testen; über den Code verstreute Kontrollen fehlen früher oder später an einer Stelle.
• Protokollieren Sie abgewiesene Versuche und testen Sie darauf. Lassen Sie wiederholte Autorisierungsfehler eine Meldung auslösen und decken Sie die Zugriffskontrolle in Ihren automatisierten Tests mit einem Fall je Rolle ab.