API-Sicherheitslücken in der Praxis: Vom Server-Side Request Forgery bis zur Autorisierung

In der modernen Softwareentwicklung spielen APIs eine zentrale Rolle. Sie bilden das Rückgrat zahlreicher Anwendungen und ermöglichen die nahtlose Kommunikation zwischen verschiedenen Systemen. Doch was passiert, wenn APIs unsicher implementiert werden? Die Folgen können verheerend sein – von Datenlecks bis hin zur vollständigen Kompromittierung von Systemen.

Dieser Artikel beleuchtet die sieben kritischsten API-Sicherheitsschwachstellen basierend auf der OWASP API Security Top 10 und zeigt anhand praktischer Beispiele, wie Entwickler diese Schwachstellen erkennen und beheben können.

Die OWASP API Security Top 10 als Ausgangspunkt

Die OWASP (Open Web Application Security Project) hat vor einigen Jahren erkannt, dass die herkömmliche Top-10-Liste für Webanwendungen nicht ausreichend auf die spezifischen Sicherheitsanforderungen von APIs eingeht. Daher wurde eine separate Liste für API-Sicherheit entwickelt, die regelmäßig aktualisiert wird.

Wichtig zu verstehen: Diese Liste ist kein Checklisten-Ansatz nach dem Motto "Wenn alle Punkte abgehakt sind, ist die API sicher". Vielmehr dient sie als Sensibilisierungsdokument und Ausgangspunkt für Entwickler, die sich mit API-Sicherheit beschäftigen möchten.

1. Server-Side Request Forgery (SSRF): Wenn interne Systeme plötzlich erreichbar werden

Das Problem verstehen

Server-Side Request Forgery (SSRF) ist eine Schwachstelle, bei der Angreifer die Kontrolle über die Ziele von serverseitigen Anfragen erlangen können. Dies ermöglicht ihnen potenziell den Zugriff auf:

• Dienste auf localhost
• Interne Server
• Interne APIs
• Metadatendienste in Cloud-Umgebungen

Die besondere Gefahr bei SSRF liegt darin, dass sie Angreifern ermöglicht, die Netzwerkgrenzen zu überschreiten und interne Systeme zu erreichen, die normalerweise nicht von außen zugänglich sind.

Der Dropbox-Fall

Ein bekanntes Beispiel für SSRF trat bei Dropbox auf. Obwohl Dropbox über ein robustes Sicherheitsprogramm verfügt, entdeckte ein ethischer Hacker eine SSRF-Schwachstelle. Das Problem: Die Anwendung akzeptierte URLs als Eingabe für das Laden von Bildern.

Der Code, der die URL-Ziele überprüfte, nutzte die URL-Interpretation von Python, während der tatsächliche Request mit libcurl gesendet wurde – zwei Bibliotheken mit unterschiedlichen Interpretationen von mehrdeutigen URLs.

Wie tritt SSRF auf?

SSRF-Schwachstellen entstehen typischerweise, wenn Anwendungen URLs als Eingabe akzeptieren, wie bei:

• Webhooks
• Link-Vorschauen
• Bildladen von externen Quellen

Ein besonders tückisches Problem stellt die unterschiedliche Interpretation von mehrdeutigen URLs durch verschiedene URL-Parser dar. Ein Beispiel:

https://google.com@evil.com

Diese URL wird von manchen Parsern als Anfrage an google.com interpretiert, während andere sie als Anfrage an evil.com verstehen – ein perfektes Szenario für einen SSRF-Angriff.

Lösungsansatz für SSRF

Die beste Verteidigung gegen SSRF besteht darin, Mehrdeutigkeiten zu beseitigen:

1. Die ursprüngliche, unvertrauenswürdige URL parsen
2. Eine neue, eindeutige URL mit festgelegtem Schema (https) rekonstruieren
3. Diese neue URL für die Prüfung und den tatsächlichen Request verwenden

Dieser Ansatz verhindert, dass Angreifer die unterschiedlichen Interpretationen verschiedener Parser ausnutzen können.

2. Broken Authentication: Die Kunst des Passwort-Zurücksetzens

Das Smart-Scale-Beispiel

Eine erschreckend häufige Schwachstelle in der API-Sicherheit betrifft die Authentifizierung. Am Beispiel einer "Smart Scale" (intelligente Waage) wurde deutlich, wie leicht Angreifer Passwörter zurücksetzen und fremde Konten übernehmen können.

Die Schwachstelle: Die App verwendete einen 6-stelligen numerischen Code für das Zurücksetzen von Passwörtern – ein klassisches Beispiel für einen zu schwachen Sicherheitsmechanismus.

Username Enumeration: Der erste Schritt

