API-spezifische Angriffe – OWASP API Top 10
Wir haben die Transportschicht mit TLS und mTLS abgesichert, Authentifizierung und Autorisierung implementiert. Aber welche Angriffe zielen speziell auf APIs? Die OWASP API Security Top 10 beschreiben die häufigsten und gefährlichsten API-Schwachstellen. Sie unterscheiden sich deutlich von den klassischen OWASP Top 10 für Webanwendungen, weil APIs andere Angriffsvektoren haben.
„OWASP hatten wir bei den Webanwendungen schon mit SQL-Injection und XSS. Gelten die gleichen Angriffe auch für APIs?“
„Teilweise, aber APIs haben andere Schwerpunkte. Klar, auch Injections können vorkommen, aber die häufigsten Probleme sind andere. Deshalb hat OWASP eine eigene Top-10-Liste nur für APIs erstellt.“
Schauen wir uns die Risiken einmal ganz konkret an:
API1: Broken Object Level Authorization (BOLA)
Das haben wir bereits im Detail behandelt: Die API prüft nicht, ob der Benutzer auf das spezifische Objekt zugreifen darf. Ein Angreifer ändert einfach die ID im API-Aufruf und erhält Daten anderer Benutzer. Der beste Schutz: Bei jedem Zugriff die Berechtigung auf Objektebene prüfen.
API2: Broken Authentication
Das haben wir ebenfalls schon ausführlich behandelt. Schwächen in der Authentifizierung selbst: fehlende Rate Limits auf dem Login-Endpunkt, keine vollständige Token-Validierung, Akzeptieren abgelaufener Tokens, schwache API-Keys.
Effektive Schutzmaßnahmen:
- Token-Validierung streng umsetzen (alle Prüfungen aus den vorherigen Abschnitten)
- Rate Limiting auf Authentifizierungs-Endpunkten
- Kurze Token-Gültigkeitsdauer
API3: Broken Object Property Level Authorization
Damit ist eine spezielle Form der Authorization gemeint, nicht nur ob der Benutzer überhaupt auf das Objekt zugreifen darf. Die API gibt dabei mehr Datenfelder zurück, als der Benutzer sehen darf. Das passiert oft, wenn Entwickler der Einfachheit halber das komplette Datenbankobjekt zurückgeben, statt gezielt nur die erlaubten Felder auszuwählen.
Beispiel: Die Patienten-API von NovaHealth liefert bei einer Abfrage nicht nur Name und Geburtsdatum, sondern auch die interne Versicherungsnummer, die Abrechnungsdaten und das Erstelldatum des Datensatzes. Das sind Informationen, die der anfragende Benutzer eigentlich nicht benötigt und oft auch nicht sehen soll.
Oftmals holt sich die Frontend-Anwendung dann daraus was sie anzeigen soll, daher ist die Schwachstelle für normale Nutzer nicht direkt ersichtlich. Aber ein API-Request, der direkt an die Anwendung geht, erhält eben die gesamten Daten in der Response, nicht nur die, die angezeigt werden sollten. Die nachfolgende Abbildung veranschaulicht diese Situation:
Effektiver Schutz: Explizit definieren, welche Felder in der API-Antwort enthalten sein dürfen. Niemals das komplette Datenbankobjekt zurückgeben.
API4: Unrestricted Resource Consumption
Die API setzt keine Limits für Anfragehäufigkeit, Payload-Größe oder Datenmenge. Ein Angreifer kann den Server überlasten oder durch riesige Payloads Speicher füllen.
Effektive Schutzmaßnahmen:
- Rate Limiting: Maximal N Anfragen pro Zeiteinheit pro Client
- Max Payload Size: Maximale Größe für Request-Bodys begrenzen. Kein Patient hat einen 10.000 Zeichen langen Nachnamen und kein Röntgenbild ist 27 Gigabyte groß.
- Pagination: Große Datenmengen seitenweise ausliefern (z.B. maximal 100 Ergebnisse pro Seite), statt tausende Datensätze auf einmal. Auch hier ist oft der Fehler, dass die Anzeige im Frontend z.B. 2-3 Datensätze anzeigt, aber im Hintergrund der Request die halbe Datenbank zurückgeliefert hat.
API5: Broken Function Level Authorization (BFLA)
Im Unterschied zur Frage, ob der Benutzer die betreffenden Daten abrufen darf, ist hier die Frage: Darf dieser Nutzer diese Funktion überhaupt ausführen? Auch darauf sind wir bereits eingegangen.
Beispiel: Ein normaler Nutzer ruft einen Admin-Endpunkt mit einer kritische Aktion wie DELETE /api/admin/patienten/12345 auf. Hier ist nicht das einzelne Objekt das Problem, sondern dass die Funktion/Aktion für Anfragen ohne Berechtigung verboten sein sollte, auch wenn der Benutzer selbst Patient „12345“ ist und seine Daten sehen dürfte.
Effektiver Schutz wie zuvor auch: Berechtigungsprüfung auf jedem Endpunkt im Backend.
Weitere wichtige Risiken (API6-API10):
- API6 – Server-Side Request Forgery (SSRF): Die API akzeptiert URLs als Eingabe und ruft sie serverseitig ab. Die Anwendung macht also selber Web-Requests. Ein Angreifer kann die API so z.B. dazu bringen, Anfragen an interne Systeme zu senden, die von außen nicht erreichbar sind. Das könnte z.B. der Metadaten-Service einer Cloud-Umgebung sein, der ggf. Infos ausspuckt mit denen der Angreifer weiter in die IT-Infrastruktur eindringen kann.
- API7 – Security Misconfiguration: Dazu gehört z.B. eine fehlende oder zu lockere CORS-Konfiguration – Stichwort: Same-Origin Policy (SOP) des Browsers. Weiterhin: Debug-Modi in Produktion aktiv, unnötige HTTP-Methoden (PUT, DELETE, TRACE) aktiviert, ausführliche Fehlermeldungen mit Stack Traces und internen Pfaden.
- API8 – Lack of Protection from Automated Threats: Kein Schutz vor Bots, die automatisiert Daten abgreifen (Scraping), Konten übernehmen (Credential Stuffing) oder Gutschein-Codes durchprobieren. Schutzmaßnahmen können sein: Rate Limiting, Bot Detection, CAPTCHA oder Challenges, etc.
- API9 – Improper Inventory Management: Alte API-Versionen (z.B.
/api/v1/) bleiben aktiv und erreichbar, obwohl längst eine neuere Version (z.B./api/v3/) im Einsatz ist. Die alten Versionen haben oft weniger Sicherheitsprüfungen und werden vergessen. - API10 – Unsafe Consumption of APIs: Die eigene Anwendung vertraut Antworten von Drittanbieter-APIs blind, ohne die Daten zu validieren. Wenn die Drittanbieter-API kompromittiert wird, übernimmt die eigene Anwendung die manipulierten Daten ungeprüft. Auch Geld kann hier zu eine Rolle spielen, das Thema passt aber auch zu API4: Wenn eine Anwendung im Hintergrund eine weitere kostenpflichtige API konsumiert (z.B. 10 Cent pro Anfrage), sollten die Nutzer nicht uneingeschränkt anfragen senden können.
💡 Die OWASP API Security Top 10 sind eine Pflichtlektüre für jeden, der APIs entwickelt oder absichert. Sie werden einigermaßen regelmäßig aktualisiert und die aktuelle Version (2023) spiegelt, wie bei allen OWASP Top Tens, die Angriffsmuster wider, die in der Praxis am häufigsten ausgenutzt werden.
Mal sehen, ob du die API-spezifischen Angriffe und ihre Gegenmaßnahmen draufhast. Ordne die folgenden Aussagen ein: