Die OWASP API Top 10 2019

Dieser Artikel gibt einen kurzen Überblick über die einzelnen Risiken der «OWASP API Top 10» und die jeweiligen Schutzmassnahmen.

Application Programming Interfaces (APIs), also Anwendungsschnittstellen, machen laut einem Bericht von Gartner bereits 40 % der Angriffsfläche von Webanwendungen aus – Tendenz steigend. Gartner schätzt, dass diese Zahl bis zum Jahr 2021 auf 90 % steigen wird. ^[1]Der Trend geht immer mehr hin zu dynamischen Single-Page-Anwendungen (SPAs), klassische serverbasierte Webanwendungen werden nach und nach abgelöst.

Dafür gibt es mehrere Ursachen. Zum einen fördert die zunehmende Nutzung von Smartphones und Tablets diese Entwicklung, auf denen mobile Anwendungen nicht nur klassische Webanwendungen einbetten, sondern direkt mit Anwendungsschnittstellen kommunizieren. Zum anderen erfreuen sich Internet-of-Things-Geräte (IoT) immer größerer Beliebtheit. APIs sind für eine solche Internet-Infrastruktur wesentlich. ^[2] Somit ist es offensichtlich, dass APIs für die Sicherheit von Webanwendungen eine immer bedeutendere Rolle spielen.

Aus diesem Grund hat die Non-Profit-Organisation «Open Web Application Security Project» (OWASP) 2019 erstmals eine eigene Top-Ten-Liste für API-Schwachstellen veröffentlicht. Seit 2001 arbeitet die OWASP-Community, bestehend aus mehreren tausenden Mitgliedern, gemeinsam daran, Webanwendungen sicherer zu machen. Bekannt wurde OWASP dabei vor allem durch die «OWASP Top 10», eine Auflistung der wichtigsten Sicherheitsrisiken für Webanwendungen, die erstmals im Jahr 2003 herausgegeben wurde. Seitdem sind aus dem Projekt weitere Top-10-Listen hervorgegangen, beispielsweise für Mobilapplikationen oder IoT-Anwendungen. Dass OWASP nun eine eigene Liste für API-Sicherheitsrisiken veröffentlicht hat, verdeutlicht einmal mehr die immer größer werdende Bedeutung von APIs. ^[3]

Dieser Artikel soll einen kurzen Überblick über die einzelnen Risiken der «OWASP API Top 10» und die jeweiligen Schutzmaßnahmen geben. Dabei werden Sie feststellen, dass es zwischen der Top-Ten-Liste für APIs und der ursprünglichen Liste für Webanwendungen etliche Überschneidungen gibt. Dies liegt daran, dass Single-Page-Anwendungen mit APIs im Grunde denselben Zweck erfüllen wie traditionelle Webanwendungen. ^[4]Trotzdem greifen die Sicherheitsmechanismen für traditionelle Webanwendungen bei SPAs mit APIs nicht immer, da sie sich in der Funktionsweise wesentlich unterscheiden: Bei SPAs werden Daten im Client via APIs angefordert und verarbeitet, wohingegen die Verarbeitung bei traditionellen Webanwendungen auf dem Server erfolgt. Während bei diesen Anwendungen der Server die Informationen über den aktuellen Zustand der Anwendung verwaltet, übernimmt in SPAs der Client diese Aufgabe. ^[5]

Die OWASP API Top 10 2019

OWASP stuft die folgenden Sicherheitsrisiken als die 10 kritischsten API-Schwachstellen ein ^[6]:

1. Fehler in Autorisierung auf Objektebene
2. Fehler in Authentifizierung
3. Preisgabe sensibler Daten
4. Fehlende Ressourcen- und Ratenbegrenzung
5. Fehler in Autorisierung auf Funktionsebene
6. Massenzuweisung
7. Sicherheitsrelevante Fehlkonfiguration
8. Injection
9. Unzureichende Asset-Verwaltung
10. Unzureichendes Logging und Monitoring

Fehler in Autorisierung auf Objektebene

Fehler in der Autorisierung auf Objektebene (API1: Broken Object Level Authorization) stellen die kritischten Schwachstellen für Anwendungsschnittstellen dar. Moderne Anwendungen verfügen meist über sehr komplexe Mechanismen für die Autorisierung, die zudem nicht zentral implementiert sind. Selbst wenn in einer Anwendung eine wirksame Autorisierungsinfrastruktur vorhanden ist, wird diese nicht immer zwingend auch für den Zugriff auf sensible Objekte angewendet. Folglich werden die Berechtigungen von authentifizierten Benutzern auf Objektebene nicht überprüft.

