OWASP Top 10 API-Security-Risiken: Fehlerhafte Autorisierung auf Objektebene

Obwohl die Liste für 2023 noch nicht abgeschlossen ist, können Sie alle Top-10 der API-Security-Risiken auf der Github-Website des Open Worldwide Application Security Project® (OWASP) lesen und kommentieren. Das Risiko Nr. 1 auf der Liste ist die fehlerhafte Autorisierung auf Objektebene (BOLA).

BOLA entsteht, wenn ein Bedrohungsakteur erfolgreich eine Anfrage nach Datenobjekten stellt, die eingeschränkt sein sollten.

Angriffsvektoren

Angreifer nutzen API-Endpunkte aus, indem sie die ID eines in einer Anfrage enthaltenen Objekts manipulieren und die API dazu verleiten, vertrauliche und geschützte Daten zurückzugeben. BOLA können in Anwendungen auftreten, in denen die Serverkomponente die Client-Zustände nicht vollständig verfolgt und sich auf Objekt-IDs verlässt, um zu bestimmen, auf welche Objekte zugegriffen werden soll.

OWASP hat eine Ausnutzbarkeit-Punktzahl von zwei zugewiesen, was bedeutet, dass sie von Hackern leicht ausgenutzt werden können.

Security-Schwächen

Laut OWASP ist dies einer der häufigsten und folgenreichsten Angriffe auf API.

Auch wenn die Anwendung eine entsprechende Infrastruktur zur Überprüfung von Berechtigungen implementiert, vergessen Entwickler manchmal, diese Überprüfungen durchzuführen, bevor sie den Zugriff auf sensible Objekte gestatten. Die Erkennung von Zugriffskontrollen reagiert nicht unbedingt auf automatisierte statische oder dynamische Tests, was bedeutet, dass Schwachstellen unentdeckt bleiben können.

OWASP stuft BOLAs außerdem auf der Skala ihrer Verbreitung mit drei ein. Diese Security-Bedrohung findet man in einer Vielzahl von Domains und Apps.

Geschäftliche Auswirkungen

Jedes Mal, wenn unbefugter Zugriff auf sensible Daten erteilt wird, besteht das Risiko von Offenlegung und Haftung. Der unbefugte Zugriff auf einige Objekte kann auch die Tür für weitere Datenverluste öffnen, einschließlich Account Takeover.

BOLA-Exploits können Folgendes verursachen:

• Verluste von sensiblen Datensätzen in großem Umfang
• Manipulation von Datensätzen, einschließlich Anzeigen, Ändern oder Löschen
• Rechte-Ausweitung
• Vollständige Übernahme von Administratorkonten

So funktionieren BOLA-Angriffe

Angreifer sondieren, ob Systeme vorhanden sind, die Muster innerhalb von Codes für Anfragen verwenden. Sie können beispielsweise testen, ob es BOLA-Fehler gibt, indem sie Benutzer-IDs oder Objekt-IDs ändern, um zu sehen, wie die API reagiert. Sobald sie einen solchen Fehler finden und sich Zugriff verschaffen, sind API ohne die richtigen Security-Protokolle einem erheblichen Risiko ausgesetzt. Sobald ein Bedrohungsakteur über die API Zugriff erhält, können alle Daten gefährdet sein.

So könnte sich dies in einem realen Szenario abspielen. Jemand könnte mit einer Kunden-ID rechtmäßig oder unrechtmäßig Zugriff auf das System eines Unternehmens erhalten. Nachdem der Zugriff authentifiziert ist, wird seine Identität durch ein Token dargestellt. In einer API-Anfrage wird die Kunden-ID, die für den Zugriff verwendet wurde, durch die ID eines anderen Benutzers ersetzt, um Zugriff auf die personenbezogenen Daten eines anderen Benutzers zu erhalten.

Wenn die Angreifer wissen, dass dies funktioniert, können sie den Prozess des Ersetzens von Kunden-ID-Nummern in nachfolgenden Anfragen automatisieren und zusätzliche Datensätze exfiltrieren.

Ein Zugangsdaten-Stuffing-Angriff kann beispielsweise verwendet werden, um eine Datenverletzung in einem Finanzinstitut durchzuführen. Durch die Änderung von Anfrage-Kennungen haben Angreifer Zugriff auf verschiedene Benutzerkonten und können möglicherweise sogar Geld überweisen oder Daten an verschiedene Endpunkte umleiten.

