Zurück zum Blog
29. April 2026

Wie Sie Ihre API-Endpunkte vor BOLA-Angriffen schützen

Sie haben eine schlanke API entwickelt. Sie ist schnell, skalierbar und ermöglicht ein großartiges Benutzererlebnis. Wahrscheinlich haben Sie die Grundlagen abgehakt: Sie haben HTTPS aktiviert, verwenden JWTs oder API-Schlüssel zur Authentifizierung und haben vielleicht sogar einen Schwachstellenscanner ausgeführt. Sie fühlen sich sicher. Doch in der Welt der API-Sicherheit gibt es einen stillen Killer, den herkömmliche Scanner oft übersehen, und er erfordert keinen komplexen Exploit oder eine ausgeklügelte Payload, um zu funktionieren.

Er wird BOLA genannt – Broken Object Level Authorization.

Falls Ihnen der Begriff nicht geläufig ist, BOLA ist im Wesentlichen der "ID-Tausch"-Trick. Stellen Sie sich vor, ein Benutzer meldet sich bei Ihrer App an und sieht sein Profil unter api.example.com/user/12345. Er bemerkt die Nummer am Ende. Aus einer Laune heraus ändert er 12345 in 12346. Wenn Ihr Server die privaten Daten von Benutzer 12346 problemlos zurückgibt, ohne zu prüfen, ob der Anfragende tatsächlich die Berechtigung hat, diese zu sehen, haben Sie eine BOLA-Schwachstelle.

Es klingt einfach – fast zu einfach. Aber diese Einfachheit ist der Grund, warum BOLA konsequent als die Bedrohung Nr. 1 in den OWASP API Security Top 10 eingestuft wird. Warum? Weil es kein Fehler bei der Authentifizierung (wissen, wer der Benutzer ist), sondern ein Fehler bei der Autorisierung (wissen, was der Benutzer tun darf) ist.

Die Absicherung Ihrer API-Endpunkte gegen BOLA-Angriffe geht nicht darum, eine größere Firewall hinzuzufügen; es geht darum, wie Ihre Anwendung den Datenbesitz handhabt. In diesem Leitfaden werden wir genau aufschlüsseln, wie BOLA funktioniert, warum es auftritt und welche konkreten Schritte Sie unternehmen können, um Ihre Endpunkte dauerhaft zu sichern.

Was genau ist BOLA und warum ist es so gefährlich?

Um BOLA zu verstehen, müssen wir zwischen Authentifizierung und Autorisierung unterscheiden. Diese beiden Begriffe werden oft synonym verwendet, aber im Kontext der API-Sicherheit sind sie Welten voneinander entfernt.

Authentifizierung ist der Prozess der Überprüfung der Identität eines Benutzers. "Sind Sie der, für den Sie sich ausgeben?" Wenn ein Benutzer ein Passwort oder einen Token angibt und Ihr System "Ja" sagt, ist er authentifiziert.

Autorisierung ist der Prozess der Überprüfung von Berechtigungen. "Nachdem ich weiß, wer Sie sind, dürfen Sie auf dieses spezifische Datenelement zugreifen?"

BOLA tritt auf, wenn eine Anwendung Zugriff auf ein Objekt (einen Datenbankeintrag, eine Datei, ein Benutzerkonto) basierend auf benutzerdefinierten Eingaben gewährt, aber es versäumt zu überprüfen, ob der authentifizierte Benutzer dieses Objekt tatsächlich besitzt oder darauf zugreifen darf.

Die Anatomie eines BOLA-Angriffs

Ein typischer BOLA-Angriff folgt einem sehr vorhersehbaren Muster:

  1. Beobachtung: Der Angreifer erstellt ein legitimes Konto auf Ihrer Plattform. Er beginnt, die App zu nutzen und bemerkt, dass die API-Anfragen vorhersehbare Identifikatoren (wie ganze Zahlen) in der URL verwenden.
  2. Manipulation: Der Angreifer verwendet ein Proxy-Tool (wie Burp Suite oder Postman), um eine Anfrage abzufangen. Er sieht eine Anfrage wie GET /api/v1/orders/9876.
  3. Iteration: Der Angreifer ändert 9876 in 9875, 9874 und so weiter.
  4. Exfiltration: Wenn der Server die Eigentumsrechte der Bestellung 9875 nicht überprüft, gibt er die Daten zurück. Der Angreifer schreibt dann ein einfaches Skript, um Tausende von IDs zu durchlaufen und Ihre gesamte Datenbank innerhalb von Minuten zu scrapen.

