Coders Conquer Security OWASP Top 10 API Series - Mangel an Ressourcen und Ratenbegrenzung
Mit dem Mangel an Ressourcen und der Ratenbegrenzung verhält sich die API-Schwachstelle fast genau so, wie sie im Titel beschrieben wird. Jede API verfügt über begrenzte Ressourcen und Rechenleistung, die ihr je nach Umgebung zur Verfügung stehen. Die meisten müssen auch Anfragen von Benutzern oder anderen Programmen bearbeiten, die sie auffordern, die gewünschte Funktion auszuführen. Diese Schwachstelle tritt auf, wenn zu viele Anfragen gleichzeitig eingehen und die API nicht über genügend Rechenressourcen verfügt, um diese Anfragen zu bearbeiten. Die API kann dann nicht mehr verfügbar sein oder nicht mehr auf neue Anfragen reagieren.
APIs werden anfällig für dieses Problem, wenn ihre Raten- oder Ressourcenlimits nicht korrekt eingestellt sind oder wenn Limits im Code undefiniert bleiben. Eine API kann dann überlastet werden, wenn z. B. ein Unternehmen eine besonders geschäftige Zeit erlebt. Es ist aber auch eine Sicherheitsschwachstelle, da Bedrohungsakteure ungeschützte APIs absichtlich mit Anfragen überlasten können, um Denial-of-Service-Angriffe (DDoS) durchzuführen.
Übrigens, wie geht es Ihnen bisher mit den API gamifizierten Herausforderungen? Wenn Sie Ihre Fähigkeiten im Umgang mit einer ratenbegrenzenden Schwachstelle gleich ausprobieren möchten, treten Sie in die Arena:
Lassen Sie uns ein wenig tiefer gehen.
Was sind einige Beispiele für den Mangel an Ressourcen und die Rate, die die Anfälligkeit der API einschränken?
Es gibt zwei Möglichkeiten, wie sich diese Sicherheitslücke in eine API einschleichen kann. Die erste ist, wenn ein Programmierer einfach nicht definiert, wie hoch die Drosselungsraten für eine API sein sollen. Vielleicht gibt es irgendwo in der Infrastruktur eine Standardeinstellung für Drosselungsraten, aber sich darauf zu verlassen, ist keine gute Strategie. Stattdessen sollten die Raten für jede API individuell festgelegt werden. Dies gilt insbesondere deshalb, weil APIs sehr unterschiedliche Funktionen sowie verfügbare Ressourcen haben können.
Zum Beispiel könnte eine interne API, die nur einige wenige Benutzer bedienen soll, eine sehr niedrige Drosselungsrate haben und problemlos funktionieren. Eine öffentlich zugängliche API, die Teil einer E-Commerce-Website ist, benötigt jedoch höchstwahrscheinlich eine außergewöhnlich hohe Drosselungsrate, um die Möglichkeit eines Anstiegs der gleichzeitigen Benutzer zu kompensieren. In beiden Fällen sollten die Drosselungsraten auf der Grundlage der erwarteten Anforderungen, der Anzahl der potenziellen Benutzer und der verfügbaren Rechenleistung definiert werden.
Besonders bei APIs, die wahrscheinlich sehr stark ausgelastet sind, könnte es verlockend sein, die Preise auf unbegrenzt zu setzen, um die Leistung zu maximieren. Dies könnte mit einem einfachen Stück Code 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 beliebig oft kontaktieren, ohne Rücksicht auf die Anzahl der Anfragen im Laufe der Zeit. Dies ist eine schlechte Idee, denn egal wie viele Rechenressourcen einer API zur Verfügung stehen, Angreifer können Dinge wie Botnets einsetzen, um sie schließlich zu verlangsamen oder möglicherweise ganz offline zu schalten. Wenn das passiert, wird gültigen Benutzern der Zugriff verweigert und der Angriff ist erfolgreich.
Beseitigung von Ressourcenmangel und ratenbegrenzenden Problemen
Für jede API, die von einer Organisation eingesetzt wird, sollten die Drosselungsraten im Code definiert sein. Dies könnte Dinge wie Ausführungszeitüberschreitungen, den maximal zulässigen Speicher, die Anzahl der Datensätze pro Seite, die an einen Benutzer zurückgegeben werden können, oder die Anzahl der zulässigen Prozesse innerhalb eines bestimmten Zeitrahmens umfassen.
Aus dem obigen Beispiel könnte man, anstatt die Drosselungsraten weit offen zu lassen, sie eng definieren 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)
In dem neuen Beispiel würde die API anonyme Benutzer auf 200 Anfragen pro Stunde beschränken. Bekannte Benutzer, die bereits vom System überprüft wurden, erhalten mit 5.000 Anfragen pro Stunde mehr Spielraum. Aber auch sie sind begrenzt, um eine versehentliche Überlastung zu Spitzenzeiten zu verhindern oder um zu kompensieren, wenn ein Benutzerkonto kompromittiert und für einen Denial-of-Service-Angriff verwendet wird.
Als abschließende gute Praxis ist es eine gute Idee, eine Benachrichtigung für Benutzer anzuzeigen, wenn sie die Drosselungsgrenzen erreicht haben, zusammen mit einer Erklärung, wann diese Grenzen zurückgesetzt werden. Auf diese Weise wissen gültige Benutzer, warum eine Anwendung ihre Anfragen ablehnt. Dies kann auch hilfreich sein, wenn gültigen Benutzern, die genehmigte Aufgaben ausführen, der Zugriff auf eine API verweigert wird, da dies dem Betriebspersonal signalisieren kann, dass die Drosselung erhöht werden muss.
Schauen Sie sich die Secure Code Warrior Blog-Seiten, um mehr über diese Schwachstelle zu erfahren und zu erfahren, wie Sie Ihr Unternehmen und Ihre Kunden vor den Auswirkungen anderer Sicherheitslücken schützen können. Sie können auch eine Demo der Schulungsplattform Secure Code Warrior ausprobieren, um alle Ihre Cybersecurity-Kenntnisse zu schärfen und auf dem neuesten Stand zu halten.