Bevor ein Angreifer ein Passwort zurücksetzen kann, muss er gültige Benutzernamen identifizieren. Dies wird durch Timing-Angriffe möglich:

1. Bei falschen Benutzernamen antwortet das System sofort
2. Bei korrekten Benutzernamen mit falschem Passwort dauert die Antwort länger (wegen der bcrypt-Passwortverifizierung)

Diese Zeitdifferenz ermöglicht Angreifern, gültige Benutzerkonten zu identifizieren.

Brute-Force des Reset-Codes

Nachdem ein gültiger Benutzername gefunden wurde, kann der Angreifer:

1. Einen Passwort-Reset für diesen Benutzer auslösen
2. Den 4- oder 6-stelligen Reset-Code durch systematisches Ausprobieren aller möglichen Kombinationen erraten
3. Das Passwort des Benutzers ändern und das Konto übernehmen

Lösungen für sichere Authentifizierung

Um diese Schwachstellen zu beheben, sollten Entwickler:

1. Timing-Angriffe verhindern: Immer eine Passwort-Hash-Berechnung durchführen, auch wenn der Benutzer nicht existiert
2. Rate-Limiting implementieren: Brute-Force-Angriffe durch Begrenzung der Anfragehäufigkeit erschweren
3. Sichere Tokens verwenden: Statt kurzer numerischer Codes signierte Tokens (wie JWTs) mit eingebetteter Benutzer-ID verwenden

3. Broken Object Level Authorization: Der häufigste API-Sicherheitsfehler

Das Grundproblem

Broken Object Level Authorization (BOLA) steht auf Platz 1 der OWASP API Security Top 10 – und das aus gutem Grund. Diese Schwachstelle tritt auf, wenn eine API zwar prüft, ob ein Benutzer generell eine bestimmte Aktion ausführen darf, aber nicht verifiziert, ob er auf ein spezifisches Objekt zugreifen darf.

Beispiel:

• Ein Benutzer darf grundsätzlich Familienmitglieder hinzufügen
• Die API prüft jedoch nicht, ob der Benutzer zur spezifischen Familie gehört, die er modifizieren will

Der simple Angriff

Der Angriff ist erschreckend einfach: Der Angreifer muss lediglich die ID im Request ändern (z.B. von "family_id=1" zu "family_id=7"), und schon kann er Aktionen auf fremden Objekten ausführen.

Die Herausforderung der Implementierung

Die Implementierung einer korrekten objektbezogenen Autorisierung ist komplex:

// Problematischer Ansatz mit zu viel Logik im Endpunkt
if (hasPermission(user, "add_family_member")) {
  if ((user.hasRole("family_owner") || user.hasRole("parent")) 
      && user.isMemberOf(family)) {
    // Aktion erlauben
  } else {
    throw new ForbiddenException();
  }
}

Solche verteilten Autorisierungsregeln:

• Sind schwer zu warten
• Führen zu Code-Duplizierung
• Können nicht effektiv auditiert werden

Die Lösung: Policy-Zentralisierung

Der bessere Ansatz ist die Zentralisierung der Autorisierungslogik:

// Sauberer Ansatz
if (policyEngine.checkPermission(user, "add_family_member", family)) {
  // Aktion erlauben
} else {
  throw new ForbiddenException();
}

Für komplexere Anforderungen können spezielle Policy-Engines wie Open Policy Agent (OPA) eingesetzt werden.

4. Unrestricted Resource Consumption: Die Bedeutung von Rate-Limiting

Ein weiterer kritischer Aspekt der API-Sicherheit ist der Schutz vor übermäßigem Ressourcenverbrauch. Ohne angemessenes Rate-Limiting können Angreifer APIs überlasten oder Brute-Force-Angriffe durchführen.

Besonders wichtig ist Rate-Limiting bei:

• Authentifizierungsendpunkten
• Passwort-Reset-Funktionen
• Ressourcenintensiven Operationen

Zu beachten ist jedoch, dass Rate-Limiting zwar eine wichtige Verteidigungslinie darstellt, aber allein nicht ausreicht. Fortgeschrittene Angreifer können durch verteilte Angriffe von verschiedenen IPs Rate-Limiting-Mechanismen umgehen.

5. Broken Function Level Authorization: Berechtigungen richtig prüfen

Rollenbasierte Zugriffssteuerung und ihre Grenzen

Die traditionelle rollenbasierte Zugriffssteuerung (RBAC) kann zu Problemen führen:

• Rollenexplosion: Eine Vielzahl von Rollen mit leicht unterschiedlichen Berechtigungen
• Hardcodierte Logik: Autorisierungsregeln direkt im Code, die bei Änderungen angepasst werden müssen
• Mangelnde Flexibilität: Schwierigkeiten bei der Anpassung an neue Anforderungen

