OWASP API Top Ten 2023 Ein Blick auf die Top 10 API Security Risks von OWASP

Anbieter zum Thema

Ergon Informatik AG

Pathlock Deutschland GmbH

Die aktuelle OWASP-Liste „Top 10 API Security Risks“, ein Update der Liste von 2019, wirft ein Schlaglicht auf bekannte und neue Risiken. Zugleich verdeutlicht sie, woran Entwickler in puncto API-Sicherheit besonders arbeiten müssen – und sorgt für Diskussionsstoff.

Eine klassische E-Commerce-Applikation funktioniert wie ein Restaurant: Sie stellt die Services in Form der Speisekarte bereit, leitet die Bestellungen an das Backend – die Küche – weiter und liefert den Gästen dann das Gewünschte. Eine moderne Webapplikation hingegen gleicht eher einem Salatbuffet: Der Gast stellt sich selbst alles von Grund auf neu zusammen – pro Zutat eine eigene API. Denn heute teilen sich aufgabenspezifische Apps und Services auf kleinteiligem Weg die Arbeit direkt. Ohne diese Schnittstellen – heute vorrangig Web-APIs – stünde unser Online-Alltag ebenso still wie die Geschäftswelt, zeitweise machte sogar der Begriff „API Economy“ die Runde.

Kommt einer Zutat im digitalen Menü eine derart kritische Rolle zu, zieht dies Angreifer geradezu magisch an. Wie bedrohlich der API-Topf überzukochen droht, zeigt sich schon daran, dass OWASP (Open Web Application Security Project) die bekannte Top-10-Liste kritischer Web-Schwachstellen 2019 um eine separate Aufstellung der zehn größten API-Risiken ergänzte. Kürzlich erhielt die API-Risikoliste ein Update. Dieses gibt interessante Einblicke, welche API-Bedrohungen sich gerade zusammenbrauen.

Zunächst fällt auf: Vier der Top Five API-Risiken betreffen den Bereich Authentifizierung und Autorisierung. Wie schon 2019, so hält auch 2023 „Broken Object Level Authorization“ den Spitzenplatz (API1:2023). Nach ähnlichem Rezept funktionieren API3 („Broken Object Level Property Level Authorization“), API5 („Broken Function Level Authorization“) sowie API2 („Broken Authentication“). Mit API4 („Unrestricted Resource Consumption“) schaffte es lediglich ein Risiko unter die Top 5, dass aufgrund mangelnder limitierender Parameter dem Ressourcenmissbrauch den Weg zur Salatbar öffnet – oder genauer: dass es DoS-Angriffen erlaubt, eben diesen Weg zu blockieren.

Broken Object Level Authorization

Dass Broken Object Level Authorization sich so hartnäckig auf Platz 1 hält, ist leicht nachzuvollziehen: Prüft ein API-Endpunkt nicht, ob ein Nutzer tatsächlich berechtigt ist, auf das angeforderte Objekt zuzugreifen, öffnet dies eine beachtliche Angriffsfläche. Ein Angreifer kann Zugang zu internen Daten erhalten, bis hin zu Geschäftsgeheimnissen oder – angesichts der DSGVO-Rechtslage ähnlich kritisch – personenbezogenen Daten, um sie zu exfiltrieren, zu modifizieren oder zu löschen. Der Ablauf ähnelt damit legitimem Datenverkehr. Netzwerkbasierte Abwehrtools schlagen deshalb oft erst an, wenn der Angreifer Interna exfiltriert – oder schlimmstenfalls bereits exfiltriert hat: Die Kontrolle greift erst nach erfolgter digitaler Zechprellerei, also viel zu spät.