Diese Schwachstelle tritt auf, wenn zu viele Anforderungen gleichzeitig eingehen und die API nicht über genügend Rechenressourcen verfügt, um diese Anforderungen zu verarbeiten. Die API kann dann nicht mehr verfügbar sein oder nicht mehr auf neue Anfragen reagieren.
Matias Madou, Ph.D., ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit und konzentrierte sich dabei auf statische Analyselösungen. Später wechselte er zu Fortify in den USA, wo er erkannte, dass es nicht ausreicht, nur Codeprobleme zu erkennen, ohne den Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, den Aufwand für die Sicherheit verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht an seinem Schreibtisch im Team Awesome sitzt, steht er gerne auf der Bühne und hält Vorträge auf Konferenzen wie der RSA Conference, BlackHat und DefCon.

Secure Code Warrior ist für Ihr Unternehmen da, um Sie dabei zu unterstützen, Ihren Code über den gesamten Lebenszyklus der Softwareentwicklung hinweg zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder ein anderer Sicherheitsverantwortlicher sind, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Demo buchenMatias Madou, Ph.D., ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit und konzentrierte sich dabei auf statische Analyselösungen. Später wechselte er zu Fortify in den USA, wo er erkannte, dass es nicht ausreicht, nur Codeprobleme zu erkennen, ohne den Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, den Aufwand für die Sicherheit verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht an seinem Schreibtisch im Team Awesome sitzt, steht er gerne auf der Bühne und hält Vorträge auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Matias ist ein Forscher und Entwickler mit mehr als 15 Jahren praktischer Erfahrung im Bereich der Softwaresicherheit. Er hat Lösungen für Unternehmen wie Fortify Software und sein eigenes Unternehmen Sensei Security entwickelt. Im Laufe seiner Karriere hat Matias mehrere Forschungsprojekte zur Anwendungssicherheit geleitet, die zu kommerziellen Produkten geführt haben, und kann auf über 10 Patente verweisen. Wenn er nicht am Schreibtisch sitzt, ist Matias als Ausbilder für fortgeschrittene Anwendungssicherheitstrainings courses tätig und hält regelmäßig Vorträge auf globalen Konferenzen wie RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec und BruCon.
Matias hat einen Doktortitel in Computertechnik von der Universität Gent, wo er die Sicherheit von Anwendungen durch Programmverschleierung untersuchte, um die innere Funktionsweise einer Anwendung zu verbergen.


