Wie APISIX vor den OWASP Top 10 API-Sicherheitsbedrohungen schützt

Mit der zunehmenden Nutzung und Abhängigkeit von APIs in der heutigen vernetzten digitalen Landschaft haben sich auch die Sicherheitsbedrohungen, die auf sie abzielen, im Laufe der Jahre verstärkt. Im Jahr 2023 hat das Open Web Application Security Project (OWASP) die neuen Top 10 Bedrohungen für die API-Sicherheit identifiziert. In diesem Blogbeitrag werden wir jede Bedrohung untersuchen und lernen, wie APISIX mit Beispielen dagegen schützen kann.

Das OWASP ist eine weltweit anerkannte Gemeinschaft, die regelmäßig Cybersicherheitsforschung veröffentlicht.

Hier ist die Liste der von OWASP genannten Sicherheitsrisiken:

1. Broken Object Level Authorization
2. Broken Authentication
3. Broken Object Property Level Authorization
4. Unrestricted Resource Consumption
5. Broken Function Level Authorization
6. Unrestricted Access to Sensitive Business Flows
7. Server-Side Request Forgery
8. Security Misconfiguration
9. Improper Inventory Management
10. Unsafe Consumption of APIs

1. Broken Object Level Authorization

Bedrohung: APIs bieten oft Endpunkte an, die Objektkennungen verarbeiten, was zu Problemen bei der Zugriffskontrolle auf Objektebene führen kann. Angreifer können diese Schwachstellen ausnutzen, um unbefugten Zugriff auf Daten zu erlangen.

Beispiel: Eine Gesundheitseinrichtung bietet ein Online-Patientenportal an. Aufgrund eines Fehlers im Design des Portals kann ein Patient, sobald er authentifiziert ist, die URL oder die Anfrageparameter ändern, um auf die medizinischen Aufzeichnungen eines anderen Patienten zuzugreifen. Beispielsweise meldet sich der Patient Steve im Patientenportal an, um seine medizinischen Aufzeichnungen einzusehen. Seine Aufzeichnungen sind über die URL https://healthportal.com/patient/123 zugänglich. Aus Neugier ändert Steve die URL auf https://healthportal.com/patient/124 und stellt fest, dass er nun die medizinischen Aufzeichnungen eines anderen Patienten einsehen kann. Dies stellt einen erheblichen Datenschutzverstoß dar und verstößt gegen Vorschriften wie den Health Insurance Portability and Accountability Act (HIPAA).

Empfehlung: Implementieren Sie einen geeigneten Autorisierungsmechanismus, der auf Benutzerrichtlinien und Hierarchien basiert. Das APISIX-Gateway unterstützt OAuth2- oder JWT-basierte Autorisierungsabläufe mithilfe von Plugins. Sie können die OAuth2-Richtlinie verwenden, um das Token bei jeder Anfrage zu überprüfen.

Verwenden Sie fein abgestimmte Zugriffskontrollen durch das APISIX Role-Based Access Control (RBAC)-System, indem Sie es mit Open Policy Agent (OPA) integrieren. Durch die Einrichtung spezifischer Rollen und Berechtigungen in APISIX und die Zuordnung dieser Rollen zu bestimmten Benutzern oder Token können Sie sicherstellen, dass Anfragen an sensible Endpunkte ordnungsgemäß autorisiert sind.

2. Broken Authentication

Bedrohung: Falsch implementierte Authentifizierungsmechanismen können es Angreifern ermöglichen, Authentifizierungstoken zu kompromittieren oder einfach einen Brute-Force-Angriff auf Login-Endpunkte durchzuführen, da keine Ratenbegrenzung vorhanden ist.

Beispiel: Das Bankensystem hat einen benutzerdefinierten Authentifizierungsmechanismus implementiert. Aufgrund mangelnder Sicherheitsüberprüfung und -tests gab es jedoch eine Schwachstelle im Authentifizierungsablauf. Konkret wurde nach der Eingabe von Benutzername und Passwort ein vorhersehbares Sitzungstoken generiert, wie eine Kombination aus Benutzername und Zeitstempel. Ein Angreifer, der diesen Fehler kannte, konnte leicht das Sitzungstoken eines anderen Benutzers vorhersagen.