REST-APIs folgen einem ähnlichen Muster bzw. Pfad. Grundsätzlich trägt der Client die «Verantwortung», den jeweiligen Status aufrechtzuerhalten und herauszufinden, welche Informationen benötigt werden. In einer REST-API-Anfrage ist häufig eine ID der jeweiligen Ressource enthalten, die in einem Pfad oder einem anderen Parameter gesendet wird. Möchte ein Benutzer, der in einem Online-Shop angemeldet und somit authentifiziert ist, beispielsweise die Bankdaten für sein Benutzerkonto abrufen, könnte die API-Anfrage wie folgt aussehen: GET/accounts/id1/bank_details. Ein Angreifer könnte nun die in der Anfrage aufgeführte ID durch eine andere beliebige ID ersetzen und dadurch Zugriff auf die Daten eines anderen Benutzers erlangen, falls die API die Autorisierung des Benutzers nicht weiter überprüft. Es gibt dadurch keine weitere Prüfung, ob auch wirklich ein Benutzer die Eingabe vornimmt, der laut ID dazu berechtigt ist.

2017 wurde eine solche Sicherheitslücke auf einer Website von T-Mobile aufgedeckt. In diesem Fall wurde die Telefonnummer als ID verwendet. Man musste also lediglich die Telefonnummer eines anderen Benutzers kennen, um damit weitere Daten dieses Benutzers abzurufen. ^[7]

Förderlich für solche Fehler sind zum einen – wie bereits erwähnt – dezentrale Zugriffsmechanismen, zum anderen werden Hierarchien immer komplexer. Für verschiedene Benutzer gelten unterschiedlichste Zugriffsberechtigungen. Hat sich ein Benutzer durch die Eingabe seiner Anmeldedaten authentisiert, findet oft keine weitere Überprüfung seiner Berechtigungen statt.

Als Folge kann ein Angreifer Daten anderer Benutzer und im Falle von Multi-Tenant-Systemen auch Daten anderer Tenants abrufen. Darüber hinaus kann ein Angreifer die Schwachstelle ausnutzen, um seine Berechtigungen zu erweitern, sowohl horizontal als auch vertikal; dies kann bis zu einer kompletten Übernahme von Benutzerkonten führen.

Um eine solche Sicherheitslücke aufzudecken, sollten neben dynamischen Anwendungssicherheitstests (Dynamic Application Security Testing (DAST)) manuelle Tests der Anwendung/API sowie Code Reviews herangezogen werden. Erfahrungsgemäß gehören Fehler in der Autorisierung auf Objektebene zu den in Penetration Tests am häufigsten gefundenen Schwachstellen.

Damit eine solche Verwundbarkeit erst gar nicht entsteht, sollten die Berechtigungen eines Benutzers bei jeder Referenz erneut überprüft werden. Es sollte nicht allein der vom Client gesendeten ID vertraut, sondern die im Sitzungsobjekt gespeicherte ID verwendet werden. Zugriffsrechte müssen zentral im Backend geprüft werden und Entwickler müssen sicherstellen, dass der zentrale Authentifizierungsmechanismus auch wirklich in jedem Controller verwendet wird. Es reicht nicht aus, zufällige, nicht erratbare IDs anstelle von Zahlen zu verwenden, auch wenn diese durchaus eine sehr gute Maßnahme zur Verteidigung in der Tiefe darstellen.

Fehler in Authentifizierung

Anwendungsschnittstellen sind anfällig für Fehler in der Authentifizierung (API2: Broken User Authentication), da Verfahren zur Authentifizierung und Sitzungsverwaltung oft nicht richtig implementiert sind. Angreifer können sich ohne Authentisierung anmelden, die Identität eines anderen Benutzers vortäuschen und Passwörter oder Sitzungsinformationen erbeuten.

Die Häufigkeit dieser Schwachstelle ist einerseits auf Authentifizierungsendpunkte zurückzuführen, die absichtlich für jeden zugänglich sind. Zudem sind sich Entwickler möglicherweise nicht ganz im Klaren darüber, wie Authentifizierungsmechanismen ordnungsgemäß zu implementieren sind und wo die Grenzen eben dieser Mechanismen liegen. Es fehlt an zusätzlichen Schutzmaßnahmen, wie Lockout-Mechanismen, CAPTCHAs oder Vorkehrungen gegen Credential Stuffing, oder es sind Schutzmechanismen vorhanden, die im Kontext nicht effektiv sind. Auch APIs, die in der URL sensible Authentisierungsinformationen, wie Authentisierungstoken oder Passwörter, senden, sind anfällig. Außerdem kommt es vor, dass die Authentizität von Authentisierungstoken nicht geprüft wird und unsignierte/schwach signierte JSON Web Tokens akzeptiert werden.

Macht sich ein Angreifer einen dieser anfälligen Mechanismen zu Nutze, kann er sich zum Beispiel mithilfe eines Brute-Force-Angriffs unberechtigten Zugriff auf die Konten anderer Benutzer verschaffen. Infolgedessen kann er persönliche Daten auslesen oder im Namen eines anderen Benutzers sensible Aktionen durchführen.