Mit dem Mangel an Ressourcen und der Ratenbegrenzung verhält sich die API-Schwachstelle fast genau so, wie sie im Titel beschrieben wird. Jede API verfügt über begrenzte Ressourcen und Rechenleistung, die ihr je nach Umgebung zur Verfügung stehen. Die meisten müssen auch Anfragen von Benutzern oder anderen Programmen bearbeiten, die sie auffordern, die gewünschte Funktion auszuführen. Diese Schwachstelle tritt auf, wenn zu viele Anfragen gleichzeitig eingehen und die API nicht über genügend Rechenressourcen verfügt, um diese Anfragen zu bearbeiten. Die API kann dann nicht mehr verfügbar sein oder nicht mehr auf neue Anfragen reagieren.
APIs werden anfällig für dieses Problem, wenn ihre Raten- oder Ressourcenlimits nicht korrekt eingestellt sind oder wenn Limits im Code undefiniert bleiben. Eine API kann dann überlastet werden, wenn z. B. ein Unternehmen eine besonders geschäftige Zeit erlebt. Es ist aber auch eine Sicherheitsschwachstelle, da Bedrohungsakteure ungeschützte APIs absichtlich mit Anfragen überlasten können, um Denial-of-Service-Angriffe (DDoS) durchzuführen.
Übrigens, wie geht es Ihnen bisher mit den API gamifizierten Herausforderungen? Wenn Sie Ihre Fähigkeiten im Umgang mit einer ratenbegrenzenden Schwachstelle gleich ausprobieren möchten, treten Sie in die Arena:
Lassen Sie uns ein wenig tiefer gehen.
Was sind einige Beispiele für den Mangel an Ressourcen und die Rate, die die Anfälligkeit der API einschränken?
Es gibt zwei Möglichkeiten, wie sich diese Sicherheitslücke in eine API einschleichen kann. Die erste ist, wenn ein Programmierer einfach nicht definiert, wie hoch die Drosselungsraten für eine API sein sollen. Vielleicht gibt es irgendwo in der Infrastruktur eine Standardeinstellung für Drosselungsraten, aber sich darauf zu verlassen, ist keine gute Strategie. Stattdessen sollten die Raten für jede API individuell festgelegt werden. Dies gilt insbesondere deshalb, weil APIs sehr unterschiedliche Funktionen sowie verfügbare Ressourcen haben können.
Zum Beispiel könnte eine interne API, die nur einige wenige Benutzer bedienen soll, eine sehr niedrige Drosselungsrate haben und problemlos funktionieren. Eine öffentlich zugängliche API, die Teil einer E-Commerce-Website ist, benötigt jedoch höchstwahrscheinlich eine außergewöhnlich hohe Drosselungsrate, um die Möglichkeit eines Anstiegs der gleichzeitigen Benutzer zu kompensieren. In beiden Fällen sollten die Drosselungsraten auf der Grundlage der erwarteten Anforderungen, der Anzahl der potenziellen Benutzer und der verfügbaren Rechenleistung definiert werden.
Besonders bei APIs, die wahrscheinlich sehr stark ausgelastet sind, könnte es verlockend sein, die Preise auf unbegrenzt zu setzen, um die Leistung zu maximieren. Dies könnte mit einem einfachen Stück Code 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 beliebig oft kontaktieren, ohne Rücksicht auf die Anzahl der Anfragen im Laufe der Zeit. Dies ist eine schlechte Idee, denn egal wie viele Rechenressourcen einer API zur Verfügung stehen, Angreifer können Dinge wie Botnets einsetzen, um sie schließlich zu verlangsamen oder möglicherweise ganz offline zu schalten. Wenn das passiert, wird gültigen Benutzern der Zugriff verweigert und der Angriff ist erfolgreich.
Beseitigung von Ressourcenmangel und ratenbegrenzenden Problemen
Für jede API, die von einer Organisation eingesetzt wird, sollten die Drosselungsraten im Code definiert sein. Dies könnte Dinge wie Ausführungszeitüberschreitungen, den maximal zulässigen Speicher, die Anzahl der Datensätze pro Seite, die an einen Benutzer zurückgegeben werden können, oder die Anzahl der zulässigen Prozesse innerhalb eines bestimmten Zeitrahmens umfassen.
Aus dem obigen Beispiel könnte man, anstatt die Drosselungsraten weit offen zu lassen, sie eng definieren 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)
In dem neuen Beispiel würde die API anonyme Benutzer auf 200 Anfragen pro Stunde beschränken. Bekannte Benutzer, die bereits vom System überprüft wurden, erhalten mit 5.000 Anfragen pro Stunde mehr Spielraum. Aber auch sie sind begrenzt, um eine versehentliche Überlastung zu Spitzenzeiten zu verhindern oder um zu kompensieren, wenn ein Benutzerkonto kompromittiert und für einen Denial-of-Service-Angriff verwendet wird.
Als abschließende gute Praxis ist es eine gute Idee, eine Benachrichtigung für Benutzer anzuzeigen, wenn sie die Drosselungsgrenzen erreicht haben, zusammen mit einer Erklärung, wann diese Grenzen zurückgesetzt werden. Auf diese Weise wissen gültige Benutzer, warum eine Anwendung ihre Anfragen ablehnt. Dies kann auch hilfreich sein, wenn gültigen Benutzern, die genehmigte Aufgaben ausführen, der Zugriff auf eine API verweigert wird, da dies dem Betriebspersonal signalisieren kann, dass die Drosselung erhöht werden muss.
Schauen Sie sich die Secure Code Warrior Blog-Seiten, um mehr über diese Schwachstelle zu erfahren und zu erfahren, wie Sie Ihr Unternehmen und Ihre Kunden vor den Auswirkungen anderer Sicherheitslücken schützen können. Sie können auch eine Demo der Schulungsplattform Secure Code Warrior ausprobieren, um alle Ihre Cybersecurity-Kenntnisse zu schärfen und auf dem neuesten Stand zu halten.