Warum herkömmliche Sicherheitstools BOLA nicht erkennen

Wenn Sie eine Standard-Web Application Firewall (WAF) oder einen einfachen Schwachstellenscanner verwenden, fragen Sie sich vielleicht, warum diese Sie nicht davor gewarnt haben.

Das Problem ist, dass BOLA-Angriffe wie vollkommen legaler Traffic aussehen. Für eine WAF sieht eine Anfrage an /api/v1/orders/9875 identisch aus wie eine Anfrage an /api/v1/orders/9876. Beide sind gültige HTTP GET-Anfragen. Beide verfügen über ein gültiges Authentifizierungstoken. Der „Angriff“ findet in der Geschäftslogik Ihres Codes statt, nicht in der Formatierung der Anfrage.

Hier wird die Lücke zwischen „Scannen“ und „Testen“ deutlich. Ein Scanner sucht nach bekannten Signaturen (wie SQL Injection-Strings); ein Penetration Test sucht nach Logikfehlern. Aus diesem Grund bewegen sich Teams in Richtung Continuous Threat Exposure Management (CTEM) und nutzen Plattformen wie Penetrify. Sie benötigen ein System, das den Kontext Ihrer API-Aufrufe versteht, nicht nur, ob die Anfrage „wohlgeformt“ ist.

Häufige Szenarien, in denen BOLA unbemerkt eindringt

BOLA ist nicht auf nur einen Endpunkttyp beschränkt. Es taucht häufig überall dort auf, wo eine eindeutige ID zum Abrufen von Daten verwendet wird. Hier sind einige der häufigsten Verstecke.

Benutzerprofile und Kontoeinstellungen

Dies ist das klassische Beispiel. Endpunkte wie /api/users/{userId}/settings oder /api/me/profile sind Hauptziele. Wenn das Backend die {userId} einfach aus der URL übernimmt und die Datenbank abfragt, ohne zu prüfen, ob current_user.id == requested_userId, kann jeder eingeloggte Benutzer die Einstellungen jedes anderen Benutzers anzeigen oder bearbeiten.

E-Commerce und Bestellhistorie

Stellen Sie sich eine Seite „Meine Bestellungen“ vor. Die API könnte /api/orders/{orderId} aufrufen. Ein Angreifer kann die orderId einfach inkrementieren, um die Käufe, Adressen und Telefonnummern anderer Personen einzusehen. Dies ist eine Goldgrube für Identitätsdiebe.

SaaS-Mandantenisolation

Für Unternehmen, die Multi-Tenant-SaaS-Anwendungen entwickeln, kann BOLA katastrophal sein. Wenn Sie eine Struktur wie /api/tenant/{tenantId}/projects haben und ein Benutzer von Mandant A auf Projekte von Mandant B zugreifen kann, indem er einfach die tenantId ändert, haben Sie eine massive Datenpanne. Dies ist nicht nur ein Fehler; es ist ein grundlegendes Versagen der Mandantenisolation.

Datei-Uploads und -Downloads

Viele Anwendungen speichern Dateien (Rechnungen, IDs, Fotos) und stellen sie über Endpunkte wie /api/files/download?fileId=5542 bereit. Wenn das System nicht prüft, ob der Benutzer die Berechtigung zum Zugriff auf fileId 5542 hat, kann ein Angreifer jedes auf Ihre Plattform hochgeladene Dokument abgreifen.

Schritt-für-Schritt-Anleitung zur Implementierung von BOLA-Abwehrmaßnahmen

Wie stoppen Sie das also tatsächlich? Es erfordert einen mehrschichtigen Ansatz. Sie können sich nicht auf eine einzige „Patentlösung“ verlassen. Stattdessen müssen Sie die Autorisierung in das Grundgerüst Ihres API-Designs integrieren.

1. Implementieren Sie strenge Autorisierungsprüfungen auf Objektebene

Der direkteste Weg, BOLA zu stoppen, ist die Überprüfung der Eigentumsrechte bei jeder einzelnen Anfrage, die auf eine Ressource zugreift.