API3:2023 („Broken Object Level Property Level Authorization“) wiederum aggregiert zwei Punkte der vorherigen Liste: API3:2019 („Excessive Data Exposure“) und API6:2019 („Mass Assignment“). Denn OWASP richtet nun den Blick auf deren gemeinsame Ursache: Mängel im Vorgehen, die Autorisierung auf der Ebene der Objekteigenschaften zu validieren. Auch dies ebnet Unberechtigten den Weg, sensible Daten einzusehen und zu manipulieren.

Von der API zum Geschäftsrisiko

Eine tatsächliche – und sehr spannende – Neuerung in der Top-Ten-Liste stellt hingegen API6:2023 dar: „Unrestricted Access to Sensitive Business Flows“. Denn hier entfernt sich OWASP von der reinen Technik und springt direkt auf die Ebene der Geschäftsrisiken. Der Hintergrund: Manch ein Programmier- oder Konfigurationsfehler von API-Endpunkten verschafft Dritten Einblick in die Geschäftslogik, die eigentlich hinter der API verborgen bleiben sollte – und dies bringt böswillige Dritte auf den Geschmack, die Lücke für lukrative Zwecke zu missbrauchen.

Der OWASP-Report nennt drei anschauliche Beispiele für dieses Risiko, darunter das folgende: Eine Fluggesellschaft bietet den Online-Kauf von Tickets ohne Stornogebühren an. Ein böswilliger Nutzer bucht 90 Prozent der Plätze für einen gewünschten Flug. Einige Tage vor dem Flug storniert er alle Tickets auf einmal, sodass die Airline die Ticketpreise senken muss, um das Flugzeug zu füllen. Nun erwirbt der Nutzer ein einziges Ticket – erheblich billiger als das ursprüngliche.

Bedenkliches Fehlen des Injection-Risikos

Während geschäftsbezogene Risiken neu hinzugestoßen sind, fällt gegenüber der API-Top-Ten-Liste von 2019 eine bedenkliche Auslassung auf: Die Risikoliste von 2019 räumte den diversen Spielarten von Injection-Angriffen (SQL-, NoSQL-, Command-Injection etc.) einen Listenpunkt ein (API8:2019). Dieser Punkt ist nun unter den Tisch gefallen. Denn OWASP stuft Injections als generelles Problem von (Web-)Applikationen ein. Dies hat auf GitHub zu lebhaften Diskussionen geführt.

Die Auslassung ist nicht stimmig, und zwar aus zwei Gründen: Erstens stellen Injections auch bei modernen Web-Applikationen, die APIs nutzen, eines der Hauptrisiken dar. Heutzutage gibt es APIs, hinter denen keine Web-Applikation steht, sondern direkt eine Backend-Applikation. Hier besteht, ähnlich wie bei Web-Anwendungen, ein Injection-Risiko, nur eben nicht XSS oder Ähnliches. Es ist also nach wie vor zwingend erforderlich, Vorkehrungen gegen API-Injections zu treffen.

Zweitens könnte man vom neu eingeführten Listenpunkt API6:2023 „Unrestricted Access to Sensitive Business Flows“ mit mindestens dem gleichen Recht behaupten, es betreffe die Applikationsseite. Die Auslassung ist somit nicht nachvollziehbar. Vor allem aber ist sie bedenklich, weil Entwicklungsteams dadurch APIs möglicherweise weniger intensiv auf Injections untersuchen und dieses brisante Thema damit in der Entwicklung nicht die Aufmerksamkeit erhält, die es verdient.

Server-Side Request Forgery

In der aktuellen Fassung errang lediglich eine einzelne Angriffsvariante ihren eigenen Platz auf dem Top-Ten-Treppchen, da sie laut OWASP ebenso verbreitet wie leicht umzusetzen ist: Server-Side Request Forgery (SSRF). SSRF kann auftreten, wenn eine API eine Ressource abruft, ohne die vom Benutzer angegebene URL zu validieren. So kann ein Angreifer die Anwendung zwingen, eine manipulierte Anfrage an das von ihm gewünschte Ziel zu senden, selbst wenn das Ziel hinter einer Firewall sitzt und von außen gar nicht erreichbar sein sollte.