Um Fehler in der Authentifizierung zu identifizieren, sollten alle möglichen Wege zur Authentifizierung bei allen APIs sowie sämtliche Funktionen im Zusammenhang mit der Sitzungsverwaltung, den Authentifizierungsmechanismen, der Erstellung von Benutzerkonten sowie dem Ändern und Wiederherstellen von Passwörtern überprüft werden. Als Basis können dabei unter anderem die folgenden Fragen dienen: In welcher Form erfolgt die Authentisierung von Benutzern? Wie werden Passwörter gespeichert und übertragen? Wie wird die Benutzerkennung erstellt und verwaltet?

Zum Schutz gegen derartige Schwachstellen und vor allem deren Ausnutzung, müssen präventive Maßnahmen getroffen werden. Zunächst sind sämtliche Zugangsdaten sowie die Sitzungs-ID zu schützen; hierfür sollte auf bewährte Standardmechanismen und Good Practices zurückgegriffen werden. Die Implementierung einer Passwortrichtlinie nach NIST 800-63 ist empfehlenswert. API-Endpunkte zur Wiederherstellung von Anmeldedaten/zum Zurücksetzen von Passwörtern sind dabei ebenso kritisch zu behandeln wie Authentifizierungsendpunkte. Wo möglich sollten Multi-Faktor-Authentifizierungsprozesse implementiert werden. Zur Verhinderung von Credential Stuffing, Dictionary- oder Brute-Force-Angriffen sollte zusätzlich eine Ratenbegrenzung (Rate Limiting) definiert und umgesetzt werden, die für die Authentifizierungsendpunkte strenger sein muss als das allgemeine Rate Limiting für die API. Nähere Infos zur Ratenbegrenzung allgemein folgen in der Beschreibung zu API4 – Fehlende Ressourcen- und Ratenbegrenzung weiter unten in diesem Artikel. In diesem Zusammenhang ist auch zu berücksichtigen, dass API-Keys keine effektive Maßnahme zur Authentifizierung von Benutzern darstellen. API-Keys können lediglich die Anwendung identifizieren, von der eine API aufgerufen wird, jedoch nicht den Benutzer der Anwendung. ^[8]

Preisgabe sensibler Daten

Auf dem dritten Platz der Top-Ten-Risiken für APIs ist die Preisgabe sensibler Daten (API3: Excessive Data Exposure) zu finden. API-Antworten enthalten meist sehr viele Daten, die erst vom Client gefiltert werden, damit ein Benutzer auf der Client-seitigen Benutzeroberfläche nur die vorgesehenen Daten sehen kann. Die APIs sind somit abhängig von der Filterung durch den Client. Begünstigt wird diese Schwachstelle zudem durch generische Implementierungsverfahren, die Entwickler oft einsetzen, ohne zu berücksichtigen, welche Art von Daten exponiert wird (bzw. ob darunter sensible Informationen sind) und für wen diese Daten bestimmt sind.

Erlangt ein Angreifer direkten Zugriff auf den ungefilterten Datenverkehr, kann er sämtliche Informationen in den API-Antworten einsehen. Somit hat er auch Zugriff auf sensible Daten, die er für weitere Angriffe verwenden kann. Ein solcher Angriff kann immensen finanziellen Schaden nach sich ziehen und sich außerdem negativ auf den Ruf des Angriffsopfers auswirken.

Bei Uber wurde beispielsweise im September 2019 eine Schwachstelle entdeckt, deren Ausnutzung zur vollständigen Übernahme von Benutzeraccounts führen konnte. Sendete man eine ungültige Anfrage (addDriver) zum Hinzufügen eines neuen Fahrers (mit der Telefonnummer oder E-Mail-Adresse eines Benutzers), wurde daraufhin eine Fehlermeldung angezeigt, die die UUID (Universally Unique Identifier) des Benutzers enthielt; bei der UUID handelt es sich um eine standardisierte eindeutige Identifikationsnummer. Diese UUID konnte wiederum verwendet werden, um eine getConsentScreenDetails-Anfrage zu senden, über die es möglich war, sämtliche Informationen über den Benutzer abzurufen und schließlich das Benutzerkonto vollständig zu übernehmen. ^[9]

Um derartige Schwachstellen auszumachen, sollten sämtliche Daten klassifiziert werden; das bedeutet: Daten sollten von der Erstellung bis hin zur Archivierung nachverfolgbar sein. Zudem sollte klar sein, welche Daten vertraulich sind und somit besonders geschützt werden müssen, wo und wie diese Daten übertragen und gespeichert werden und wer Zugriff auf diese Daten hat. Automatische Testverfahren alleine sind nicht ausreichend wirksam, da diese Verfahren nicht unterscheiden können, ob es sich bei den Daten nun um sensible Informationen handelt oder ob die API-Antworten nur die gewünschten Informationen enthalten. Daher sollte eine Kombination aus dynamischen und statischen Methoden eingesetzt werden. Zum einen sind API-Antworten auf überflüssige Daten zu überprüfen (dynamisch). Zum anderen sind generische Methoden wie to_json() / to_string() zu entfernen bzw. von Vornherein zu verhindern (statisch) und nur die benötigten Informationen sollten in die Antwort eingebettet werden.