Empfehlung: Verstehen Sie zunächst alle möglichen Authentifizierungsabläufe zur API und erfinden Sie das Rad bei der Authentifizierung nicht neu! APISIX unterstützt den standardmäßigen OpenID Connect (OIDC)-Autorisierungsablauf. Anstelle von vorhersehbaren Sitzungstoken kann APISIX mit externen Identitätsanbietern wie Keycloak oder Sitzungsverwaltungssystemen mithilfe von Plugins integriert werden, um sicherzustellen, dass Sitzungstoken zufällig, verschlüsselt und mit begrenzter Lebensdauer sind.

Um Brute-Force-Angriffe auf Benutzerkonten zu verhindern, kann das Rate-Limiting-Plugin von APISIX verwendet werden. Dies stellt sicher, dass bei mehreren fehlgeschlagenen Anmeldeversuchen in kurzer Zeit die IP oder der Benutzer vorübergehend gesperrt wird. Um die Datensicherheit und -integrität zu gewährleisten, unterstützt APISIX SSL/TLS-Verschlüsselung. Dadurch wird sichergestellt, dass Benutzeranmeldeinformationen und andere sensible Daten während der Übertragung verschlüsselt sind.

3. Broken Object Property Level Authorization

Bedrohung: Diese Bedrohung entsteht durch das Fehlen oder die unsachgemäße Validierung der Autorisierung auf Objekteigenschaftsebene, was zu unbefugter Informationspreisgabe oder Manipulation führen kann.

Beispiel: Die API einer Online-Einkaufsplattform ermöglicht es registrierten Benutzern, ihre Profildetails wie Name, E-Mail, Lieferadresse und Zahlungsdetails zu aktualisieren. Zusätzlich hat jedes Benutzerprofil eine Eigenschaft namens userType, die entweder regular oder admin sein kann. Aufgrund eines Problems im API-Design können Benutzer auch die Eigenschaft userType in ihren Profilaktualisierungsanfragen ändern. Angenommen, die reguläre Benutzerin Alice entdeckt diesen Fehler, als sie die API-Anfragen mit den Entwicklertools ihres Browsers untersucht. Sie stellt fest, dass beim Aktualisieren ihres Profils ein JSON-Payload an den Server gesendet wird. Alice ändert den Wert von userType auf admin und sendet die Anfrage. Zu ihrer Überraschung wird ihr Profil aktualisiert, und sie hat nun administrative Berechtigungen auf der Plattform, was ihr Zugriff auf sensible Daten, die Änderung von Produktlisten und sogar die Einsicht in die Bestellhistorie anderer Benutzer ermöglicht.

Empfehlung: Stellen Sie sicher, dass die exponierten Objekteigenschaften für den Benutzer zugänglich sind und halten Sie die zurückgegebenen Datenstrukturen basierend auf den Geschäftsanforderungen minimal. Um dies zu erreichen, können Sie das Request-Validation-Plugin von APISIX verwenden, das eingehende Anfragen gegen ein vordefiniertes Schema validieren kann. Oder verwenden Sie das RBAC-System von APISIX, um Rollen für reguläre Benutzer und Administratoren einzurichten. Um unnötige Daten, die dem Client exponiert werden, zu entfernen, bietet APISIX ein Response-Rewrite-Plugin, das die API-Antwort dynamisch ändern kann.

4. Unrestricted Resource Consumption

Bedrohung: Angreifer können APIs ausnutzen, um übermäßige Ressourcen zu verbrauchen, was zu Denial-of-Service-Angriffen oder erhöhten Betriebskosten führen kann.

Beispiel: Ein cloudbasierter Dateispeicherdienst ermöglicht es Benutzern, Dateien hochzuladen und zu speichern, sie mit anderen zu teilen und von überall darauf zuzugreifen. Der Dienst hat keine Einschränkungen hinsichtlich der Anzahl der Dateien, die ein Benutzer gleichzeitig hochladen kann, oder der Größe jeder Datei. Infolgedessen kann ein böswilliger Benutzer oder ein Bot eine enorme Anzahl extrem großer Dateien in schneller Folge hochladen, was erhebliche Serverressourcen verbraucht. Dies kann zu langsameren Antwortzeiten für andere Benutzer, potenziellen Serverabstürzen und erhöhten Infrastrukturkosten für den Dienstanbieter führen.

Empfehlung:

• Definieren und erzwingen Sie maximale Datengrößen für alle eingehenden Parameter und Payloads. Verwenden Sie das Client-Control-Plugin, um die maximale Größe des Anfragekörpers festzulegen, damit Benutzer keine übermäßig großen Dateien hochladen können. Oder verwenden Sie das Request-Validation-Plugin, um Abfragezeichenfolgen zu validieren, insbesondere solche, die die Anzahl der zurückgegebenen Datensätze steuern. Um einen Bot, ein Skript oder einen Benutzeragenten daran zu hindern, unerwünschte Daten zu senden, können Sie das UA-Restriction-Plugin nutzen.
• Implementieren Sie Rate Limiting basierend auf den Geschäftsanforderungen. APISIX bietet Limit-Req, Limit-Conn und Limit-Count-Plugins, die die Rate begrenzen können, mit der ein einzelner Benutzer oder eine IP-Adresse Anfragen stellen kann. Dadurch wird sichergestellt, dass Benutzer das System nicht mit einer großen Anzahl schneller Anfragen überfluten können.

5. Broken Function Level Authorization

Bedrohung: Zugriffskontrollrichtlinien sind manchmal zu komplex, mit verschiedenen Ebenen, Gruppen und Rollen, und eine unscharfe Unterscheidung zwischen administrativen und standardmäßigen Funktionen führt oft zu Berechtigungsschwachstellen. Angreifer können diese Schwächen ausnutzen, um auf Ressourcen anderer Benutzer oder administrative Funktionen zuzugreifen.

Beispiel: Eine Online-Lernplattform bietet verschiedene Kurse für Studenten an. Aufgrund von Problemen im Design der Plattform können Studenten durch die Manipulation von URLs oder API-Endpunkten auf Funktionen zugreifen, die nur für Dozenten bestimmt sind. Beispielsweise könnte ein Student feststellen, dass er durch die Änderung der URL von /student/dashboard auf /instructor/dashboard auf das Dashboard des Dozenten zugreifen kann, was ihm ermöglicht, Kursinhalte zu ändern, Aufgaben zu bewerten oder sogar Kurse hinzuzufügen/zu entfernen.

Empfehlung:

• Verweigern Sie standardmäßig allen Zugriff und erfordern Sie explizite Genehmigungen für bestimmte Rollen. Mit APISIX können Sie einen Consumer oder eine Gruppe von Consumern erstellen, um unterschiedliche Zugriffskontrollen für Benutzer zu gewähren. Dann kann das JWT-Authentifizierungs-Plugin so konfiguriert werden, dass Rolleninformationen im JWT-Token enthalten sind. Wenn ein Benutzer sich anmeldet, enthält das JWT-Token, das er erhält, seine Rolle (student oder instructor). APISIX kann dann die Rolle des Benutzers aus dem JWT-Token überprüfen, bevor der Zugriff auf bestimmte Funktionen gewährt wird.
• Stellen Sie sicher, dass administrative Controller von einem Controller erben, der Autorisierungsprüfungen basierend auf Benutzerrollen implementiert. Wenn Sie API7 Enterprise verwenden, können Administratoren den API-Zugriff auf bestimmte Benutzer/Gruppen beschränken und Sie können den Zugriff auf Basis von Anfragen und Benutzern einrichten.

6. Unrestricted Access to Sensitive Business Flows

Bedrohung: Sensible Geschäftsabläufe werden ohne Risikobewertung exponiert, wie die Funktionalität dem Unternehmen schaden könnte, wenn sie in automatisierter und übermäßiger Weise verwendet wird.

Beispiel: Mit einer Kombination aus Proxys und automatisierten Skripten (Bots) simuliert der Angreifer mehrere echte Benutzer, die Einkäufe tätigen. Das Skript fügt das Produkt schnell dem Warenkorb hinzu und schließt den Kaufprozess ab, wodurch der Bestand erschöpft wird, bevor echte Kunden die Möglichkeit haben, einen Kauf zu tätigen. Der Angreifer verkauft diese Produkte dann zu einem höheren Preis auf anderen Plattformen weiter. Die Verkaufsplattform verliert potenzielle Einnahmen, da sie die Produkte nicht zu dem beabsichtigten Preis an echte Kunden verkaufen kann.

Empfehlung:

• Implementieren Sie Geräte-Fingerprinting, um den Dienst für unerwartete Client-Geräte zu verweigern. APISIX kann mit Identitäts- und Zugriffsverwaltungsplattformen wie Auth0, Authgear und so weiter integriert werden, um verschiedene Authentifizierungsmechanismen einschließlich biometrischer Anmeldefunktionen auf Geräten zu ermöglichen.
• Verwenden Sie menschliche Erkennungsmechanismen wie Captchas oder fortschrittliche biometrische Lösungen. Das Gleiche wie oben.
• Analysieren Sie den Benutzerfluss, um nicht-menschliche Muster zu erkennen. Sie können API7 Enterprise verwenden, um zusätzliche Authentifizierungsfaktoren zu erzwingen, wenn eine Anfrage mit nicht-menschlichen Mustern verbunden ist, wie z.B. hohe Geschwindigkeiten zwischen verschiedenen Anmeldeorten oder die Erkennung von Bots.
• Blockieren Sie IP-Adressen bekannter bösartiger Quellen. APISIX verfügt über ein IP-Restriction-Plugin, um den Zugriff von einzelnen oder mehreren IP-Adressen zu blockieren.

