Gut behütet: OWASP API Security Top 10

Inhaltsverzeichnis

Exponierte APIs entwickeln sich zur beliebtesten Angriffsfläche von Webanwendungen. OWASP (Open Web Application Security Project) reagiert darauf mit einer neuen und spezialisierten Top-Ten-Liste für API-Security.

Die ursprüngliche OWASP Top Ten ist eine weitverbreitete Liste der zehn wichtigsten Schwachstellen in Webapplikationen. Die Liste erschien erstmals 2003 und basiert auf den Daten hunderter Organisationen weltweit. Sie beschreibt jede Schwachstelle und potenzielle Gegenmaßnahmen im Detail. Über die Jahre hat OWASP zusätzlich Schwachstellen von APIs (Application Programming Interfaces) berücksichtigt, die in der Softwareentwicklung immer stärker Verbreitung finden. OWASP hat folglich nicht mehr einfach von Applikationen, sondern von "Applikationen oder APIs" gesprochen. Ebenfalls hat die Organisation Schwachstellen aufgenommen, die API-spezifisch sind wie die "A4 – XML External Entities" in der Ausgabe von 2017.

OWASP setzt nun ein Zeichen und hat im Dezember 2019 eine eigene Liste der Top-Ten-Schwachstellen für APIs veröffentlicht. Damit betont OWASP die zunehmende Wichtigkeit von API-Sicherheit für Unternehmen.

Beim Schutz der Programmierschnittstellen können dezidierte Sicherheitsprodukte wie Web Application Firewalls (WAF), API-Gateways und CIAM-Systeme (Customer Identity Access Management) einiges leisten. Sich einzig auf solche Produkte zu verlassen wäre allerdings fahrlässig. Der wichtigste Schutz geht von den Entwicklern der APIs aus, die Schwachstellen kennen und dadurch vermeiden können.

SPAs befeuern die Verbreitung von APIs

Anders als noch vor zehn Jahren sind Webapplikationen heute meist Single-Page Applications (SPA), die eine Vielzahl von APIs beispielsweise in Form von Microservices integrieren. Bei der Entwicklung der Nutzerschnittstelle kommen Webframeworks wie Angular oder React zum Einsatz. Die APIs kapseln einzelne Aspekte der Businesslogik. Die Zusammensetzung der Elemente auf der Nutzeroberfläche orientiert sich an Rich Clients.

Zeitgemäße APIs sind typischerweise als RESTful Webservices umgesetzt. Die SPAs rufen sie direkt aus dem Browser heraus auf, wodurch sie im gleichen Maße Angriffen ausgesetzt sind wie traditionelle Webanwendungen. Leider weisen solche APIs häufig ähnliche oder gar dieselben Schwachstellen auf. Erschwerend kommt hinzu, dass sie noch näher bei den sensiblen Daten angesiedelt sind als beispielsweise hinter einer Java-Enterprise-Fassade in früheren Zeiten.

Gartner schätzt in einer neuen API-Security-Studie, dass bis 2021 bei 90 Prozent der Webapplikationen die größte Angriffsfläche durch exponierte APIs entstehen wird. Deren Missbrauch wird demnach bis 2022 zum wichtigsten Angriffsvektor und weltweit zu Data Breaches führen. Bereits heute sind prominente Datenpannen aufgrund unsicherer APIs in der Presse wie der Hack des US Postal Services von 2018, der Daten von 60 Millionen Benutzern betraf. Grund für den erfolgreichen Angriff war das Fehlen von grundlegender Zugriffskontrolle auf Objekte.