Um sich gegen die Ausnutzung dieses Risikos zu schützen, darf dem Client bei der Filterung von Daten niemals blind vertraut werden, sondern sämtliche API-Antworten müssen geprüft werden und dürfen ausschließlich Informationen enthalten, die der Benutzer wirklich benötigt. Hierzu sollten Schemata für die API-Antworten definiert werden, bei denen auch der Fehlerfall berücksichtigt werden muss.

Fehlende Ressourcen- und Ratenbegrenzung

API4: Lack of Resources and Rate Limiting bezieht sich auf den unzureichenden Schutz von APIs gegen eine hohe Anzahl von Anfragen oder umfangreiche Nutzdaten. Die Ressourcen- und Ratenbegrenzung ist ein Schutzmechanismus, der den eingehenden oder ausgehenden Datenverkehr zu oder von einem Netzwerk steuert. Zum Beispiel kann für eine Schnittstelle ein Wert für die Anzahl an zulässigen Anfragen pro Minute festgelegt werden. Übersteigt die Anzahl an Anfragen diesen Wert, wird ein Fehler ausgelöst. ^[10]Oftmals verfügen APIs über gar keine Ressourcen- oder Ratenbegrenzung. Bei manchen APIs wurde möglicherweise sogar ein solcher Schutzmechanismus implementiert, die Grenzwerte wurden jedoch nicht flächendeckend umgesetzt oder können leicht umgangen werden.

Anwendungsschnittstellen mit fehlender oder mangelhaft implementierter Ressourcen- und Ratenbegrenzung bieten Angreifern die Chance, Brute-Force-Angriffe auf Benutzerkonten auszuführen oder ein Denial of Service zu verursachen. Für die Ausnutzung dieser Schwachstelle ist oft keine Authentisierung erforderlich; es müssen lediglich mehrere Anfragen gleichzeitig gesendet werden.

Ein Beispiel für fehlende Ressourcenbegrenzung: Ein Angreifer kann über eine POST-Anfrage an /api/v1/images eine große Bilddatei hochladen. Sobald der Upload abgeschlossen ist, erstellt die API mehrere Thumbnails in unterschiedlichen Größen. Aufgrund der Dateigröße wird der verfügbare Arbeitsspeicher während der Erstellung der Thumbnails vollständig genutzt und die API reagiert nicht mehr.

Um eine derartige Schwachstelle zu identifizieren, sollte auf mehreren Wegen auf die Anwendung zugegriffen werden: nicht authentisiert, authentisiert und mit falschen Zugangsdaten.

Zur präventiven Eindämmung des Risikos sollte eine Ratenbegrenzung (Standard-konforme Antwort mit dem Statuscode «429 Too Many Requests») sowie eine Ressourcenbegrenzung – ein Limit für Nutzdaten – implementiert werden. Überdies sollte Benutzereingaben niemals vertraut werden.

Fehler in Autorisierung auf Funktionsebene

Diese Schwachstelle (API5: Broken Function Level Authorization) ist der auf Platz 1 dieser Auflistung genannten Schwachstelle sehr ähnlich; beide hängen mit der Autorisierung zusammen. Der wesentliche Unterschied liegt in der Ebene, auf die sich beide Risiken beziehen: Bei API1 geht es um Objekte, wohingegen bei API5 die Funktionen relevant sind. Das zugrunde liegende Prinzip ist identisch: Ein Angreifer ändert einen Teil des Pfads oder einen Parameter der API-Anfrage, um einen privilegierten API-Endpunkt zu erreichen. Zum Beispiel kann ein autorisierter Benutzer mit normalen Benutzerrechten die Anfrage GET/api/users/my_bank_details senden, um seine eigenen Bankdaten abzufragen. Ersetzt ein Angreifer nun users durch admin und sendet die Anfrage mit dem angepassten Pfad erneut, erlangt er Zugriff auf administrative Funktionen. Oft wird im Backend die Anfrage nicht weiter geprüft, da die Backend-Entwickler sich auf den Client verlassen. Somit erhalten Angreifer ungehindert Zugriff auf administrative Funktionen. Diese Art von Schwachstelle ist sehr häufig zu finden, da Pfade und Parameter in APIs strukturierter aufgebaut sind und dadurch einfacher zu erraten sind als in klassischen Webanwendungen.

In der Theorie sind alle Benutzer einer Webanwendung potenzielle Angreifer. Um einen Angriff durchzuführen, müssen lediglich die entsprechenden Parameter verändert werden. Dadurch können privilegierte Funktionen exponiert werden und Angreifer können Berechtigungen vertikal erweitern.

So war es beispielsweise bei einer Smartwatch für Kinder möglich, sich durch Ändern eines einzigen Parameters Administratorrechte – nicht für ein einziges Gerät, sondern den gesamten Cloud-Dienst – und somit Zugriff auf sämtliche Funktionen und Benutzerdaten zu verschaffen. Sicherheitsforscher sendeten API-Anfragen und sahen sich die übermittelten Parameter genauer an. Dabei stellten sie fest, dass ein Parameter (User[Grade]) immer 1 lautete, während alle anderen Parameter für jede Anfrage unterschiedlich waren. Sie änderten den Wert zu 2, was jedoch keine Auswirkungen hatte. Schließlich fügten sie 0 ein: Durch diese einzige Änderung waren sie plötzlich Administratoren für das gesamte System, nicht nur für eine bestimmte Smartwatch. Dadurch konnten sie sämtliche Informationen zum Aufenthaltsort sowie persönliche Daten, wie den Namen des Kindes und die Namen der Eltern, für alle Systembenutzer abrufen und Anrufe an beliebige Smartwatches durchführen. ^[12]

Um unautorisierten Zugriff über eine solche Schwachstelle zu verhindern, darf dem Client niemals blind vertraut werden. Stattdessen sollten Zugriffsrechte zentral im Backend geprüft werden. Der Zugriff auf privilegierte Funktionen sollte generell verweigert (deny by default) und explizit nur Benutzern gewährt werden, die der entsprechenden Gruppe angehören oder die entsprechende Rolle besitzen. Davon ausgenommen sind öffentliche Ressourcen, bei denen der Zugriff erforderlich ist.

Massenzuweisung

Das Risiko der Massenzuweisung (API6: Mass Assignment) wird oftmals durch Frameworks begünstigt, welche die Umwandlung von Clientparametern in Objekteigenschaften automatisieren. Wird bei der automatischen Umwandlung nicht berücksichtigt, ob es sich möglicherweise um sensible Eigenschaften handelt und ob diese exponiert werden dürfen, ist eine API verwundbar. Angreifer können Eigenschaften beliebig überschreiben und sich damit erhöhte Rechte verschaffen, Daten manipulieren oder Sicherheitsmechanismen umgehen. Sensible Objekteigenschaften, die geändert werden, können sich dabei auf Rechte (z. B. Adminrechte), auf Prozesse (z. B. ein Kontostand) oder Metadaten (z. B. der Zeitpunkt der Erstellung) beziehen. Es gibt durchaus Objekteigenschaften, die direkt vom Client aktualisiert werden sollen; hierbei handelt es sich jedoch um nicht sensible Eigenschaften, beispielsweise user.first_name. Zu sensiblen Objekteigenschaft, die nicht vom Client aktualisiert werden sollen, zählt hingegen beispielsweise user.is_admin.

Die Massenzuweisung ist kein neues Phänomen, jedoch ist sie besonders in REST-APIs durch Methoden mit wohlbekannten Verben wie POST, PUT und PATCH leichter auszunutzen. Zudem müssen Objekteigenschaften nicht erraten werden, sondern können leicht in einer anderen GET-Methode, die sie zurückgibt, gefunden werden.

Das folgende Szenario verdeutlicht dieses Risiko: In einer Ridesharing-Applikation können Benutzer grundlegende Profildaten bearbeiten. Dabei erfolgt ein API-Aufruf mit dem folgenden JSON-Objekt an PUT /api/v1/users/me:

• {"user_name":"inons","age":24}

In der Anfrage GET /api/v1/users/me ist zusätzlich die Eigenschaft credit_balance enthalten:

• {"user_name":"inons","age":24,"credit_balance":10}

Ein Angreifer wiederholt die erste Anfrage mit den folgenden Nutzdaten:

•  {"user_name":"attacker","age":60,"credit_balance":99999}

Da der Endpunkt anfällig für Massenzuweisung ist, erhält der Angreifer auf diesem Weg Guthaben, ohne dafür zu bezahlen.

Eine solche Schwachstelle kann durch einen Code Review oder durch dynamische Tests mithilfe eines Interception Proxy wie Burp oder des OWASP Zed Attack Proxy (ZAP) aufgedeckt werden.

Damit eine API im Hinblick auf diese Schwachstelle sicher ist, dürfen eingehende Daten nicht automatisch an Objekte gebunden werden. Schemata sowie erwartete Parameter und Werte müssen klar definiert werden und die erwarteten Parameter/Werte sollten dementsprechend in eine Whitelist aufgenommen werden. Eigenschaften, für die kein Zugriff über den Client vorgesehen ist, sind hingegen einer Blacklist hinzuzufügen. Sämtliche Eigenschaften, die keinesfalls geändert werden dürfen, sollten auf den Status «read-only» gesetzt werden.