Mit dem Mangel an Ressourcen und der Ratenbegrenzung verhält sich die API-Schwachstelle fast genau so, wie sie im Titel beschrieben wird. Jede API verfügt über begrenzte Ressourcen und Rechenleistung, die ihr je nach Umgebung zur Verfügung stehen. Die meisten müssen auch Anfragen von Benutzern oder anderen Programmen bearbeiten, die sie auffordern, die gewünschte Funktion auszuführen. Diese Schwachstelle tritt auf, wenn zu viele Anfragen gleichzeitig eingehen und die API nicht über genügend Rechenressourcen verfügt, um diese Anfragen zu bearbeiten. Die API kann dann nicht mehr verfügbar sein oder nicht mehr auf neue Anfragen reagieren.
APIs werden anfällig für dieses Problem, wenn ihre Raten- oder Ressourcenlimits nicht korrekt eingestellt sind oder wenn Limits im Code undefiniert bleiben. Eine API kann dann überlastet werden, wenn z. B. ein Unternehmen eine besonders geschäftige Zeit erlebt. Es ist aber auch eine Sicherheitsschwachstelle, da Bedrohungsakteure ungeschützte APIs absichtlich mit Anfragen überlasten können, um Denial-of-Service-Angriffe (DDoS) durchzuführen.
Übrigens, wie geht es Ihnen bisher mit den API gamifizierten Herausforderungen? Wenn Sie Ihre Fähigkeiten im Umgang mit einer ratenbegrenzenden Schwachstelle gleich ausprobieren möchten, treten Sie in die Arena:
Lassen Sie uns ein wenig tiefer gehen.
Was sind einige Beispiele für den Mangel an Ressourcen und die Rate, die die Anfälligkeit der API einschränken?
Es gibt zwei Möglichkeiten, wie sich diese Sicherheitslücke in eine API einschleichen kann. Die erste ist, wenn ein Programmierer einfach nicht definiert, wie hoch die Drosselungsraten für eine API sein sollen. Vielleicht gibt es irgendwo in der Infrastruktur eine Standardeinstellung für Drosselungsraten, aber sich darauf zu verlassen, ist keine gute Strategie. Stattdessen sollten die Raten für jede API individuell festgelegt werden. Dies gilt insbesondere deshalb, weil APIs sehr unterschiedliche Funktionen sowie verfügbare Ressourcen haben können.
Zum Beispiel könnte eine interne API, die nur einige wenige Benutzer bedienen soll, eine sehr niedrige Drosselungsrate haben und problemlos funktionieren. Eine öffentlich zugängliche API, die Teil einer E-Commerce-Website ist, benötigt jedoch höchstwahrscheinlich eine außergewöhnlich hohe Drosselungsrate, um die Möglichkeit eines Anstiegs der gleichzeitigen Benutzer zu kompensieren. In beiden Fällen sollten die Drosselungsraten auf der Grundlage der erwarteten Anforderungen, der Anzahl der potenziellen Benutzer und der verfügbaren Rechenleistung definiert werden.
Besonders bei APIs, die wahrscheinlich sehr stark ausgelastet sind, könnte es verlockend sein, die Preise auf unbegrenzt zu setzen, um die Leistung zu maximieren. Dies könnte mit einem einfachen Stück Code 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 beliebig oft kontaktieren, ohne Rücksicht auf die Anzahl der Anfragen im Laufe der Zeit. Dies ist eine schlechte Idee, denn egal wie viele Rechenressourcen einer API zur Verfügung stehen, Angreifer können Dinge wie Botnets einsetzen, um sie schließlich zu verlangsamen oder möglicherweise ganz offline zu schalten. Wenn das passiert, wird gültigen Benutzern der Zugriff verweigert und der Angriff ist erfolgreich.
Beseitigung von Ressourcenmangel und ratenbegrenzenden Problemen
Für jede API, die von einer Organisation eingesetzt wird, sollten die Drosselungsraten im Code definiert sein. Dies könnte Dinge wie Ausführungszeitüberschreitungen, den maximal zulässigen Speicher, die Anzahl der Datensätze pro Seite, die an einen Benutzer zurückgegeben werden können, oder die Anzahl der zulässigen Prozesse innerhalb eines bestimmten Zeitrahmens umfassen.
Aus dem obigen Beispiel könnte man, anstatt die Drosselungsraten weit offen zu lassen, sie eng definieren 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)
In dem neuen Beispiel würde die API anonyme Benutzer auf 200 Anfragen pro Stunde beschränken. Bekannte Benutzer, die bereits vom System überprüft wurden, erhalten mit 5.000 Anfragen pro Stunde mehr Spielraum. Aber auch sie sind begrenzt, um eine versehentliche Überlastung zu Spitzenzeiten zu verhindern oder um zu kompensieren, wenn ein Benutzerkonto kompromittiert und für einen Denial-of-Service-Angriff verwendet wird.
Als abschließende gute Praxis ist es eine gute Idee, eine Benachrichtigung für Benutzer anzuzeigen, wenn sie die Drosselungsgrenzen erreicht haben, zusammen mit einer Erklärung, wann diese Grenzen zurückgesetzt werden. Auf diese Weise wissen gültige Benutzer, warum eine Anwendung ihre Anfragen ablehnt. Dies kann auch hilfreich sein, wenn gültigen Benutzern, die genehmigte Aufgaben ausführen, der Zugriff auf eine API verweigert wird, da dies dem Betriebspersonal signalisieren kann, dass die Drosselung erhöht werden muss.
Schauen Sie sich die Secure Code Warrior Blog-Seiten, um mehr über diese Schwachstelle zu erfahren und zu erfahren, wie Sie Ihr Unternehmen und Ihre Kunden vor den Auswirkungen anderer Sicherheitslücken schützen können. Sie können auch eine Demo der Schulungsplattform Secure Code Warrior ausprobieren, um alle Ihre Cybersecurity-Kenntnisse zu schärfen und auf dem neuesten Stand zu halten.