Nummer	Titel	Beschreibung
API1	Broken Object Level Authorization	API Endpoints nehmen Objekt IDs entgegen, ohne zu überprüfen, ob der User/Client für Zugriff auf diese Objekte berechtigt ist.
API2	Broken Authentication	Authentisierungslogik ist oft fehlerhaft implementiert. Dies erlaubt Angreifern, Authentisierungs-Tokens zu kompromittieren oder Fehler in der Authentisierung auszunutzen. Wenn die Identität des Clients bzw. des Users nicht sicher festgestellt werden kann, ist die Grundlage für API Security nicht gegeben.
API3	Excessive Data Exposure	Entwickler tendieren dazu, generell alle Objekteigenschaften auf Endpoints zu exponieren, auch die sensitiven. Man verlässt sich auf den Client und hofft, dass dieser die Daten passend filtert, bevor sie dem User angezeigt werden.
API4	Lack of Resources & Rate Limiting	APIs machen keine Limitierung bezüglich der Größe und der Anzahl Ressourcen, die ein Client anfragt. Dies kann zu schlechter Performance bis hin zu Denial of Service (DoS) führen. Desweiteren können dadurch Brute-force Angriffe, z.B. auf Passwörter, ermöglicht werden.
API5	Broken Function Level Authorization	Komplexe Zugriffsregeln mit verschiedenen Hierarchien, Gruppen, Rollen und einer unklaren Trennung zwischen administrativen und regulären Funktionen führen zu Autorisierungsfehlern. Angreifer können so Zugriff auf Ressourcen erlangen, der ihnen nicht zusteht.
API6	Mass Assignment	Vom Client gelieferte Daten, z.B. im JSON Format, werden direkt und ohne Filterung ins Datenmodell abgefüllt. Angreifer können zusätzliche Attribute erraten, in der Dokumentation einsehen oder mittels Exploration herausfinden. Damit können sie Objekt Attribute modifizieren, zu denen sie keinen Zugriff haben sollten.
API7	Security Misconfiguration	Unsichere Konfigurationen resultieren meist aus unsicheren Default Settings, unvollständigen Konfigurationen, öffentlich verfügbaren Cloud Storages, falsch konfigurierten HTTPS Headers und Methoden, zu offenen CORS Regeln oder auch Fehlermeldungen, die zuviel preisgeben.
API8	Injection	Injection Schwachstellen, z.B. für SQL, NoSQL, LDAP oder OS Commands entstehen, wenn unsichere Input-Daten als Teil eines Kommandos an einen Interpreter geschickt werden. Ein Angreifer kann damit ggf. bösartige Aktionen auslösen und unautorisiert Daten auslesen oder verändern.
API9	Improper Assets Management	APIs exponieren tendenziell mehr Endpoints als traditionelle Web-Applikationen. Korrekte und aktuelle Dokumentation ist daher sehr wichtig. Ein Inventar über die Hosts und API Versionen verhindert z.B. die Veröffentlichung von nicht mehr unterstützten APIs und Debugging Endpoints.
API10	Insufficient Logging & Monitoring	Unzureichendes Logging und Monitoring, verbunden mit fehlender oder ungenügender Integration mit Incident Reponse, erlauben es Angreifern Systeme zu attackieren, sich einzunisten und weitere Ziele anzugreifen, mit dem Ziel Daten zu extrahieren oder zu modifizieren. Studien zeigen, dass Breaches oft erst nach 200 Tagen entdeckt werden, und das erst noch von externen Stellen und nicht durch interne Prozesse.

Vergleich der Charts

Beim Vergleich der neuen Top-Ten-Liste für APIs mit der aktuellen für Web-Applikationen aus dem Jahr 2017 (A1-A10), fällt auf, dass etliche Schwachstellen gleich oder zumindest ähnlich sind:

• Broken Authentication (API2, A2)
• Security Misconfiguration (API7, A6)
• Injection (API8, A1)
• Insufficient Logging & Monitoring (API10, A10)

Ein Grund dafür dürfte sein, dass traditionelle Webanwendungen und SPAs mit APIs grundlegend dieselben Aufgaben erledigen. Beide Ansätze stellen eine Nutzerschnittstelle in Webbrowsern zur Verfügung und müssen Benutzer authentisieren. Sie nehmen Benutzerdaten entgegen und manipulieren Datensätze in Datenbanken. Beide laufen auf Servern oder in Containern und sind daher gegen Konfigurationsfehler anfällig. Administratoren überwachen den Betrieb und die Sicherheit gestern wie heute mit Monitorings von Log-Daten.

Die Listen haben nicht nur überlappende Themen, sondern auch eine ähnliche Priorität der Schwachstellen. Lediglich bei Injection fällt auf, dass sie bei APIs auf Platz 8 stehen, während sie in der Webapplikationsliste den Spitzenplatz innehaben. Vielleicht liegt die Annahme zugrunde, dass moderne Webframeworks vermehrt Funktionen zur Validierung der Eingabedaten übernehmen und damit Clients weniger boshafte Strings an die APIs übergeben. Es gilt jedoch zu berücksichtigen, dass native Mobile Apps oder IoT-Clients ebenfalls die APIs nutzen. Dort fehlen entsprechende Frameworks. Zudem sollte man sich nie auf clientseitige Validierung verlassen, da Hacker an den Frameworks vorbei direkt die APIs angreifen können.

Interessanterweise ist "A4 XML Enternal Entities (XEE)" nicht in der API-Liste vertreten. Vermutlich ist das auf die abnehmende Bedeutung von SOAP-Webservices zurückzuführen. "A7 Cross-Site Scripting (XSS)" fehlt ebenfalls auf der API-Liste. OWASP betrachtet XSS augenscheinlich als reines Browserproblem. APIs interpretieren freilich kein JavaScript und sind deshalb nicht direkt anfällig für XSS. Allerdings sollten API-Endpunkte ihre Eingabedaten dahingehen validieren, dass sie keine JavaScript-Befehle enthalten, die eine Anwendung dauerhaft speichern könnte. Je nach Client könnten die Befehle und damit XSS durchaus ein Problem darstellen.