Die 10 größten API-Sicherheitsrisiken laut OWASP

Wenn Sie die API-Sicherheit verbessern möchten, ist es oft schwierig zu wissen, wo Sie anfangen sollen. Ihr Team fragt sich vielleicht, was als „kritische“ und was als „nicht kritische“ Schwachstelle gilt und welche Tools eingesetzt werden sollten, um die schwerwiegendsten Risiken für Backend-Anwendungen (auch Server genannt) und andere API-basierte Systeme zu mindern.

Die Cybersicherheitsbranche begegnet diesen Fragen mit Frameworks, die auf Forschungsergebnissen basierende Erkenntnisse dazu liefern, welche Risiken Vorrang haben sollten und wie sich darauf reagieren lässt. Zu den jüngsten Entwicklungen gehört das OWASP API Top 10, ein Framework zur Absicherung Ihrer APIs.

Das OWASP API Top 10 im Überblick

Die OWASP Foundation gibt Unternehmen seit mehr als einem Jahrzehnt Sicherheitsempfehlungen. Ihr bekanntestes Projekt ist das OWASP Top 10 Project, das es seit 2003 gibt und das kürzlich für 2021 aktualisiert wurde.

2019 wurde die erste OWASP-Liste zur API-Sicherheit veröffentlicht. OWASP entschied sich für die Veröffentlichung, weil die Organisation die Bedeutung von APIs und deren zunehmendes Risiko für die Sicherheitslage heutiger mobiler, SaaS- und webbasierter Anwendungen erkannt hatte.

Warum sollten Sie das OWASP API Security Top 10 verwenden?

Softwareunternehmen können heute ohne APIs nicht innovativ sein. APIs bilden die Grundlage unzähliger Anwendungen, da sie deren einfache Integration sowie den Austausch von Daten und Funktionen mit anderen ermöglichen – etwa mit Drittanbietern und internen Entwicklungsteams. Der Kern einer API besteht also darin, Daten einfach auszutauschen und Interoperabilität zu ermöglichen. Leider können Angreifer dadurch auch leicht die Anwendungslogik und vertrauliche Daten offenlegen, die über eine API bereitgestellt werden. Da diese APIs häufig öffentlich zugänglich sind, ist das Risiko einer Nutzung durch böswillige Akteure besonders hoch.

Sicherheit von Webanwendungen im Vergleich zur API-Sicherheit

Warum musste OWASP eine separate Liste der zehn häufigsten Schwachstellen in APIs veröffentlichen? APIs und Webanwendungen sind zwar oft voneinander abhängig, aber grundverschiedene Technologien und können unterschiedliche Risiken mit sich bringen.

Sicherheit von Webanwendungen

Herkömmliche Webanwendungen haben ihre Einstiegspunkte hauptsächlich an zwei Stellen: auf der Client- und auf der Serverseite. Die größten Bedrohungen für Webanwendungen hängen in der Regel mit Schwachstellen in einer dieser beiden Kategorien zusammen.

Zwei Beispiele für OWASP Top 10-Schwachstellen in Anwendungen sind fehlerhafte Zugriffskontrollen, durch die Unbefugte auf den Server zugreifen können, und kryptografische Fehler, durch die Daten auf dem Server nicht ordnungsgemäß verschlüsselt sind.

Wie wir sehen, stehen beide Risikotypen in direktem Zusammenhang mit dem Server. Das liegt daran, dass Webanwendungen nur wenige Einstiegspunkte haben: Die Daten werden serverseitig verarbeitet, die Webseite wird im Client-Browser gerendert, der Benutzer sendet eine Anfrage zurück und diese erreicht erneut den Server. Es handelt sich um einen einfachen Austausch in beide Richtungen. Auch wenn Angreifer jeden Teil dieses Prozesses manipulieren können, gibt es nur wenige Einstiegspunkte.

API-Sicherheit

APIs bieten hingegen eine potenziell sehr große Angriffsfläche, da sie zahlreiche API-Endpunkte offenlegen, über die Angreifer auf vertrauliche Daten zugreifen können. Komponenten einer einzelnen Anwendung verwenden jeweils eigene APIs, um Daten an Server zu senden und von ihnen zu empfangen. Eine Anwendung kann zahlreiche clientseitige Einstiegspunkte enthalten, die Angreifer ausnutzen können.

Wie bereits erwähnt, liegt es in der Natur von APIs, Daten offenzulegen. Wenn alles wie vorgesehen funktioniert, machen APIs Anwendungen deutlich effizienter, da sie mit anderen Anwendungen und Datenbanken „kommunizieren“ können. Leider macht diese Eigenschaft die API-Sicherheitsrisiken für Unternehmen, die APIs einsetzen, besonders folgenreich.

Die OWASP API Security Top 10 erklärt

Die OWASP API Security-Liste führt die häufigsten Schwachstellen auf, die die Sicherheit Ihres Anwendungsservers am ehesten gefährden. Sie bietet Ihrem Team eine hervorragende Orientierung bei der Auswahl von Lösungen und Services, um Ihre API-Sicherheit zu stärken und die Sicherheitslage Ihres gesamten Unternehmens durchgängig zu verbessern.