Klicken Sie auf den unten stehenden Link und laden Sie die PDF-Datei dieser Ressource herunter.
Secure Code Warrior ist für Ihr Unternehmen da, um Sie dabei zu unterstützen, Ihren Code über den gesamten Lebenszyklus der Softwareentwicklung hinweg zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder ein anderer Sicherheitsverantwortlicher sind, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Bericht ansehenDemo buchenMatias Madou, Ph.D., ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit und konzentrierte sich dabei auf statische Analyselösungen. Später wechselte er zu Fortify in den USA, wo er erkannte, dass es nicht ausreicht, nur Codeprobleme zu erkennen, ohne den Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, den Aufwand für die Sicherheit verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht an seinem Schreibtisch im Team Awesome sitzt, steht er gerne auf der Bühne und hält Vorträge auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Matias ist ein Forscher und Entwickler mit mehr als 15 Jahren praktischer Erfahrung im Bereich der Softwaresicherheit. Er hat Lösungen für Unternehmen wie Fortify Software und sein eigenes Unternehmen Sensei Security entwickelt. Im Laufe seiner Karriere hat Matias mehrere Forschungsprojekte zur Anwendungssicherheit geleitet, die zu kommerziellen Produkten geführt haben, und kann auf über 10 Patente verweisen. Wenn er nicht am Schreibtisch sitzt, ist Matias als Ausbilder für fortgeschrittene Anwendungssicherheitstrainings courses tätig und hält regelmäßig Vorträge auf globalen Konferenzen wie RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec und BruCon.
Matias hat einen Doktortitel in Computertechnik von der Universität Gent, wo er die Sicherheit von Anwendungen durch Programmverschleierung untersuchte, um die innere Funktionsweise einer Anwendung zu verbergen.
Mit dem Mangel an Ressourcen und der Ratenbegrenzung verhält sich die API-Schwachstelle fast genau so, wie sie im Titel beschrieben wird. Jede API verfügt über begrenzte Ressourcen und Rechenleistung, die ihr je nach Umgebung zur Verfügung stehen. Die meisten müssen auch Anfragen von Benutzern oder anderen Programmen bearbeiten, die sie auffordern, die gewünschte Funktion auszuführen. Diese Schwachstelle tritt auf, wenn zu viele Anfragen gleichzeitig eingehen und die API nicht über genügend Rechenressourcen verfügt, um diese Anfragen zu bearbeiten. Die API kann dann nicht mehr verfügbar sein oder nicht mehr auf neue Anfragen reagieren.
APIs werden anfällig für dieses Problem, wenn ihre Raten- oder Ressourcenlimits nicht korrekt eingestellt sind oder wenn Limits im Code undefiniert bleiben. Eine API kann dann überlastet werden, wenn z. B. ein Unternehmen eine besonders geschäftige Zeit erlebt. Es ist aber auch eine Sicherheitsschwachstelle, da Bedrohungsakteure ungeschützte APIs absichtlich mit Anfragen überlasten können, um Denial-of-Service-Angriffe (DDoS) durchzuführen.
Übrigens, wie geht es Ihnen bisher mit den API gamifizierten Herausforderungen? Wenn Sie Ihre Fähigkeiten im Umgang mit einer ratenbegrenzenden Schwachstelle gleich ausprobieren möchten, treten Sie in die Arena:
Lassen Sie uns ein wenig tiefer gehen.
Was sind einige Beispiele für den Mangel an Ressourcen und die Rate, die die Anfälligkeit der API einschränken?
Es gibt zwei Möglichkeiten, wie sich diese Sicherheitslücke in eine API einschleichen kann. Die erste ist, wenn ein Programmierer einfach nicht definiert, wie hoch die Drosselungsraten für eine API sein sollen. Vielleicht gibt es irgendwo in der Infrastruktur eine Standardeinstellung für Drosselungsraten, aber sich darauf zu verlassen, ist keine gute Strategie. Stattdessen sollten die Raten für jede API individuell festgelegt werden. Dies gilt insbesondere deshalb, weil APIs sehr unterschiedliche Funktionen sowie verfügbare Ressourcen haben können.
Zum Beispiel könnte eine interne API, die nur einige wenige Benutzer bedienen soll, eine sehr niedrige Drosselungsrate haben und problemlos funktionieren. Eine öffentlich zugängliche API, die Teil einer E-Commerce-Website ist, benötigt jedoch höchstwahrscheinlich eine außergewöhnlich hohe Drosselungsrate, um die Möglichkeit eines Anstiegs der gleichzeitigen Benutzer zu kompensieren. In beiden Fällen sollten die Drosselungsraten auf der Grundlage der erwarteten Anforderungen, der Anzahl der potenziellen Benutzer und der verfügbaren Rechenleistung definiert werden.
Besonders bei APIs, die wahrscheinlich sehr stark ausgelastet sind, könnte es verlockend sein, die Preise auf unbegrenzt zu setzen, um die Leistung zu maximieren. Dies könnte mit einem einfachen Stück Code 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 beliebig oft kontaktieren, ohne Rücksicht auf die Anzahl der Anfragen im Laufe der Zeit. Dies ist eine schlechte Idee, denn egal wie viele Rechenressourcen einer API zur Verfügung stehen, Angreifer können Dinge wie Botnets einsetzen, um sie schließlich zu verlangsamen oder möglicherweise ganz offline zu schalten. Wenn das passiert, wird gültigen Benutzern der Zugriff verweigert und der Angriff ist erfolgreich.
Beseitigung von Ressourcenmangel und ratenbegrenzenden Problemen
Für jede API, die von einer Organisation eingesetzt wird, sollten die Drosselungsraten im Code definiert sein. Dies könnte Dinge wie Ausführungszeitüberschreitungen, den maximal zulässigen Speicher, die Anzahl der Datensätze pro Seite, die an einen Benutzer zurückgegeben werden können, oder die Anzahl der zulässigen Prozesse innerhalb eines bestimmten Zeitrahmens umfassen.
Aus dem obigen Beispiel könnte man, anstatt die Drosselungsraten weit offen zu lassen, sie eng definieren 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)
In dem neuen Beispiel würde die API anonyme Benutzer auf 200 Anfragen pro Stunde beschränken. Bekannte Benutzer, die bereits vom System überprüft wurden, erhalten mit 5.000 Anfragen pro Stunde mehr Spielraum. Aber auch sie sind begrenzt, um eine versehentliche Überlastung zu Spitzenzeiten zu verhindern oder um zu kompensieren, wenn ein Benutzerkonto kompromittiert und für einen Denial-of-Service-Angriff verwendet wird.
Als abschließende gute Praxis ist es eine gute Idee, eine Benachrichtigung für Benutzer anzuzeigen, wenn sie die Drosselungsgrenzen erreicht haben, zusammen mit einer Erklärung, wann diese Grenzen zurückgesetzt werden. Auf diese Weise wissen gültige Benutzer, warum eine Anwendung ihre Anfragen ablehnt. Dies kann auch hilfreich sein, wenn gültigen Benutzern, die genehmigte Aufgaben ausführen, der Zugriff auf eine API verweigert wird, da dies dem Betriebspersonal signalisieren kann, dass die Drosselung erhöht werden muss.
Schauen Sie sich die Secure Code Warrior Blog-Seiten, um mehr über diese Schwachstelle zu erfahren und zu erfahren, wie Sie Ihr Unternehmen und Ihre Kunden vor den Auswirkungen anderer Sicherheitslücken schützen können. Sie können auch eine Demo der Schulungsplattform Secure Code Warrior ausprobieren, um alle Ihre Cybersecurity-Kenntnisse zu schärfen und auf dem neuesten Stand zu halten.
Inhaltsübersicht
Matias Madou, Ph.D., ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit und konzentrierte sich dabei auf statische Analyselösungen. Später wechselte er zu Fortify in den USA, wo er erkannte, dass es nicht ausreicht, nur Codeprobleme zu erkennen, ohne den Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, den Aufwand für die Sicherheit verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht an seinem Schreibtisch im Team Awesome sitzt, steht er gerne auf der Bühne und hält Vorträge auf Konferenzen wie der RSA Conference, BlackHat und DefCon.