7. Server Side Request Forgery (SSRF)

Bedrohung: SSRF-Angriffe ermöglichen es einem Angreifer, Anfragen an interne Ressourcen des Servers zu stellen, wodurch potenziell Zugriff auf interne Netzwerke, Dateisysteme oder sogar die Ausführung von Befehlen erlangt werden kann. Dies geschieht, wenn ein API-Endpunkt eine URL oder einen Teil davon als Eingabe akzeptiert und sie ohne ordnungsgemäße Validierung abruft.

Beispiel: Ein API-Endpunkt akzeptiert eine URL, um ein Bild aus dem Internet abzurufen. Ein böswilliger Benutzer sendet eine URL wie http://169.254.169.254/latest/meta-data/ (ein typischer Metadaten-Endpunkt in Cloud-Umgebungen). Der Dienst ruft die URL ab, denkt, es sei ein Bild, ruft aber stattdessen sensible Daten wie IAM-Rollen, geheime Schlüssel oder andere interne Konfigurationsdetails ab. Der Angreifer verwendet diese Informationen dann für weitere Angriffe, wie z.B. Rechteerweiterung oder Datenlecks.

Empfehlung:

• Eingabevalidierung - Validieren und bereinigen Sie immer Eingaben. Vermeiden Sie es, vollständige URLs aus nicht vertrauenswürdigen Quellen zu akzeptieren. Mit APISIX können Sie ein URI-Blocker-Plugin einrichten, um Blockierungsregeln für interne Ressourcen anzuwenden.
• Whitelisting - Erlauben Sie nur Verbindungen zu bekannten und vertrauenswürdigen Domänen oder IPs. Das Gleiche können Sie mit dem IP-Restriction-Plugin von APISIX tun oder Referer-Restriction für eine Whitelist akzeptabler Domänen oder URL-Muster aktivieren. Jede URL, die nicht der Whitelist entspricht, wird abgelehnt.
• Netzwerksegmentierung - Stellen Sie sicher, dass Ihre Server segmentiert sind und sensible interne Ressourcen nicht direkt zugänglich sind.

8. Security Misconfiguration

Bedrohung: Dies tritt auf, wenn eine API nicht sicher konfiguriert ist, was potenziell sensible Informationen preisgibt oder unnötige Berechtigungen gewährt. Beispiele sind Protokollierungsfehlermeldungen, die Serverdetails offenlegen, unnötige HTTP-Methoden, die aktiviert sind, oder Standardanmeldeinformationen, die unverändert gelassen wurden.

Beispiel: Ein einfaches Beispiel könnte eine API sein, die versehentlich ein .git-Verzeichnis offenlegt, was den Quellcode und die Commit-Historie preisgibt. Ein anderes Beispiel: Ein böswilliger Benutzer stößt bei der Nutzung Ihrer Plattform auf eine Fehlermeldung. Anstatt einer generischen Fehlermeldung sieht er eine detaillierte Stack-Trace, die die Datenbankstruktur, Softwareversionen und Dateipfade offenlegt. Mit diesen Informationen identifiziert er potenzielle Schwachstellen in der Plattform. Zusätzlich versucht er, sich mit dem Testkonto anzumelden, und hat Erfolg, wodurch er administrativen Zugriff erhält.

Empfehlung:

• Regelmäßige Audits - Überprüfen und aktualisieren Sie regelmäßig Konfigurationen. Verwenden Sie automatisierte Tools, um nach häufigen Fehlkonfigurationen zu scannen. Mit den Logging-Plugins von APISIX werden alle Zugriffs- und Systemaktivitäten protokolliert. Ungewöhnliche Aktivitäten, wie wiederholte fehlgeschlagene Anmeldeversuche oder Zugriffe auf eingeschränkte Endpunkte, können zur Überprüfung gekennzeichnet werden.
• Prinzip der geringsten Rechte - Gewähren Sie nur notwendige Berechtigungen und vermeiden Sie übermäßig permissive Einstellungen.
• Standardmäßige Sicherheitsheader - APISIX erzwingt sichere Standardeinstellungen mit wesentlichen Sicherheitsheadern wie Content Security Policy (CSP) und HTTP Strict Transport Security (HSTS), die festgelegt sind. Dies reduziert das Risiko bestimmter webbasierter Angriffe.
• Fehlermaskierung - Stellen Sie sicher, dass Fehlermeldungen generisch sind und keine sensiblen Informationen preisgeben. APISIX kann so konfiguriert werden, dass detaillierte Fehlermeldungen mit dem Response-Rewrite-Plugin oder einem benutzerdefinierten Data-Mask-Plugin maskiert werden.

9. Improper Inventory Management

Bedrohung: Wenn Organisationen wachsen, verlieren sie oft den Überblick über alle ihre APIs, insbesondere wenn es keine zentrale Verwaltung gibt. Dies kann zu vergessenen, veralteten oder ungeschützten APIs führen, die ausgenutzt werden können.

Beispiel: Es ist üblich, dass mehrere Versionen von APIs unbeaufsichtigt bleiben. Angreifer könnten veraltete API-Versionen oder ungepatchte Zugriffspunkte ins Visier nehmen. Sie können auch unbefugten Zugriff über Schwachstellen in Drittanbieterverbindungen erlangen.

Empfehlung: Verwenden Sie die Admin API von APISIX, um regelmäßig Routen zu überprüfen und zu deaktivieren, die nicht mehr benötigt werden, und um alle API-Versionen zu verfolgen, ohne Client-Apps zu stören. Das API7 Portal bietet ein zentrales Management-Dashboard, in dem alle APIs überwacht und verwaltet werden können. Eine alte Version einer API könnte noch aktiv sein und wird nicht mehr verwendet. Über das Dashboard kann diese API identifiziert und ohne Codeänderungen im Backend-Service selbst abgeschaltet werden.

10. Unsafe Consumption of APIs

Bedrohung: Bei der Integration von Drittanbieter-APIs oder sogar beim Verbrauch interner APIs kann die Anwendung Schwachstellen in den Upstream-APIs ausgesetzt werden, wenn dies nicht sicher erfolgt.

Beispiel: Stellen Sie sich eine mobile Anwendung vor, die es Benutzern ermöglicht, ihre Gesundheitsmetriken wie Herzfrequenz, Schlafmuster und körperliche Aktivität zu überwachen. Die Anwendung hat keine strengen Validierungs- und Sicherheitsprüfungen, wenn sie diese Drittanbieter-APIs verbraucht. Ein Angreifer stellt fest, dass eine der integrierten APIs für Ernährungstracker anfällig ist und bösartige Daten zurückgeben kann. Wenn die Anwendung Mahlzeitenvorschläge von dieser API abruft, verarbeitet sie unwissentlich bösartige Payloads, was zu potenziellen Datenlecks oder Anwendungsfehlfunktionen führen kann.

Empfehlung: Überprüfen Sie vor der Integration einer Drittanbieter-API, ob sie von einer seriösen Quelle stammt und Sicherheitsbewertungen durchlaufen hat.

• Fehlerbehandlung - Behandeln Sie unerwartete Antworten oder Verhaltensweisen von verbrauchten APIs, ohne Schwachstellen preiszugeben.
• Datenvalidierung - Validieren und bereinigen Sie immer Daten, die von Drittanbieter-APIs empfangen werden. APISIX kann mit Web Application Firewalls (WAF) integriert werden, um eingehende Daten von Drittanbieter-APIs zu überprüfen und zu filtern. Dies kann bekannte bösartige Muster oder Payloads erkennen und blockieren. Es ist auch möglich, TLS/mTLS zu aktivieren für Upstream-Dienste, um die Sicherheit des Datenverkehrs zu gewährleisten, während er durch das interne Netzwerk fließt.

Zusammenfassung

Die Anwendung der vorgeschlagenen Sicherheitsrichtlinien von OWASP API 2023 bietet einen grundlegenden Ausgangspunkt für die Absicherung von APIs. Die Verwendung der Funktionen des APISIX-Gateways vereinfacht diesen Prozess und reduziert die Kosten für die Implementierung der von OWASP empfohlenen Präventionsmechanismen erheblich.

Verwandte Ressourcen

• Sichere APIs in einem API-Gateway
• API-Gateway-Authentifizierung
• Verhindern Sie das Auslaufen sensibler Daten im API-Gateway