Sicherheitsrelevante Fehlkonfiguration

Das API-Sicherheitsrisiko auf Rang 7 der Top-Ten-Liste beschäftigt sich mit sicherheitsrelevanten Fehlkonfigurationen (API7: Security Misconfiguration). Oft werden unsichere Standardeinstellungen oder Komponenten eingesetzt, für die es bereits bekannte Schwachstellen gibt. Angreifer können von Informationen über die eingesetzte Komponente profitieren und diese verwenden, um weitere Angriffe vorzunehmen oder Code auf dem Server auszuführen. Diese Schwachstelle tritt mitunter am häufigsten auf und kann enorme wirtschaftliche Auswirkungen nach sich ziehen, wenn die Übernahme eines Systems unbemerkt bleibt und kontinuierlich sensible Daten abgerufen werden.

Manuelle, unsichere, fehlende oder Ad-hoc-Sicherheitskonfigurationen bieten eine Angriffsfläche für unberechtigten Zugriff. Dazu zählen unter anderem Standardpasswörter, unsichere Standardeinstellungen, unnötige Komponenten wie Ports, Benutzerkonten, Funktionen und Verzeichnisauflistungen, oder zu detaillierte Fehlermeldungen, die neben dem verwendeten Produkt auch die verwendete Version preisgeben.

Eine lückenhafte Sicherheitskonfiguration kann nicht nur dazu führen, dass Informationen abfließen, sondern auch, dass ein Angreifer unautorisiert auf Daten zugreifen kann, indem er sich öffentlich bekannte Schwachstellen von veralteter oder anfälliger Software zu Nutze macht. Dies kann bis zur vollständigen Übernahme und Kompromittierung des kompletten Systems reichen.

Um sicherzustellen, dass derartige Verwundbarkeiten nicht unentdeckt bleiben, sollten regelmäßig Schwachstellenscans durchgeführt werden. Wiederholbare Härtungsprozesse für Anwendungen, Frameworks, Applikationsserver, Datenbankserver und Betriebssysteme gemäß den jeweils geltenden Good Practices tragen dazu bei, dass eine solche Sicherheitslücke erst gar nicht entsteht. Für alle Umgebungen – das bedeutet Entwicklungs-, Test- und Produktivumgebung – ist generell dieselbe sichere Konfiguration anzuwenden. Auf unnötige Funktionen sollte gänzlich verzichtet werden, damit die Plattform so einfach wie möglich gehalten wird. Zudem kann eine segmentierte Architektur für die Anwendung hilfreich sein. Zu guter Letzt sollten Entwickler eine automatische Überprüfung der Konfigurationen und Einstellungen in allen Systemumgebungen implementieren.

Injection

API8: Injection ist ein wohlbekanntes Sicherheitsrisiko aus der OWASP Top-10-Liste für Webanwendungen, denn in dieser Liste ist Injection ganz oben auf Rang 1 zu finden. Grund dafür sind SQL Injections, die bei Webanwendungen zu den häufigsten Angriffsarten zählen. Bei APIs sind SQL-Injection-Angriffe wiederum nicht so stark verbreitet, was zum einen auf die Verwendung von objektrelationalen Abbildungen (ORMs; Object-Relational Mappings) und zum anderen auf die zunehmende Nutzung von NoSQL zurückzuführen ist. NoSQL Injections existieren zwar, sind aber bei weitem nicht so gängig.

Im Grunde hängt dieses Sicherheitsrisiko mit der Funktionsweise von Interpretern zusammen: Daten werden interpretiert; der Interpreter unterscheidet dabei jedoch nicht zwischen Code und Daten und interpretiert infolgedessen Daten möglicherweise als Code. Angreifer nutzen genau dieses Verhalten aus, um bösartige Daten, zum Beispiel über Parameter oder die URL, an die API zu senden. Mithilfe eines solchen Angriffs kann ein Angreifer Dateien einsehen, stehlen und/oder manipulieren, ein Denial of Service verursachen und Systeme sogar vollständig übernehmen.

Eine Schnittstelle ist anfällig für einen Injection-Angriff, sobald vom Client bereitgestellte Daten oder Daten von externen Systemen von der API nicht überprüft, gefiltert und bereinigt werden oder diese direkt verwendet und unmittelbar in Anfragen, beispielsweise NoSQL-Anfragen, Betriebssystembefehle oder ähnliches, umgewandelt werden.

Ein Code Review sollte durchgeführt werden, um sicherzustellen, dass beim Aufruf von Interpretern zwischen Code und Daten unterschieden wird. Zudem sollten Scanner zur Überprüfung eingesetzt werden. Hierbei ist zwischen statischen oder dynamischen Testverfahren abzuwägen. Bei beiden besteht das Risiko, dass etwas übersehen wird. Ideal wäre daher eine Kombination aus beiden Verfahren, die sich jedoch als kostspielig erweisen kann.