Secure Code Warrior ist für Ihr Unternehmen da, um Sie dabei zu unterstützen, Ihren Code über den gesamten Lebenszyklus der Softwareentwicklung hinweg zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder ein anderer Sicherheitsverantwortlicher sind, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Demo buchenHerunterladenRessourcen für den Einstieg
Benchmarking von Sicherheitskompetenzen: Optimierung von Secure-by-Design im Unternehmen
Aussagekräftige Daten über den Erfolg von Secure-by-Design-Initiativen zu finden, ist bekanntermaßen schwierig. CISOs stehen oft vor der Herausforderung, den Return on Investment (ROI) und den Geschäftswert von Sicherheitsprogrammen sowohl auf Mitarbeiter- als auch auf Unternehmensebene nachzuweisen. Ganz zu schweigen davon, dass es für Unternehmen besonders schwierig ist, Erkenntnisse darüber zu gewinnen, wie ihre Organisation im Vergleich zu aktuellen Branchenstandards abschneidet. Die Nationale Cybersicherheitsstrategie des Präsidenten forderte die Beteiligten auf, "Sicherheit und Widerstandsfähigkeit durch Design" zu erreichen. Der Schlüssel zum Erfolg von Secure-by-Design-Initiativen liegt nicht nur darin, Entwicklern die nötigen Fähigkeiten zu vermitteln, um sicheren Code zu gewährleisten, sondern auch darin, den Aufsichtsbehörden zu versichern, dass diese Fähigkeiten vorhanden sind. In dieser Präsentation stellen wir eine Vielzahl von qualitativen und quantitativen Daten vor, die aus verschiedenen Primärquellen stammen, darunter interne Daten von über 250.000 Entwicklern, datengestützte Kundeneinblicke und öffentliche Studien. Auf der Grundlage dieser gesammelten Daten wollen wir eine Vision des aktuellen Stands von Secure-by-Design-Initiativen in verschiedenen Branchen vermitteln. Der Bericht zeigt auf, warum dieser Bereich derzeit nicht ausreichend genutzt wird, welche erheblichen Auswirkungen ein erfolgreiches Schulungsprogramm auf die Minderung von Cybersecurity-Risiken haben kann und welches Potenzial zur Beseitigung von Schwachstellen in einer Codebasis besteht.
Professionelle Dienstleistungen - Beschleunigen Sie mit Fachwissen
Das PSS-Team (Program Strategy Services) von Secure Code Warriorunterstützt Sie beim Aufbau, der Verbesserung und der Optimierung Ihres Programms für sichere Codierung. Ganz gleich, ob Sie neu anfangen oder Ihren Ansatz verfeinern möchten, unsere Experten bieten Ihnen maßgeschneiderte Beratung.
Themen und Inhalte der Schulung zu sicherem Code
Unsere branchenführenden Inhalte werden ständig weiterentwickelt, um sie an die sich ständig verändernde Softwareentwicklungslandschaft anzupassen und Ihre Rolle zu berücksichtigen. Die Themen reichen von KI bis XQuery Injection und werden für eine Vielzahl von Rollen angeboten, von Architekten und Ingenieuren bis hin zu Produktmanagern und QA. Verschaffen Sie sich einen kleinen Überblick über die Inhalte, die unser Katalog nach Thema und Rolle bietet.
Quests: Branchenführendes Lernen, damit die Entwickler immer einen Schritt voraus sind und Risiken minimiert werden.
Quests ist eine learning platform , die Entwicklern hilft, Software-Sicherheitsrisiken zu verringern, indem sie ihre Fähigkeiten zur sicheren Programmierung verbessern. Mit kuratierten Lernpfaden, praktischen Herausforderungen und interaktiven Aktivitäten befähigt sie Entwickler, Schwachstellen zu erkennen und zu vermeiden.
Ressourcen für den Einstieg
Wird Vibe Coding Ihre Codebasis in eine Verbindungsparty verwandeln?
Vibe Coding ist wie eine College-Verbindungsparty, und AI ist das Herzstück aller Festivitäten, das Fass. Es macht eine Menge Spaß, sich auszutoben, kreativ zu werden und zu sehen, wohin die eigene Fantasie einen führen kann, aber nach ein paar Bierfässern ist das Trinken (oder die Verwendung von KI) in Maßen zweifellos die sicherere langfristige Lösung.
Das Jahrzehnt der Defenders: Secure Code Warrior Zehnte Runde
Secure Code WarriorDas Gründungsteam von SCW ist zusammengeblieben und hat das Schiff ein ganzes Jahrzehnt lang durch alle Lektionen, Triumphe und Rückschläge gesteuert. Wir vergrößern uns und sind bereit für unser nächstes Kapitel, SCW 2.0, als führendes Unternehmen im Risikomanagement für Entwickler.