Sehr brisant ist die Angriffsart laut OWASP, weil Web-Services, Kubernetes und Docker ihre Verwaltungs- und Kontrollkanäle über HTTP auf bekannten oder vorhersehbaren Pfaden bereitstellen. Damit sind sie für SSRF-Angriffe ein gefundenes Fressen.

Dies erinnert an einen brisanten Vorfall vom vorletzten Jahr: Ende 2021 sorgte die Log4Shell genannte Zero-Day-Sicherheitslücke in Log4j für großes Aufsehen. Log4Shell selbst ist zwar keine SSRF-Schwachstelle, lässt sich aber für SSRF verwenden.

Neben dem erwähnten Fehler, den Ressourcenverbrauch nicht durch Richtlinien zu begrenzen (API4:2023), umfasst die aktuelle API-Risikoaufstellung eine weitere, ähnlich gelagerte Gruppe von Konfigurationsfehlern, die OWASP schlicht „Security Misconfiguration“ (API8:2023) nennt. Dieser Punkt wirft diverse Sicherheitsmängel in einen Topf, von mangelnder Sicherheitshärtung des API-Stacks über veraltete Security-Patches und fehlende Transport Layer Security (TLS) bis hin zu mangelhaften CORS-Richtlinien (Cross-Origin Resource Sharing), ebenso Fehlermeldungen, die Stack Traces enthalten oder sensible Informationen preisgeben.

API9:2023 („Improper Inventory Management“) schließlich ergänzt dies um ein buntes Allerlei an Risiken aufgrund mangelhafter Inventarisierung und Dokumentation. Denn der API-Wildwuchs, dem man heute allzu oft begegnet, führt schnell zu Inkonsistenzen im API-Bestand sowie zu veralteter Dokumentation. Das Spektrum der Einfallstore reicht hier von unklar definierten APIs über das Fehlen eines klaren Konzepts, wann eine API wieder außer Betrieb zu nehmen ist, bis zum lückenhaften Überblick über sensible Datenströme und Datentypen.

Kurz: Die zunehmend granulare Arbeitsteilung zwischen Web-APIs hat eine Fülle brisanter Sicherheitsrisiken geschaffen. Teils erfordern die damit verbundenen Sicherheitslücken nur wenig Fachkenntnisse seitens der Angreifer, teils lassen sich Lücken automatisiert ausnutzen. Diese Lücken beruhen oft auf gefährlichen Default-Einstellungen oder auf Schritten, die bei der Konfiguration schlicht vergessen wurden. Und so fällt ein Missbrauch ohne Vorkehrungen zum Schutz der APIs oft erst auf, wenn die Milch schon verschüttet ist.

OWASP Top 10 API Security Risks – 2023 in der Übersicht

OWASP Top 10 API Security Risks (Quelle: OWASP 2023).

APIs umfassend schützen

Die aktuelle OWASP-Liste der größten API-Risiken veranschaulicht: Die Mittel und Wege, das arbeitsteilige, an sich gut geölte Ineinandergreifen der APIs zu attackieren, sind wirkungsvoll und vielfältig. Ebenso arbeitsteilig wie das Zusammenspiel der Applikationen und Services muss auch der Schutz der APIs organisiert sein.

Das erste Bollwerk gegen den API-Missbrauch bildet das Identity and Access Management (IAM). IAM-Systeme stellen mittels Standards wie OAuth, OpenID Connect oder SAML schon im Vorfeld sicher, dass der Nutzer auch der ist, der er vorgibt zu sein, und vergeben wohldosiert Berechtigungen für den Zugriff auf Applikationen und APIs. So vermeiden sie Authentifizierungsmängel (API2:2023).