Der falsche Weg (Pseudocode):

app.get('/api/orders/:orderId', async (req, res) => {
  const order = await db.Orders.findOne({ id: req.params.orderId });
  res.json(order); 
  // GEFAHR: Es wird nicht geprüft, ob die Bestellung dem Benutzer gehört!
});

Der richtige Weg (Pseudocode):

app.get('/api/orders/:orderId', async (req, res) => {
  const userId = req.user.id; // Get ID from the authenticated JWT
  const orderId = req.params.orderId;

  const order = await db.Orders.findOne({ 
    where: { 
      id: orderId, 
      userId: userId // MUST filter by the owner's ID
    } 
  });

  if (!order) {
    return res.status(404).send('Order not found'); 
    // Use 404 instead of 403 to avoid leaking that the ID exists
  }
  res.json(order);
});

Indem Sie die userId direkt in die Datenbankabfrage aufnehmen, stellen Sie sicher, dass die Datenbank den Datensatz nur zurückgibt, wenn er der anfragenden Person gehört. Wenn die ID existiert, aber nicht dem Benutzer gehört, gibt die Abfrage null zurück, und Sie senden einen 404-Fehler.

2. Ersetzen Sie vorhersagbare IDs durch UUIDs

Die Verwendung von fortlaufenden Ganzzahlen (1, 2, 3...) für Ihre Primärschlüssel ist ein Geschenk für Angreifer. Sie macht "ID-Walking" oder "Enumeration" trivial.

Während die Verwendung von UUIDs (Universally Unique Identifiers) den zugrunde liegenden Autorisierungsfehler nicht behebt, macht sie es für einen Angreifer nahezu unmöglich, eine gültige ID zu erraten.

  • Sequenzielle ID: 1001 $\rightarrow$ nächste ist 1002.
  • UUID: 550e8400-e29b-41d4-a716-446655440000.

Die Umstellung auf UUIDs erhöht die "Kosten" des Angriffs. Ein Angreifer kann nicht einfach eine for-Schleife von 1 bis 10.000 schreiben. Sie müssten zuerst irgendwie eine gültige UUID finden. Denken Sie jedoch daran: UUIDs sind Verschleierung, keine Sicherheit. Wenn ein Angreifer eine UUID in einem geleakten Log oder einer anderen API-Antwort findet, können sie immer noch eine BOLA-Schwachstelle ausnutzen, wenn Ihre Autorisierungsprüfungen fehlen.

3. Verwenden Sie eine zentralisierte Autorisierungs-Middleware

Die Autorisierungslogik in jedem einzelnen Controller zu schreiben, ist ein Rezept für eine Katastrophe. Sie werden einen vergessen. Sie werden einen Grenzfall übersehen.

Verschieben Sie stattdessen Ihre Autorisierungslogik in eine Middleware oder einen dedizierten Dienst. Dies gewährleistet eine konsistente Richtlinie über die gesamte API hinweg. Sie können ein richtlinienbasiertes Zugriffssteuerungssystem implementieren, in dem Sie definieren, wer welche Aktion auf welcher Ressource ausführen darf.

Zum Beispiel könnte eine Middleware prüfen: canUserAccessResource(user, resourceType, resourceId, action)

Wenn Sie in einer komplexen Umgebung mit mehreren Cloud-Anbietern (AWS, Azure, GCP) arbeiten, kann die Verwaltung dieser Berechtigungen unübersichtlich werden. Hier wird die automatisierte Sicherheitsorchestrierung entscheidend. Tools wie Penetrify helfen Ihnen, Ihre Angriffsfläche abzubilden und diese Arten von "ID-Swap"-Angriffen in Ihren Umgebungen zu simulieren, um die Lücken zu finden, die Ihre Entwickler möglicherweise übersehen haben.

4. Implementieren Sie Ratenbegrenzung und Anomalieerkennung

Ein BOLA-Angriff umfasst in der Regel ein hohes Volumen an Anfragen in einem kurzen Zeitfenster, während der Angreifer versucht, Daten abzugreifen. Während die Ratenbegrenzung eine einzelne gezielte BOLA-Anfrage nicht stoppt, wird sie einen Versuch der Massendatenexfiltration stoppen.

  • Ratenbegrenzungen pro Benutzer: Begrenzen Sie die Anzahl der Anfragen, die ein einzelner authentifizierter Benutzer an sensible Endpunkte stellen kann.
  • 404-Überwachung: Wenn ein einzelner Benutzer innerhalb einer Minute 500 "Not Found"-Fehler an einem Endpunkt wie /api/orders/{id} auslöst, suchen sie mit ziemlicher Sicherheit nach gültigen IDs. Lösen Sie einen Alarm aus oder sperren Sie die IP/das Konto vorübergehend.

BOLA in verschiedenen API-Architekturen: GraphQL und REST

Die Art und Weise, wie Sie BOLA bekämpfen, hängt leicht von der Struktur Ihrer API ab.

BOLA in REST-APIs

Bei REST tritt BOLA normalerweise im URL-Pfad auf (wie wir besprochen haben). Die Lösung ist einfach: Validieren Sie immer, dass die aus der Session/dem Token extrahierte userId eine Beziehung zur resourceId in der URL hat.

BOLA in GraphQL

GraphQL ist etwas kniffliger, da es einen einzigen Endpunkt (normalerweise /graphql) und eine Abfragesprache verwendet. Angreifer ändern nicht die URL; sie ändern die Argumente innerhalb der Abfrage.

Beispiel einer GraphQL-Abfrage:

query {
  user(id: "12345") {
    email
    phoneNumber
    creditCardLastFour
  }
}

Ein Angreifer ändert einfach das id-Argument. Da GraphQL oft "Verschachtelung" (das Abrufen eines Benutzers, dann seiner Bestellungen, dann der Versanddetails dieser Bestellungen) beinhaltet, kann eine einzige BOLA-Schwachstelle in einem Resolver zu einer massiven Kaskade von Datenlecks führen.

Die Lösung für GraphQL: Die Autorisierung muss auf Resolver-Ebene erfolgen. Jeder Resolver, der ein Objekt aus der Datenbank abruft, muss dieselbe Eigentumsprüfung durchführen, die wir für REST APIs besprochen haben. Gehen Sie nicht davon aus, dass, nur weil die Top-Level-Abfrage autorisiert wurde, dies auch für die verschachtelten Objekte gilt.

Vergleich von manuellem Penetration Testing und automatisierter BOLA-Erkennung

Wenn BOLA so gefährlich ist, warum nicht einfach einmal im Jahr ein Penetration Testing-Unternehmen beauftragen? Hier ist die Realität des "Einmal-im-Jahr"-Modells.

Merkmal Traditionelles manuelles Penetration Testing Kontinuierliches automatisiertes Testing (z.B. Penetrify)
Häufigkeit Jährlich oder halbjährlich On-Demand / Kontinuierlich
Kosten Hoch (Gebühren von Boutique-Firmen) Abonnement-basiert / Skalierbar
Abdeckung Tiefgreifend, aber Momentaufnahme Breit und entwickelt sich mit Codeänderungen
Feedback-Schleife Wochen nach dem Test Echtzeit oder nahezu Echtzeit
CI/CD-Integration Keine (Manuelle Übergabe) DevSecOps-integriert

Manuelle Tester sind hervorragend darin, komplexe Logikfehler zu finden, aber sie können nicht jedes Mal dabei sein, wenn Ihre Entwickler einen neuen Commit in die Produktion pushen. Wenn ein Entwickler am Dienstag einen neuen /api/v1/user-preferences-Endpunkt hinzufügt und Ihr letztes Penetration Testing im Januar war, ist dieser Endpunkt bis zum nächsten Januar ein offenes Tor für BOLA.

Deshalb befürworten wir Penetration Testing as a Service (PTaaS). Durch die Automatisierung der Aufklärungs- und Scanphasen können Sie sich in Richtung Continuous Threat Exposure Management (CTEM) bewegen. Sie scannen nicht nur nach "Bugs"; Sie simulieren das Verhalten eines Angreifers, der versucht, Objekt-IDs zu manipulieren.

Fortgeschrittene Strategien für Hochsicherheitsumgebungen

Für diejenigen unter Ihnen, die hochsensible Daten (Krankenakten, Finanztransaktionen, Regierungsdaten) verwalten, ist "gut genug" nicht ausreichend. Sie benötigen eine Defense-in-Depth-Strategie.

1. Indirekte Objektreferenzen verwenden (Karten-basiert)

