VenedyThreat agents/Attack vectors: API Specific, Exploitability Average (Durchschnittlich). Security Weakness: Prevalence Widespread (Weit verbreitet), Detectability Easy (Leicht). Impacts: Technical Severe (Schwerwiegend), Business Specific (Anwendungsspezifisch).
Wie der Angriff funktioniert
Jede API-Anfrage verbraucht Ressourcen (Netzwerk, CPU, Speicher, Storage), und manche lösen kostenpflichtige Aufrufe bei Drittanbietern aus (z. B. SMS-Versand, Biometrie-Prüfung).
Eine API ist verwundbar, wenn mindestens eine sinnvolle Begrenzung fehlt oder falsch (zu hoch/niedrig) gesetzt ist - etwa:
- Ausführungs-Timeouts
- Maximal zuweisbarer Speicher
- Maximale Anzahl an Dateideskriptoren/Prozessen
- Maximale Upload-Dateigröße
- Anzahl der Operationen pro Anfrage (z. B. GraphQL-Batching)
- Anzahl der Datensätze pro Seite
- Ausgabenlimits bei Drittanbietern
Der Angriff selbst erfordert nur einfache API-Anfragen: Der Angreifer schickt viele gleichzeitige oder massenhaft wiederholte Anfragen - von einem einzelnen lokalen Rechner oder mithilfe von Cloud-Ressourcen.
Die Schwachstelle lässt sich leicht aufspüren, indem man Parameter manipuliert, die die Menge zurückgegebener Ressourcen steuern, und Antwortstatus, -zeit und -länge analysiert; gleiches gilt für Batch-Operationen.
Mangels Limits eskaliert der Ressourcen- bzw. Kostenverbrauch ungebremst.
Fehlende Limits führen zu Überlast und Kosten.
Beispiel
OWASP Szenario 1 (SMS-basierter "Passwort vergessen"-Flow): Ein soziales Netzwerk versendet bei Passwort-Reset einen Einmal-Token per SMS. Beim Klick auf "Passwort vergessen" sendet der Browser:
POST /initiate_forgot_passwordmit dem Rumpf{ "step": 1, "user_number": "6501113434" }- Im Hintergrund ruft das Backend einen SMS-Drittanbieter auf:
POST /sms/send_reset_pass_codeanHost: willyo.netmit dem Rumpf{ "phone_number": "6501113434" } - Der Anbieter Willyo berechnet 0,05 USD pro Aufruf. Ein Angreifer schreibt ein Skript, das den ersten API-Aufruf zehntausende Male absendet.
- Das Backend folgt jedem Aufruf und beauftragt Willyo mit dem Versand zehntausender SMS - das Unternehmen verliert innerhalb weniger Minuten tausende Dollar.
Auswirkung
Ausnutzung kann zu Denial of Service durch Ressourcenerschöpfung führen (der Dienst wird für legitime Nutzer unverfügbar).
Ebenso kann sie die Betriebskosten in die Höhe treiben - etwa durch höhere CPU-Last in der Infrastruktur oder wachsenden Cloud-Speicherbedarf.
Beispiel aus OWASP Szenario 3: Eine monatliche Cloud-Rechnung steigt mangels Kostenlimit/-Warnung von durchschnittlich 13 USD auf 8.000 USD, nachdem eine zwischengespeicherte Datei von 15 GB auf 18 GB anwächst und damit aus dem Cache fällt.
Die geschäftliche Auswirkung (Business Impact) ist anwendungsspezifisch (OWASP-Rating Business: Specific).
So schützt man sich
- Eine Lösung einsetzen, die das Begrenzen von Speicher, CPU, Anzahl der Neustarts, Dateideskriptoren und Prozessen erleichtert - etwa Container oder Serverless-Code (z. B. Lambdas).
- Eine maximale Datengröße für alle eingehenden Parameter und Payloads definieren und durchsetzen: maximale String-Länge, maximale Anzahl an Array-Elementen und maximale Upload-Dateigröße (egal ob lokal oder in der Cloud gespeichert).
- Rate Limiting einführen: begrenzen, wie oft ein Client innerhalb eines definierten Zeitraums mit der API interagieren darf.
- Rate Limiting an den fachlichen Bedarf anpassen (fein justieren); einzelne Endpunkte können striktere Richtlinien erfordern.
- Begrenzen/drosseln, wie oft ein einzelner Client/Nutzer eine einzelne Operation ausführen darf (z. B. OTP validieren oder Passwort-Reset anfordern, ohne die Einmal-URL zu besuchen).
- Serverseitige Validierung für Query-String- und Request-Body-Parameter ergänzen, insbesondere für den Parameter, der die Anzahl der zurückgegebenen Datensätze steuert.
- Ausgabenlimits für alle Drittanbieter/API-Integrationen konfigurieren; wo das nicht möglich ist, stattdessen Abrechnungs-Warnungen (Billing Alerts) einrichten.