Hier finden Sie die vollständige Liste. Über die Links gelangen Sie direkt zu den einzelnen Abschnitten:

1. Fehlerhafte Autorisierung auf Objektebene

2. Fehlerhafte Benutzerauthentifizierung

3. Übermäßige Offenlegung von Daten

4. Unzureichende Ressourcen- und Ratenbegrenzung

5. Fehlerhafte Autorisierung auf Funktionsebene

6. Massenzuweisung

7. Fehlkonfiguration der Sicherheit

8. Injection

9. Unzureichende Verwaltung von Assets

10. Unzureichende Protokollierung und Überwachung

#1: Fehlerhafte Autorisierung auf Objektebene

APIs verwenden die Autorisierung auf Objektebene, um sicherzustellen, dass nur die richtigen Benutzer auf die von der API bereitgestellten Daten zugreifen können. Ist dieser Zugriffskontrollmechanismus fehlerhaft, können Angreifer die API nutzen, um Daten offenzulegen, zu ändern oder zu löschen, die ihnen nicht gehören oder auf die sie keinen Zugriff haben sollten.

#2: Fehlerhafte Benutzerauthentifizierung

Endpunkte und Abläufe zur Benutzerauthentifizierung gelten als fehlerhaft, wenn die API keine ausreichenden Sicherheitsmechanismen einsetzt – etwa starke Verschlüsselungsschlüssel, Schutz vor Passwort-Stuffing oder sicher gehashte Passwörter. Versäumt es ein Entwickler, Schlüssel zu erneuern oder eine Token-Authentifizierung einzurichten, können Angreifer die Zugangsdaten anderer Personen erlangen und damit auf APIs zugreifen.

Zum Beispiel führen mehrere Versionen der GitLab-Software bei geplanten Pipelines Autorisierungen nicht korrekt durch. Diese Schwachstelle könnte es einem böswilligen Benutzer ermöglichen, eine Pipeline im Kontext eines anderen Benutzers auszuführen.

#3: Übermäßige Offenlegung von Daten

Diese Schwachstelle tritt auf, wenn eine API mehr Informationen bereitstellt als nötig und Angreifer diese ausnutzen können. Diese Art der Datenoffenlegung kommt häufig vor, weil Entwickler APIs oft allgemein implementieren, ohne die Endpunkte einzuschränken. Stattdessen sollten sie genau abwägen, welche API-Endpunkte sie offenlegen, und alle anderen standardmäßig herausfiltern.

Ein Beispiel dafür ist Moodle, eine Lernplattform. Die Tabellen-Download-Funktion von Moodle enthält Benutzer-E-Mail-Adressen in der Tabelle, auch wenn diese verborgen wurden. Ein einfaches Upgrade behebt diese Schwachstelle.

#4: Unzureichende Ressourcen- und Ratenbegrenzung

Wenn Entwicklungsteams die Größe oder Anzahl der Ressourcen nicht begrenzen, die ein Client anfordern darf, entstehen Schwachstellen. Haben Angreifer unbegrenzt viele „Versuche“, die richtige Anfrage zu stellen, können sie Brute-Force- oder Denial-of-Service-Angriffe durchführen.

Die Middleware `express-brute` enthält beispielsweise ein Package mit einer Schwachstelle, die eine Umgehung der Ratenbegrenzung ermöglicht. Durch die fehlerhafte Zählung der gesendeten Anfragen kann ein Angreifer den Rate-Limiting-Mechanismus umgehen.

#5: Fehlerhafte Autorisierung auf Funktionsebene

Ist ein Zugriffskontrollsystem falsch eingerichtet, können Angreifer unbefugten Zugriff auf API-Endpunkte erhalten und ihre neu erlangten Berechtigungen ausnutzen.

`github.com/matrix-org/gomatrixserverlib`, eine Go-Bibliothek mit gängigen Funktionen für Matrix-Server, enthält eine Package-Version, in der die Funktion zur Auswertung von Berechtigungsstufen fehlschlagen kann. Dadurch werden Ereignisse von Dendrite-Servern entweder fälschlicherweise autorisiert oder abgelehnt. Diese Schwachstelle kann Unternehmen einem Denial-of-Service-Angriff (DoS) aussetzen.

#6: Massenzuweisung

Diese Schwachstelle tritt auf, wenn eine API vom Client bereitgestellte Daten an Datenmodelle bindet. Dadurch kann ein böswilliger Client Objekteigenschaften ändern, indem er einfach clientseitige Felder manipuliert.

Ein Beispiel dafür ist laravel/framework, ein Webanwendungs-Framework. Betroffene Versionen dieses Packages sind anfällig für Massenzuweisung, wenn die Eigenschaft `fillable` nicht in den Modellen verwendet wird.

#7: Fehlkonfiguration der Sicherheit

Diese Kategorie umfasst Schwachstellen, die entstehen, weil Sicherheitskonfigurationen nicht korrekt eingerichtet wurden. Beispiele für Sicherheitsfehlkonfigurationen, die eine API beeinträchtigen können:

• Fehlende Sicherheitspatches

• Unnötige aktivierte Funktionen

• Das System verwendet weder Transport Layer Security (TLS) noch eine Cross-Origin Resource Sharing (CORS)-Richtlinie.

• Fehlermeldungen geben vertrauliche Informationen preis

`typo3/cms`, ein kostenloses Open-Source-Content-Management-Framework, umfasst mehrere Versionen, die anfällig für eine Sicherheitsfehlkonfiguration sind, durch die ein Konto mit leeren Zugangsdaten erstellt werden kann. Diese Schwachstelle könnte von einem Backend-Benutzer mit den entsprechenden Zugriffsberechtigungen ausgenutzt werden.

#8: Injection

Angreifer führen Injection-Angriffe durch, indem sie über die API-Schicht bösartige Daten in das System einschleusen. APIs sind gefährdet, wenn sie Daten nicht validieren oder bereinigen. `simple-git` ist beispielsweise in den Versionen 3.3.0 und älter durch Argument-Injection anfällig für Command-Injection. Durch das Einschleusen bestimmter Git-Optionen war die Ausführung beliebiger Befehle möglich.

 #9: Unzureichende Verwaltung von Assets

Teams müssen den Zweck und Aufbau jeder API verstehen und diese Informationen sorgfältig dokumentieren. Andernfalls versäumen sie womöglich, APIs bei Bedarf zu aktualisieren, zu reparieren oder außer Betrieb zu nehmen. Eine veraltete API ist deutlich anfälliger für Angriffe als eine aktuelle.

#10: Unzureichende Protokollierung und Überwachung

Wenn ein Sicherheitsteam nicht für eine angemessene Protokollierung und Überwachung sorgt, kann ein Angreifer wiederholt versuchen, in die Systeme einzudringen, ohne dass das Team davon erfährt.

Zwei Schritte zur Stärkung Ihrer API-Sicherheit

Wenn Ihr Team die OWASP Top 10 API-Risiken berücksichtigt, können Sie zwei Schritte unternehmen, um potenzielle Sicherheitslücken zu schließen: nach Schwachstellen suchen und Ihr Team über API-Risiken aufklären.

Nach API-Schwachstellen suchen

Sicherheitsteams müssen regelmäßig mithilfe geeigneter Technologien nach API-Schwachstellen suchen, ihren Backend-API-Code prüfen, Risiken aufspüren und beheben. Ein bekanntes, anfälliges Projekt als Übung für die Scan-Verfahren Ihres Teams zu verwenden, ist eine effektive Möglichkeit, deren Wirksamkeit sicherzustellen. Solche Projekte sind bei verschiedenen Anbietern verfügbar, darunter OWASP. 

So suchen Sie nach API-Schwachstellen

Snyk bietet verschiedene Ressourcen, mit denen Ihr Team API-Sicherheitsscans durchführen kann. Mit Snyk Code können Sie Ihren Backend-API-Code scannen und Injection, fehlerhafte Benutzerauthentifizierung, übermäßige Offenlegung von Daten und weitere Sicherheitsprobleme finden. Mit Snyk IaC können Sie Sicherheitsfehlkonfigurationen (OWASP API Risk #7) aufspüren, während Sie Ihre Infrastruktur für die Bereitstellung Ihrer Container oder serverlosen Funktionen in der Cloud konfigurieren.

Klären Sie Ihr Team über die OWASP Top 10 API-Schwachstellen auf

Teams benötigen außerdem praxisnahes Wissen über die OWASP Top 10. Wenn sie wirklich verstehen, wie die einzelnen Schwachstellentypen entstehen, tragen sie seltener zu diesen Risiken bei und sind eher bereit, bei deren Behebung zu helfen.

Zusätzlich zu Lernangeboten zu häufigen Schwachstellen muss Ihr Unternehmen klare Sicherheitsrichtlinien festlegen und Entwickler mit praxisnahen Schulungen zu deren Umsetzung befähigen. Snyk Learn bietet hilfreiche Lerninhalte zu verschiedenen Sicherheitsthemen, darunter API-Schwachstellen. Wenn Entwickler Best Practices für die Sicherheit wirklich verstehen, können sie durch sicheres Programmieren, mehr Unterstützung und eine schnellere Behebung von Problemen zur Verbesserung Ihrer allgemeinen Sicherheitslage beitragen.

Wie Snyk bei der API-Sicherheit hilft

Snyk bietet nicht nur Ressourcen, mit denen Unternehmen sicherere APIs betreiben können, sondern auch Lösungen für die Anwendungs- und Cloud-Sicherheit. Darüber hinaus stellen wir Teams Lernressourcen zu häufigen Schwachstellen in verschiedenen Programmiersprachen und Frameworks wie Java bereit.

Unser Ziel ist es, entwicklerfreundliche Shift-Left-Ressourcen bereitzustellen, die Ihren gesamten Softwareentwicklungslebenszyklus (SDLC) absichern, ohne die Agilität zu beeinträchtigen. Kontaktieren Sie uns und vereinbaren Sie noch heute eine Demo.