Damit ist allerdings erst eines der Top Ten API-Risiken abgedeckt – und die anfragende Instanz eines API-Calls ist bei Weitem nicht immer ein menschlicher Nutzer. Zahlreiche API-Calls erfolgen schließlich zwischen beteiligten Services. Als weitere wichtige Zutat kommt deshalb Web Application and API Protection (WAAP) hinzu. WAAP beinhaltet unter anderem eine Web Application Firewall (WAF) sowie ein API-Gateway.

Verschmelzen der Produktgattungen

Ursprünglich waren Web-Applikation-Security und API-Security zwei separate Produktgattungen. Weil aber immer mehr Web-Applikationen APIs nutzen, muss eine moderne Web-Application-Sicherheitslösung auch API-Schutz umfassen – die beiden Themen lassen sich aus Security-Anbietersicht nicht mehr separat betrachten. Diesen Trend bestätigte das Analystenhaus Gartner 2019, indem es beide Bereiche zu „Web Application and API Protection“ (WAAP) verschmolz. Inzwischen hat sich WAAP als Produktgattung für applikationsbezogene Schutzmechanismen etabliert. WAAP-Lösungen umfassen eine WAF wie auch ein API-Security-Gateway, zudem Funktionen zum Schutz vor DoS-Angriffen und zur Abwehr bösartiger Bots.

Eine WAF bietet eine Reihe von Schutzmechanismen gegen Angriffe auf (Web-) Applikationsebene wie Injections, XSS oder SSRF, zudem unterstützt sie TLS-Datenverkehr (API7:2023, API8:2023). Das API-Gateway wiederum bietet Funktionen zur Durchsetzung der API-Spezifikationen und zur Begrenzung des API-Datenverkehrs. Im Kontext von Microservices, Kubernetes und Service-Meshes wird es auch Microgateway genannt. Ein solches Microgateway dient, anders als die klassische WAF, nicht dem Perimeterschutz sämtlicher Anwendungen, sondern dem maßgeschneiderten Schutz einzelner APIs und Applikationen im dezentralisierten Umfeld von Containern.

Während also OWASP im Jahr 2019 zwei verschiedene Top-Ten-Listen für Web-Applikations- und API-Risiken auf den Weg gebracht hat, führte der Weg auf Seiten der Security-Anbieter exakt in die Gegenrichtung. Angesichts der oben erwähnten Inkonsistenzen zwischen den beiden Top-Ten-Listen (Stichwort: Injection-Risiken) stellt sich damit die Frage, ob im Zeitalter moderner Single-Page-Anwendungen (SPAs) eine getrennte Betrachtung von OWASP Top 10 und OWASP API Top 10 überhaupt noch Sinn ergibt. Überlappungen wie jene beim Thema Injection-Risiken sprechen eher für eine gemeinsame Top-Ten-Liste der WAAP-Risiken.

Schutz vor Fehlkonfigurationen

Der Sammelbegriff „Security Misconfiguration“ (API8:2023) ist dabei naturbedingt ein weites Feld. Eine gute WAAP-Lösung hilft hier aber mit „Security by Default”-Konzepten. Ein Beispiel dafür wäre das Setzen einer sicheren CORS Policy respektive das Entfernen einer zu offenen Policy wie „Access-Control-Allow-Origin“.

Die Angriffsvektoren, die sich aus dem Missbrauch API-gestützter Geschäftsprozesse ergeben (API6:2023), lassen sich auf rein technischer Ebene nur relativ schwer in den Griff bekommen. Laut OWASP zielt dieser Punkt jedoch auf Angriffe ab, die derlei Schwächen auf automatisierte Weise ausnutzen. Solchen Angriffsautomatismen können WAAP-Lösungen mit Rate Limiting, Abwehr bösartiger Bots und Machine-Learning-basierter Analyse des Datenverkehrs begegnen.

REST und GraphQL