OWASP verwendet das Beispiel eines Automobilherstellers, der die Fernsteuerung von Fahrzeugen per API vom Mobiltelefon eines Fahrers aus mit der Fahrgestellnummer eines Fahrzeugs ermöglicht. Ein Bedrohungsakteur könnte theoretisch ein Gerät authentifizieren und dann die Fahrgestellnummer eines anderen Fahrzeugs austauschen, die online oder auf dem Fahrzeug selbst verfügbar ist. Wenn die API nicht erkennt, dass die Authentifizierung nicht zum tatsächlichen Besitzer gehört, können Angreifer möglicherweise auf das Fahrzeug zugreifen, es starten oder stehlen.

Beispiele aus der Praxis

Ein solcher Verstoß ist angeblich die Ursache für eine Verletzung von Kundendaten bei T-Mobile, von der 2018 rund 2,3 Millionen Abonnenten betroffen waren. Ein weiterer API-basierter Angriff könnte 2023 ebenfalls 37 Millionen T-Mobile-Benutzer getroffen haben.

Eine Schwachstelle wurde in den APIs von Social-Media-Plattformen  entdeckt, die von Facebook und Parler gehören. Im Fall von Facebook könnten diese Schwachstellen Angreifern ermöglichen, Beiträge auf den Seiten anderer Benutzer zu erstellen. Die Beiträge waren zwar in den Newsfeeds nicht sichtbar, konnten aber über Links aufgerufen werden.

Parler ließ den API-Zugriff auf öffentliche Beiträge ohne Authentifizierung zu. Da Beiträge-IDs von Parler sequenziell waren, konnten Angreifer die ID-Nummern leicht ersetzen. Da es keine Ratenbegrenzung gab, konnte die Automatisierung Daten mit einer extrem hohen Rate extrahieren.

Erkennung von BOLA-Schwachstellen

Laut OWASP bewertet BOLA die Erkennbarkeit mit zwei. API-Scans und -Tests sind Best Practices zum Erkennen von BOLA-Schwachstellen.

Die Erkennung beginnt mit der Auswertung von API-Endpunkten und -Identifikatoren.

Techniker können Objekt-IDs in einem API-Lebenszyklus testen. Es können zum Beispiel Testfälle erstellt werden, bei denen Objekt-IDs ersetzt werden müssen, um nach Fehlermeldungen zu suchen. Wenn keine Fehlermeldung zurückgegeben wird, kann dies auf eine potenzielle Gefährdung hindeuten. Objekte können auch auf Lese-, Schreib- und Löschaktionen getestet werden. Eine Kombination aus automatisierten Tests und manuellen Penetrationstests kann dazu beitragen, BOLA-Fehler aufzudecken.

Leider schützen herkömmliche Tools wie API-Gateways und Web Application Firewalls in der Regel nicht vor BOLA-Angriffen. Während API-Gateways gut für die Verwaltung der Authentifizierung geeignet sind, sind sie nicht in der Lage, bösartige Anfragen aufzudecken. In den meisten Fällen verwenden diese Tools Signaturen zur Erkennung und suchen nicht nach unbekannten Fällen.

Gleichzeitig können fehlerhafte Autorisierung-Angriffe auf Objektebene mit nur einer geänderten ID normalen API-Anfragen ähneln. Systeme sind möglicherweise nicht in der Lage, etwas Außergewöhnliches festzustellen, bis Exploits bereits stattgefunden haben.

Security-Teams sollten auf eine große Anzahl fehlgeschlagener API-Anfragen achten, insbesondere auf solche mit Autorisierungsfehlern. Wenn Angreifer nach gültigen Objekt-IDs suchen, ist es nicht ungewöhnlich, erhebliche nicht autorisierte (401), nicht gefundene (404) oder verbotene (403) Fehler sehen. Mehrere Anforderungen für Objekt-IDs von demselben Autorisierungstoken können ebenfalls auf bösartige Aktivitäten hinweisen.

Verhinderung von BOLA-Schwachstellen

OWASP bietet mehrere spezifische Strategien, um BOLA-Schwachstellen zu verhindern, einschließlich:

• Implementierung geeigneter Autorisierungsmechanismen, die auf Benutzerrichtlinien und -hierarchien basieren.
• Randomisierung von Objekt-IDs und Globally Unique Identifiers (GUIDs) für Datensätze.
• Autorisierungsmechanismen, um zu überprüfen, ob angemeldete Benutzer die Berechtigung haben, angeforderte Aktionen für Datensätze auszuführen.
• Aktives Testen zur Bewertung von Autorisierungsmechanismen.

BOLA sind schon seit einiger Zeit ein bekannter Exploit. Vor mehr als einem Jahrzehnt kam es über AT&T zu einem API-Verstoß bei Apple iPads, bei dem die die E-Mails von etwa 100.000 Benutzern, darunter hochrangige Regierungs- und Medienvertreter, offengelegt wurden. Dennoch steht die fehlerhafte Autorisierung auf Objektebene weiterhin ganz oben auf der Liste der API-Security-Bedrohungen.