Der Permissions-basierte Ansatz

Ein besserer Ansatz ist die Verwendung von Permissions als Abstraktionsschicht zwischen Rollen und Endpunkten:

1. Permissions werden mit Endpunkten verknüpft
2. Rollen werden mit Permissions verknüpft
3. Die Codelogik prüft nur noch auf Permissions, nicht auf Rollen

Diese Entkopplung macht das System wartbarer und ermöglicht eine präzisere Kontrolle der Berechtigungen.

6. Broken Object Property Level Authorization (BOPLA): Datenlecks vermeiden

Excessive Data Exposure

Ein häufiges Problem bei APIs ist die übermäßige Datenexposition. APIs geben oft mehr Daten zurück, als die Frontend-Anwendung tatsächlich benötigt:

// API gibt zurück:
{
  "users": [
    {
      "id": 1,
      "name": "John",
      "email": "john@example.com",
      "address": "123 Main St",
      "creditCard": "1234-xxxx-xxxx-xxxx"
    }
  ]
}

// Frontend zeigt nur an:
// Name: John

Ein Angreifer kann durch einfaches Untersuchen der API-Antworten sensible Daten wie Adressen oder Kreditkarteninformationen abgreifen.

Die Lösung: DTOs und Schema-Validierung

Statt direkt Domain-Objekte in API-Antworten zu serialisieren, sollten Entwickler:

1. Data Transfer Objects (DTOs) verwenden, die nur die notwendigen Daten enthalten
2. Ausdrucksstarke Namen wie PublicUserInfo verwenden, die den Zweck und Sicherheitskontext verdeutlichen
3. Schema-Validierung einsetzen, um sicherzustellen, dass keine unerwünschten Daten durchsickern

7. Perimeter-Sicherheit ist nicht genug

Die letzte, aber nicht minder wichtige Lektion: Vertrauen Sie niemals allein auf Ihre Perimeter-Sicherheit. Es ist verlockend anzunehmen, dass interne Systeme nicht gesichert werden müssen, weil sie "hinter der Firewall" sind.

Die Realität zeigt jedoch:

• Perimeter werden irgendwann durchbrochen
• SSRF-Angriffe können interne Systeme erreichen
• Insider-Bedrohungen existieren

Eine robuste Sicherheitsstrategie muss davon ausgehen, dass der Perimeter kompromittiert werden kann, und entsprechende Verteidigungsmaßnahmen für alle Systeme vorsehen.

Fazit: API-Sicherheit als kontinuierlicher Prozess

API-Sicherheit ist kein einmaliges Projekt, sondern ein kontinuierlicher Prozess. Die OWASP API Security Top 10 bietet einen wertvollen Ausgangspunkt, aber keine vollständige Checkliste. Entwickler müssen:

1. Die spezifischen Bedrohungen für ihre APIs verstehen
2. Auditierbare Sicherheitsmaßnahmen implementieren
3. Regelmäßige Sicherheitsüberprüfungen durchführen
4. Sicherheitsmaßnahmen an neue Bedrohungen anpassen

Nur durch diesen ganzheitlichen Ansatz können APIs wirksam gegen die vielfältigen Bedrohungen der heutigen Cyberlandschaft geschützt werden.

FAQ

Welche API-Sicherheitsschwachstelle wird am häufigsten ausgenutzt?

Broken Object Level Authorization (BOLA) ist die am häufigsten ausgenutzte API-Sicherheitsschwachstelle. Sie ermöglicht Angreifern, auf Daten zuzugreifen, für die sie keine Berechtigung haben, indem sie einfach Objekt-IDs in Anfragen manipulieren. Diese Schwachstelle steht an erster Stelle der OWASP API Security Top 10.

Wie kann die Autorisierungslogik in APIs verbessert werden?

Die Autorisierungslogik sollte zentralisiert werden, um Auditierbarkeit und Wartbarkeit zu verbessern. Statt verstreuter Berechtigungsprüfungen im Code sollte eine zentrale Policy-Engine verwendet werden. Für komplexere Anforderungen können spezialisierte Tools wie Open Policy Agent (OPA) eingesetzt werden. Entscheidend ist die klare Trennung zwischen funktionaler und objektbezogener Autorisierung.

Welche einfachen Maßnahmen können das Sicherheitsniveau von APIs sofort verbessern?

Drei unmittelbar wirkende Maßnahmen zur Verbesserung der API-Sicherheit sind:

1. Implementierung von Rate-Limiting auf allen Endpunkten, besonders bei Authentifizierungsfunktionen.
2. Verwendung von signierten Tokens statt einfacher Codes für sensible Operationen wie Passwort-Resets.
3. Einführung von Data Transfer Objects (DTOs), um die übermäßige Exposition von Daten zu verhindern.