In puncto WAAP-Lösung sollten DevOps-Teams einen wichtigen Punkt nicht aus dem Auge verlieren: Im Kontext der API-Kommunikation ist oft von REST die Rede, es gibt aber durchaus noch andere Abfragesprachen, darunter GraphQL. Gerade GraphQL nutzen Angreifer gerne für API-Missbrauch, da diese Sprache deutlich komplexere Abfragen erlaubt als das vergleichsweise schlichte REST. Zum Beispiel könnte eine bösartige GraphQL-Abfrage einen Denial-of-Service-Angriff ermöglichen, der das Rate Limiting als Abwehrmechanismus aushebelt. Mit GraphQL Introspection Calls wiederum kann der Angreifer das gesamte Datenschema auf einmal auslesen. Man sollte also darauf achten, dass die WAAP-Lösung GraphQL unterstützt – und natürlich sollte man Introspection nach Möglichkeit deaktivieren, wenn sie nicht zwingend erforderlich ist.

Der Türsteher hat dabei nach wie vor seine Berechtigung: Was man bereits mit klassischem Perimeterschutz vom Unternehmensnetzwerk fernhalten kann, sollte man gar nicht erst hereinlassen. Daher sind WAAP-Lösungen am Perimeter weiterhin sinnvoll. Ein klassischer Perimeterschutz allein reicht aber nicht mehr aus. Eine wirksame Abwehr erfordert deshalb eine Zero-Trust-Architektur anstelle des althergebrachten „Wer drin ist, dem wird vertraut“. Hier können unter anderem Microgateways nützlich sein, um API-spezifische Validierungen durchzuführen.

Elementare Rolle der Entwicklungsteams

Die wichtigste Rolle bei der Arbeitsteilung zum API-Schutz aber fällt nach wie vor den Entwicklern zu. Denn Security-Lösungen – ob IAM, WAAP oder andere – können immer nur ein beschränktes Spektrum an Sicherheitsproblemen lösen. Ergänzend notwendig ist daher Security by Design, um die Probleme möglichst gar nicht erst entstehen zu lassen. Gefragt sind hier Entwicklungsteams, die gründlich und mit Verstand arbeiten – idealerweise unterstützt durch Werkzeuge, die Code automatisiert auf Sicherheitslücken und Konfigurationen auf Fehler prüfen (API8:2023). Denn es ist in unserer komplexen und schnelllebigen API-Welt letztlich ein aussichtsloses Unterfangen, Lücken und Fehlkonfigurationen immer erst dann zu bekämpfen, wenn der Topf kurz vor dem Überkochen steht.

Zum Technik- kommt das Geschäftsrisiko (API6:2023): Beim erwähnten Kauf eines herabgesetzten Flugtickets, ermöglicht durch die Buchung zahlreicher Tickets auf Basis eines API-Missbrauchs, handelt es sich im Prinzip um ein Rate-Limiting-Problem, aber nicht auf der Ebene des Netzwerkverkehrs, sondern der Bestell- und Stornierungsvorgänge, also auf Geschäftsprozessebene. Derartiger Missbrauch lässt sich nur stoppen, wenn Entwicklungsteams eine klare Vorstellung von den Geschäftsabläufen erhalten: Welche Abläufe können sich geschäftsschädigend auswirken, wenn jemand sie exzessiv nutzt? Erst im zweiten Schritt kann dann die Entscheidung fallen, mit welchen technischen Maßnahmen sich ein Missbrauch vom legitimen Gebrauch unterscheiden und unterbinden lässt.

Kurz: Der Schutz von APIs erfordert nicht nur ein umfassendes Sicherheitskonzept, sondern auch ein Verständnis des Business und ein gründliches, bedachtes Vorgehen der Entwicklungsteams. Andernfalls, dass zeigen zahllose Sicherheitsvorfälle, gerät man allzu schnell in Teufels Küche.

Über die Autoren

Dani Estermann ist Head of Product Management bei Airlock.

Reto Ischi ist Head of Product Development bei Airlock.

(ID:49748897)