Wenn Sie dem Client absolut keine Version einer Datenbank-ID anvertrauen können, verwenden Sie eine sitzungsspezifische Karte.

Anstatt order_id: 9876 dem Benutzer preiszugeben, generiert Ihr Server einen zufälligen temporären Schlüssel für diese Sitzung:

  • TemporaryKey_A $\rightarrow$ order_id: 9876
  • TemporaryKey_B $\rightarrow$ order_id: 9877

Der Client sieht immer nur TemporaryKey_A. Wenn er versucht, TemporaryKey_C zu erraten, existiert dieser nicht in seiner Session-Map, und die Anfrage schlägt fehl. Dies eliminiert vollständig die Vorhersagbarkeit der ID.

2. Attributbasierte Zugriffskontrolle (ABAC)

Wenn Ihre Organisation wächst, wird die Rollenbasierte Zugriffskontrolle (RBAC) wie "Admin" oder "Benutzer" zu grob. Sie benötigen ABAC.

ABAC ermöglicht es Ihnen, Richtlinien basierend auf Attributen zu definieren:

  • Benutzerattribut: ClearanceLevel: Level 2
  • Ressourcenattribut: Sensitivity: Level 2
  • Umgebungsattribut: AccessTime: 9am-5pm

Eine BOLA-Prüfung in einem ABAC-System würde so aussehen: "Kann dieser Benutzer auf dieses Objekt zugreifen, wenn die Abteilung des Benutzers mit der Abteilung des Objekts übereinstimmt UND das Objekt nicht als 'Privat' gekennzeichnet ist?" Dies bietet ein wesentlich granulareres Sicherheitsniveau.

3. Digitale Signaturen für IDs

Einige hochsichere APIs signieren ihre IDs. Wenn der Server eine ID an den Client sendet, fügt er eine kryptografische Signatur (einen HMAC) hinzu. Wenn der Client die ID zurücksendet, überprüft der Server die Signatur. Ändert der Benutzer 123 zu 124, wird die Signatur ungültig, und der Server lehnt die Anfrage sofort ab – noch bevor sie die Datenbank erreicht.

Häufige Fehler beim Versuch, BOLA zu beheben

Selbst erfahrene Entwickler machen diese Fehler. Wenn Sie Ihren Code prüfen, achten Sie auf diese Muster.

Fehler 1: Sich auf das Frontend verlassen, um Schaltflächen auszublenden

"Der Benutzer kann nicht auf die 'Bearbeiten'-Seite zugreifen, weil ich die Schaltfläche in der React-Benutzeroberfläche ausgeblendet habe." Dies ist Sicherheit durch Obskurität. Ein Angreifer verwendet nicht Ihre Benutzeroberfläche; er nutzt ein Terminal oder einen Proxy. Gehen Sie immer davon aus, dass der Angreifer jeden einzelnen API-Endpunkt kennt, den Sie haben.

Fehler 2: Autorisierung nur am Einstiegspunkt prüfen

Entwickler prüfen oft, ob ein Benutzer zu Beginn einer Anfrage angemeldet ist, und gehen dann davon aus, dass alles innerhalb dieser Anfrage sicher ist.

  • Schlecht: if (!user.isAuthenticated) return 401; $\rightarrow$ fortfahren, jede ID abzurufen.
  • Gut: if (!user.isAuthenticated) return 401; $\rightarrow$ if (!user.owns(resourceId)) return 404;.

Fehler 3: Gültige IDs in anderen Endpunkten preisgeben

Sie haben BOLA möglicherweise an Ihrem /api/orders-Endpunkt behoben, aber haben Sie einen /api/search/users-Endpunkt, der eine Liste aller Benutzer-IDs zurückgibt? Wenn ja, haben Sie dem Angreifer gerade die Karte gegeben, die er benötigt, um Ihre anderen Endpunkte anzugreifen. Minimieren Sie immer die Menge an ID-Daten, die Sie in "Listen"- oder "Such"-Ansichten preisgeben.

Fehler 4: 403 Forbidden anstelle von 404 Not Found verwenden