Um sich präventiv zu schützen, sollten sämtliche Eingaben – auch von eigenen Systemen – validiert werden. Alle Eingabedaten sollten streng definiert werden, das heißt Schemata, Typen, Zeichenkettenmuster und deren Durchsetzung zur Laufzeit. Darüber hinaus muss eine sichere Übergabe an den Interpreter erfolgen, zum Beispiel in Form von Prepared Statements, als weiterer Schutz kann eine Ausgabekodierung passend für den Interpreter gewählt werden.

Unzureichende Asset-Verwaltung

Aufgrund der ständigen Weiterentwicklung kann es vorkommen, dass Anbieter den Überblick über die vorhandenen Systeme, API-Versionen und API-Endpunkte verlieren. Infolgedessen werden diese nicht außer Dienst gesetzt und für bekannte Sicherheitslücken werden keine Patches mehr herausgegeben. Das Resultat ist eine unzureichende Asset-Verwaltung (API9: Improper Assets Management). Angreifer können genau an dieser Stelle ansetzen und sich über veraltete Zugänge Zugriff auf Daten aus Produktionssystemen verschaffen. Es kann sogar bis zur kompletten Übernahme von Systemen kommen.

Möglicherweise wurden für den Produktionsserver sogar Verteidigungsmaßnahmen getroffen und er ist dadurch vor Angriffen geschützt. Oftmals sind jedoch noch ungeschützte – vergessene – Staging- oder Legacy-Server vorhanden, über die ein Angreifer Zugang erhalten kann.

Aufgrund von CI/CD (Continuous Integration/Continuous Delivery) unterliegen APIs ständigen Veränderungen. Entwickler konzentrieren sich überwiegend auf die Bereitstellung, nicht auf die Dokumentation. Somit fehlt es häufig an Dokumentation oder die vorhandene Dokumentation ist unvollständig. Darüber hinaus vereinfachen Systeme zur Bereitstellungsautomatisierung (z. B. Kubernetes) die Inbetriebnahme neuer APIs wesentlich, was wiederum dazu beiträgt, dass die Anzahl der Systeme und Anwendungsschnittstellen unübersichtlicher wird und API-Hosts oder vollständige Umgebungen in Vergessenheit geraten.

Um diese Art von Schwachstellen zu identifizieren, müssen zunächst alle Hosts und Endpunkte gefunden werden. Außerdem sollten auch hier regelmäßig Schwachstellenscans durchgeführt werden.

Wirksame Maßnahmen umfassen die Bestandsaufnahme aller vorhandenen Hosts und die Dokumentation aller verwendeten API-Versionen. Zudem sollte die Produktion von der Test- und Entwicklungsumgebung getrennt sein. Generell sollten für alle Umgebungen die gleichen Sicherheitsmaßnahmen gelten. Besonders wichtig ist hierfür der Einsatz von Netzwerk- und API-Firewalls, nicht nur gegenüber extern, sondern auch intern. Des Weiteren sollte immer eine Authentifizierung erzwungen und auch internen Diensten ein Login vorangeschaltet werden.

Unzureichendes Logging und Monitoring

Das letzte Risiko der Liste (API10: Insufficient Logging & Monitoring) bezieht sich nicht auf eine direkte Schwachstelle, sondern auf einen fehlenden oder inneffektiven Schutzmechanismus: Logging und Monitoring sind unzureichend. Dadurch können Angriffe möglicherweise unbemerkt durchgeführt werden. Ein Angreifer hat in der Regel leichtes Spiel und kann Angriffe solange wiederholen, bis sie zum Erfolg führen. Selbst wenn ein Angriff – meist erst sehr spät – entdeckt wird, ist es ohne aussagekräftige Logdateien äußerst schwierig, im Nachhinein nachzuvollziehen, ob und welche Daten abgeflossen sind.

Die Prüfung dieser Schwachstelle mithilfe eines Applikationssicherheitsaudits stellt eine Herausforderung dar, da es nicht möglich ist, die Tests ohne die Mithilfe des Kunden durchzuführen. Für eine effektive Durchführung ist die Unterstützung des sogenannten Blue Teams – die Verteidigung auf Kundenseite – erforderlich.

Generell können diesem Problem mehrere Ursachen zugrunde liegen: Es sind überhaupt keine Logs vorhanden, Logs werden nicht lange genug gespeichert oder sie enthalten nicht genügend oder nicht eindeutige Daten. Außerdem werden die Protokolle möglicherweise nicht zentral, sondern über mehrere Systeme verteilt gespeichert. Selbst wenn Logs vorhanden sind, werden diese häufig nicht automatisch ausgewertet und nicht auf Aktivitäten untersucht, die Verdacht erregen. Zu guter Letzt gibt es in vielen Fällen keinen Prozess für Warnmeldungen und zur Reaktion auf solche Warnmeldungen.

