Broken Access Control

Warum es wichtig ist

Authentifizierung beantwortet, wer du bist. Autorisierung beantwortet, was du tun darfst. Broken Access Control ist das, was passiert, wenn eine Anwendung das Erste prüft und das Zweite vergisst. Es ist der häufigste schwere Fehler im Web, weshalb OWASP es 2021 auf Platz eins der Top 10 verschoben hat, und es ist oft die Klasse, die ein Einsteiger am leichtesten findet, weil die Ausnutzung so einfach sein kann wie das Ändern eines einzigen Werts in einem Request.

Gängige Typen

• IDOR und BOLA: tausche eine Objektkennung und erhalte die Daten eines anderen Nutzers. Siehe IDOR und BOLA.
• Vertikale Privilege Escalation: ein normaler Nutzer erreicht Admin-Funktionalität, die er nicht sollte. Siehe Privilege Escalation.
• Forced Browsing: das direkte Navigieren zu versteckten oder nicht verlinkten Endpunkten, die nie erreichbar sein sollten.
• HTTP Method Tampering: ein unbewachtes Verb wie HEAD oder OPTIONS umgeht eine Kontrolle, die nur für GET und POST gesetzt war.
• Headerbasierter Bypass: das Spoofen von X-Forwarded-For: 127.0.0.1 oder die Nutzung von X-Original-URL, um eine IP- oder Pfadbeschränkung auszuhebeln und einen 403 in einen 200 zu verwandeln.

Ein durchgespieltes Beispiel

Ein Request an /api/admin/backup gibt 403 Forbidden mit der Meldung "admin IP required" zurück. Das Hinzufügen des Headers X-Forwarded-For: 127.0.0.1 gibt 200 OK mit der Backup-Datei zurück, weil der Server einem vom Client gelieferten IP-Header vertraut, den er nie validiert hat. Getrennt davon gibt das Ändern von userId=123 zu userId=124 das Profil eines anderen Nutzers zurück, weil der Server bestätigt hat, dass die Session gültig war, aber nie die Objekt-Eigentümerschaft geprüft hat. Beides ist Broken Access Control, gefunden durch Parameter Tampering und Header-Manipulation in einem Proxy wie Burp Suite.

Wie du darauf testest

Die zuverlässige Methode nutzt zwei Konten. Logge dich als Nutzer A ein, fange einen Request ab, der eines seiner Objekte erreicht, und sende ihn dann mit der Session von Nutzer B erneut, oder tausche einfach die Kennung, und sieh, ob die Daten von Nutzer A zurückkommen. Teste jede CRUD-Aktion, nicht nur Lesezugriffe, da Update und Delete oft weniger geschützt sind. Versuche, Admin-Endpunkte als normaler Nutzer zu erreichen, ganz ohne Session auf die Anwendung zuzugreifen und die obigen Methoden- und Header-Bypässe zu kombinieren. Eine Kontrolle, die für ein GET hält, kann für ein DELETE versagen.

Auswirkungen

Weil die Zugriffskontrolle jedes Objekt und jede Aktion regelt, kann ein einziger Fehler die Daten jedes Nutzers offenlegen, eine Kontoübernahme ermöglichen oder administrative Kontrolle gewähren. Echte Vorfälle reichen vom Lesen der Rechnungen anderer Kunden bis zur massenhaften Datenextraktion über eine einzige aufzählbare Kennung, weshalb Triage-Teams diese Funde konsistent hoch einstufen.

Prävention

Verweigere standardmäßig und gewähre ausdrücklich. Erzwinge die Autorisierung serverseitig bei jedem Request, prüfe die Objekt-Eigentümerschaft statt nur des Login-Status, wende Kontrollen auf alle Methoden an und vertraue niemals vom Client gelieferten Headern zur Identität oder versteckten URLs zum Schutz. Zentralisiere die Logik, teste mit mehreren Konten und alarmiere bei Zugriffen, die Nutzergrenzen überschreiten.