Wenn ein Benutzer ein Objekt anfordert, das ihm nicht gehört, teilt die Rückgabe von 403 Forbidden dem Angreifer mit: "Dieses Objekt existiert, aber Sie dürfen es nicht sehen." Durch die Rückgabe von 404 Not Found sagen Sie dem Angreifer: "Ich habe keine Ahnung, wovon Sie sprechen." Dies verhindert, dass der Angreifer bestätigen kann, ob eine bestimmte ID gültig ist oder nicht.

Die "BOLA-Audit"-Checkliste für Ihr Team

Wenn Sie ein DevOps- oder Sicherheitsteam leiten, können Sie diese Checkliste während Ihres nächsten Sprint-Reviews oder Sicherheitsaudits verwenden.

  • Inventar: Haben wir eine vollständige Liste aller API-Endpunkte, die eine ID als Parameter akzeptieren?
  • Identität: Extrahieren wir die User ID aus einem sicheren, serverseitigen Token (wie einem JWT), anstatt einer im Anfragetext oder in der URL gesendeten User ID zu vertrauen?
  • Eigentum: Enthält jede Datenbankabfrage für eine bestimmte Ressource einen Filter für die zugehörige User ID oder Tenant ID?
  • Vorhersehbarkeit: Verwenden wir UUIDs oder andere nicht-sequentielle Identifikatoren für öffentlich zugängliche Ressourcen?
  • Konsistenz: Wird die Autorisierung in einer zentralisierten Middleware oder einem Dienst gehandhabt, anstatt in jedem Controller dupliziert zu werden?
  • Fehlerbehandlung: Geben wir 404er anstelle von 403ern für unautorisierten Objektzugriff zurück?
  • Ratenbegrenzung: Haben wir Warnmeldungen für Benutzer, die eine ungewöhnliche Anzahl von 404ern an Ressourcen-Endpunkten auslösen?
  • Testen: Führen wir automatisierte „ID-Swap“-Tests als Teil unserer CI/CD-Pipeline durch?

Wie Penetrify die BOLA-Erkennung vereinfacht

Das manuelle Auffinden von BOLA-Schwachstellen ist mühsam. Sie müssen jeden Endpunkt abbilden, mehrere Benutzerkonten erstellen und jede Kombination von IDs manuell testen. Für ein kleines Team ist dies eine unmögliche Aufgabe. Für ein großes Team ist es ein Engpass.

Genau aus diesem Grund wurde Penetrify entwickelt. Anstatt sich auf einen statischen Scan zu verlassen, der nach „veralteten Bibliotheken“ sucht, konzentriert sich Penetrify auf die Angriffsfläche.

So hilft es Ihnen, das BOLA-Problem zu lösen:

  1. Automatisiertes Angriffsflächen-Mapping: Penetrify identifiziert alle Ihre exponierten Endpunkte, einschließlich derer, die Ihre Entwickler möglicherweise vergessen haben zu dokumentieren.
  2. Intelligente Logiksimulation: Die Plattform sendet nicht nur zufällige Zeichenketten; sie analysiert, wie Ihre IDs strukturiert sind, und versucht, das „ID-Walking“-Verhalten zu simulieren, das manuelle Penetration Tester verwenden.
  3. Kontinuierliche Überwachung: Da es cloud-nativ ist, kann Penetrify in Ihren DevSecOps-Workflow integriert werden. Jedes Mal, wenn Sie eine neue Version Ihrer API bereitstellen, bewertet es Ihren Sicherheitsperimeter neu.
  4. Umsetzbare Behebung: Sie erhalten nicht nur einen Bericht mit der Aussage „Sie haben einen BOLA-Bug.“ Sie erhalten spezifische Anleitungen, welcher Endpunkt anfällig ist und wie die Autorisierungsprüfung implementiert werden kann, um ihn zu beheben.

Indem Penetrify die Lücke zwischen einem einfachen Schwachstellenscanner und einem teuren manuellen Audit schließt, ermöglicht es KMU und SaaS-Startups, ihre Sicherheitsreife (für SOC 2- oder HIPAA-Compliance) nachzuweisen, ohne ein vollständiges internes Red Team zu benötigen.

Häufig gestellte Fragen (FAQ)

F: Kann ich nicht einfach eine WAF verwenden, um BOLA zu stoppen?