Fehler bei der Authentifizierung und Autorisierung müssen protokolliert werden; dazu zählen fehlgeschlagene Versuche, verweigerter Zugriff, Eingabevalidierungsfehler und sämtliche Fehler bei der Überprüfung von Sicherheitsrichtlinien. Die Protokolle müssen dabei auf einem zentralen Server überprüft werden. In den Logs sollten nicht nur verdächtige Aktivitäten, sondern auch Daten zum Benutzerkontext enthalten sein, um auch die zugehörigen Accounts identifizieren zu können. Dabei ist zu berücksichtigen, dass keinesfalls sensible Daten gespeichert werden dürfen, die wiederum von Angreifern eingesehen werden können. Generell sind Protokolle als hochsensibel zu betrachten und dementsprechend zu schützen. Es sollte ein einfaches und einheitliches Format für das Logging verwendet werden. Darüber hinaus sollten die Verantwortlichen automatische Warnungen sowie einen Incident-Response-Prozess definieren und implementieren, auf den bei einem Vorfall zurückgegriffen werden kann.

Fazit

Zusammenfassend wird aus den zuvor im Detail erläuterten Risiken deutlich, dass insbesondere Authentifizierung und Autorisierung wichtige Faktoren für die Sicherheit von APIs sind, denn vier Risiken aus der Top-10-Liste beschäftigen sich mit möglichen Schwachstellen in diesem Zusammenhang. Dementsprechend sollte besonderes Augenmerk auf die umfassende Implementierung und konsequente Anwendung von soliden Authentifizierungs- und Autorisierungsmechanismen gelegt werden. Darüber hinaus ist im Sinne der Datensicherheit auch bei APIs eine sorgfältige Umsetzung des Least-Privilege-Prinzips von großer Bedeutung, damit Benutzer nur die Berechtigungen besitzen, die sie auch wirklich benötigen. Des Weiteren wird insbesondere dem Client oftmals zu viel Vertrauen geschenkt. Daher ist eine serverseitige Validierung sowie die Durchsetzung einer Authentifizierung/Autorisierung bei jedem einzelnen Zugriff unabdingbar.

Ein weiterer nicht zu vernachlässigender, genereller Aspekt ist die hohe Komplexität einzelner Komponenten, wie die gerade genannte Authentisierung/Autorisierung oder Konfigurationen. Um angesichts dieser Komplexität Prozesse möglichst strukturiert zu gestalten und die Übersicht zu bewahren, sind Vereinheitlichung, Dokumentation und Automatisierung wesentliche Schlüsselwörter. Zu guter Letzt mangelt es in vielen Fällen am Schutz in der Tiefe (Defense in Depth). Abhilfe kann hier eine klare Trennung der einzelnen Infrastrukturkomponenten schaffen.

Im Allgemeinen sollte die in diesem Artikel beschriebene Top-10-Liste als Awareness-Dokument betrachtet werden, das zur Sensibilisierung für die zehn kritischsten API-Risiken beiträgt. Die vorgeschlagenen Maßnahmen sollten keineswegs als absoluter Standard aufgefasst werden. Sie sollten als Good Practices verstanden werden, die dabei helfen, den ersten Schritt hin zu mehr Anwendungssicherheit zu machen.

Über Oneconsult

Die Oneconsult-Unternehmensgruppe ist seit 2003 Ihr renommierter Schweizer Cybersecurity Services Partner mit Büros in der Schweiz und Deutschland und 2000+ weltweit durchgeführten Security-Projekten.

Erhalten Sie kompetente Beratung vom inhabergeführten und herstellerunabhängigen Cybersecurity-Spezialisten mit 40+ hochqualifizierten Cybersecurity Experten, darunter zertifizierte Ethical Hacker / Penetration Tester (OPST, OPSA, OSCP, OSCE, GXPN), IT-Forensiker (GCFA, GCFE, GREM, GNFA), ISO Security Auditoren (ISO 27001 Lead Auditor, ISO 27005 Risk Manager, ISO 27035 Incident Manager) und dedizierte IT Security Researcher, um auch Ihre anspruchsvollsten Herausforderungen im Informationssicherheitsbereich zu bewältigen. Gemeinsam gehen wir Ihre externen und internen Bedrohungen wie Malware-Infektionen, Hacker-Attacken und APT sowie digitalen Betrug und Datenverlust mit Kerndienstleistungen wie Penetration Tests / Ethical Hacking, APT Tests unter Realbedingungen und ISO 27001 Security Audits an. Bei Notfällen können Sie rund um die Uhr (24 h x 365 Tage) auf die Unterstützung des Digital Forensics & Incident Response (DFIR) Expertenteams von Oneconsult zählen.

www.oneconsult.com