Coders Conquer Security OWASP Top 10 API-Serie – Fehlende Ressourcenbeschränkung und Ratenbegrenzung

Bei fehlenden Ressourcen und mangelndem Rate Limiting ist die API-Schwachstelle genau das, was der Name vermuten lässt. Jede API verfügt je nach Umgebung über begrenzte Ressourcen und Rechenleistung. Die meisten müssen zudem Anfragen von Benutzern oder anderen Programmen verarbeiten, um ihre Funktion zu erfüllen. Diese Schwachstelle tritt auf, wenn zu viele Anfragen gleichzeitig eingehen und die API nicht über genügend Rechenressourcen verfügt, um diese zu verarbeiten. Die API kann dann nicht mehr verfügbar sein oder auf neue Anfragen nicht mehr reagieren.

APIs werden anfällig für dieses Problem, wenn ihre Raten- oder Ressourcenbegrenzungen nicht korrekt konfiguriert sind oder im Code undefiniert bleiben. Eine API kann überlastet werden, wenn ein Unternehmen beispielsweise eine besonders geschäftige Phase erlebt. Es handelt sich jedoch auch um eine Sicherheitslücke, da Angreifer ungeschützte APIs gezielt mit Anfragen überfluten können, um Denial-of-Service-Angriffe (DDoS) durchzuführen.

Wie kommen Sie eigentlich bisher mit den gamifizierten API-Challenges voran? Wenn Sie Ihre Fähigkeiten im Umgang mit einer Rate-Limiting-Schwachstelle direkt testen möchten, treten Sie in die Arena ein:

Gehen wir nun etwas tiefer ins Detail.

Was sind einige Beispiele für die API-Schwachstelle durch Ressourcenmangel und fehlendes Rate Limiting?

Es gibt zwei Wege, wie diese Schwachstelle in eine API gelangen kann. Erstens, wenn ein Entwickler schlichtweg nicht definiert, wie hoch die Drosselungsraten für eine API sein sollen. Es mag zwar irgendwo in der Infrastruktur eine Standardeinstellung für Drosselungsraten geben, sich darauf zu verlassen, ist jedoch keine gute Strategie. Stattdessen sollte jede API ihre Raten individuell zugewiesen bekommen. Dies gilt insbesondere deshalb, weil APIs sehr unterschiedliche Funktionen und verfügbare Ressourcen haben können.

Eine interne API, die nur für wenige Benutzer gedacht ist, könnte beispielsweise mit einer sehr niedrigen Drosselungsrate einwandfrei funktionieren. Eine öffentlich zugängliche API, die Teil einer Live-E-Commerce-Seite ist, würde jedoch höchstwahrscheinlich eine außergewöhnlich hohe Rate benötigen, um einen plötzlichen Anstieg gleichzeitiger Benutzer abzufangen. In beiden Fällen sollten die Drosselungsraten basierend auf den erwarteten Anforderungen, der Anzahl potenzieller Benutzer und der verfügbaren Rechenleistung definiert werden.

Es mag verlockend sein, insbesondere bei APIs, die voraussichtlich stark ausgelastet sein werden, die Raten auf unbegrenzt zu setzen, um die Leistung zu maximieren. Dies könnte mit einem einfachen Code-Schnipsel erreicht werden (als Beispiel verwenden wir das Python Django REST Framework):

"DEFAULT_THROTTLE_RATES: {
       "anon: None,
       "user: None

In diesem Beispiel können sowohl anonyme Benutzer als auch solche, die dem System bekannt sind, die API unbegrenzt oft kontaktieren, ohne Rücksicht auf die Anzahl der Anfragen im Zeitverlauf. Das ist keine gute Idee, denn egal wie viele Rechenressourcen eine API zur Verfügung hat, Angreifer können Botnetze einsetzen, um sie schließlich extrem zu verlangsamen oder möglicherweise komplett offline zu nehmen. Wenn das passiert, wird berechtigten Benutzern der Zugriff verweigert und der Angriff ist erfolgreich.

Beseitigung von Problemen durch Ressourcenmangel und Rate Limiting

Jede API, die von einer Organisation bereitgestellt wird, sollte ihre Drosselungsraten im Code definiert haben. Dies kann Dinge wie Ausführungs-Timeouts, maximal zulässigen Arbeitsspeicher, die Anzahl der Datensätze pro Seite, die an einen Benutzer zurückgegeben werden können, oder die Anzahl der innerhalb eines definierten Zeitrahmens zulässigen Prozesse umfassen.

Ausgehend vom obigen Beispiel könnten die Drosselungsraten, anstatt sie weit offen zu lassen, präzise definiert werden, mit unterschiedlichen Raten für anonyme und bekannte Benutzer.

"DEFAULT_THROTTLE_RATES: {
       "anon: config("THROTTLE_ANON, default=200/hour),
       "user: config("THROTTLE_USER, default=5000/hour)

Im neuen Beispiel würde die API anonyme Benutzer auf 200 Anfragen pro Stunde begrenzen. Bekannte Benutzer, die bereits vom System verifiziert wurden, erhalten mit 5.000 Anfragen pro Stunde mehr Spielraum. Aber selbst diese sind begrenzt, um eine versehentliche Überlastung zu Spitzenzeiten zu verhindern oder um gegenzusteuern, falls ein Benutzerkonto kompromittiert und für einen Denial-of-Service-Angriff missbraucht wird.

Als abschließende bewährte Methode ist es ratsam, Benutzern eine Benachrichtigung anzuzeigen, wenn sie die Drosselungsgrenzen erreicht haben, zusammen mit einer Erklärung, wann diese Grenzen zurückgesetzt werden. Auf diese Weise wissen berechtigte Benutzer, warum eine Anwendung ihre Anfragen ablehnt. Dies kann auch hilfreich sein, wenn berechtigten Benutzern bei der Ausführung genehmigter Aufgaben der Zugriff verweigert wird, da es dem Betriebspersonal signalisieren kann, dass die Drosselung angepasst werden muss.

Besuchen Sie die Secure Code Warrior-Blogseiten für weitere Einblicke in diese Schwachstelle und erfahren Sie, wie Sie Ihr Unternehmen und Ihre Kunden vor den Auswirkungen anderer Sicherheitslücken schützen können. Sie können auch eine Demo der Secure Code Warrior-Schulungsplattform ausprobieren, um Ihre Cybersicherheitskenntnisse stets auf dem neuesten Stand zu halten.