Nicht effektiv. Wie erwähnt, verwenden BOLA-Angriffe gültige Syntax und gültige Authentifizierung. Eine WAF betrachtet die Struktur der Anfrage, während BOLA ein Versagen der Geschäftslogik ist. Während eine WAF bei der Ratenbegrenzung helfen kann, um einen Angreifer zu verlangsamen, kann sie nicht feststellen, ob Benutzer A Zugriff auf Bestellung B haben sollte.

F: Verhindert die Verwendung von JWTs (JSON Web Tokens) BOLA?

Nein. JWTs handhaben die Authentifizierung (den Nachweis, wer der Benutzer ist). Sie handhaben nicht die Autorisierung (worauf der Benutzer zugreifen kann). Ein Benutzer kann ein perfekt gültiges, signiertes JWT besitzen und es trotzdem verwenden, um ein Objekt anzufordern, das ihm nicht gehört, wenn Ihr Backend die Eigentumsprüfung nicht durchführt.

F: Bin ich immer noch gefährdet, wenn ich eine NoSQL-Datenbank wie MongoDB verwende?

Ja. BOLA ist unabhängig vom Datenbanktyp. Ob Sie MongoDB _id (die von Natur aus komplexer sind als Ganzzahlen) oder eine PostgreSQL-Sequenz verwenden, die Schwachstelle besteht, wenn die Anwendung einem Benutzer erlaubt, einen Datensatz über eine ID anzufordern, ohne die Eigentümerschaft zu überprüfen.

F: Ist BOLA dasselbe wie IDOR?

Im Wesentlichen ja. IDOR (Insecure Direct Object Reference) ist der ältere, umfassendere Begriff. BOLA ist die moderne Terminologie, die speziell auf APIs zugeschnitten ist. Im Kontext einer API ist ein BOLA-Angriff eine Form von IDOR.

F: Wie teste ich auf BOLA, ohne ein teures Tool zu kaufen?

Sie können damit beginnen, einen Proxy wie Burp Suite (Community Edition) zu verwenden. Erstellen Sie zwei separate Benutzerkonten. Melden Sie sich als Benutzer A an, erfassen Sie eine Anfrage für eine Ressource, die Ihnen gehört, und ersetzen Sie dann die Ressourcen-ID durch eine ID, die Benutzer B gehört. Wenn Sie die Daten von Benutzer B sehen können, während Sie als Benutzer A angemeldet sind, liegt eine BOLA-Schwachstelle vor.

Abschließende Gedanken: Über die Point-in-Time-Sicherheit hinausgehen

Der größte Fehler, den ein Unternehmen in der API-Sicherheit machen kann, ist der Glaube, dass ein einziger „sauberer“ Penetration Test-Bericht bedeutet, dass es sicher ist. Sicherheit ist kein Ziel; sie ist ein Zustand ständiger Wartung.

Ihr Code ändert sich täglich. Ihre Infrastruktur skaliert. Neue Endpunkte werden hinzugefügt, um eine Kundenanfrage zu erfüllen. Jede einzelne dieser Änderungen ist eine Gelegenheit für eine BOLA-Schwachstelle, unbemerkt zu bleiben.

Der Übergang von „einmal jährlichen Audits“ zu „Continuous Threat Exposure Management“ ist der einzige Weg, modernen Angreifern einen Schritt voraus zu sein. Durch die Kombination von strenger Autorisierungslogik, nicht-vorhersehbaren IDs und automatisierten Testplattformen wie Penetrify können Sie aufhören, Sicherheit als bloße Checkbox zu behandeln, und beginnen, sie als Kernfunktion Ihres Produkts zu betrachten.

Warten Sie nicht auf eine Datenschutzverletzung, um festzustellen, dass Ihre Autorisierungslogik fehlerhaft ist. Beginnen Sie noch heute mit der Überprüfung Ihrer Endpunkte, implementieren Sie die besprochenen Eigentumsprüfungen und automatisieren Sie Ihre Tests, damit Sie sich auf die Entwicklung Ihres Produkts konzentrieren können, anstatt sich um den nächsten „ID-Swap“-Angriff zu sorgen.

Bereit zu sehen, ob Ihre APIs tatsächlich sicher sind? Hören Sie auf zu raten und beginnen Sie mit dem Testen. Besuchen Sie Penetrify, um zu erfahren, wie automatisierte, bedarfsgerechte Sicherheitstests Ihre Daten und Ihren Ruf schützen können.

Zurück zum Blog