paint-brush
Verteidigen Sie Ihre Web-App: Ein Leitfaden zur Ratenbegrenzung und zur Verhinderung von Brute-Force-Angriffenvon@shad0wpuppet
24,482 Lesungen
24,482 Lesungen

Verteidigen Sie Ihre Web-App: Ein Leitfaden zur Ratenbegrenzung und zur Verhinderung von Brute-Force-Angriffen

von Constantine4m2024/01/22
Read on Terminal Reader
Read this story w/o Javascript

Zu lang; Lesen

Die Implementierung robuster Maßnahmen zur Ratenbegrenzung ist für Webanwendungen unerlässlich, um Brute-Force-Angriffe und eine mögliche Überlastung der Dienste zu verhindern. Techniken zur Ratenbegrenzung und Einblicke in das Testen und Umgehen von Ratenlimits. Der Artikel behandelt den Automatisierungsansatz, Header-Manipulationen, Endpunktvariationen und Anmeldestrategien. Der Einsatz von Cloudflare zur Wiederherstellung ursprünglicher Besucher-IPs wird ebenfalls untersucht, wobei darauf geachtet wird, mögliche Auswirkungen auf die Anwendung vor der Implementierung gründlich zu testen und zu bewerten.
featured image - Verteidigen Sie Ihre Web-App: Ein Leitfaden zur Ratenbegrenzung und zur Verhinderung von Brute-Force-Angriffen
Constantine HackerNoon profile picture
0-item


Wenn Ihre Anwendung grundlegende Funktionen wie Anmeldung, Registrierung, Zurücksetzen/Wiederherstellen von Passwörtern, Bestätigungslinks zum erneuten Senden und andere spezifische Funktionen umfasst, die Serveranfragen erfordern, ist es wichtig, Mechanismen gegen Brute-Force-Angriffe und die Erzeugung einer erheblichen Belastung Ihres Dienstes zu implementieren. Ohne solche Mechanismen ist Ihre Anwendung möglicherweise anfällig für verschiedene Bedrohungen, einschließlich des Versendens einer übermäßigen Anzahl von E-Mails/OTPs an Benutzer, was möglicherweise zu finanziellen Schäden und Reputationsschäden führen kann.


Vielen Webanwendungen mangelt es an angemessenen Maßnahmen zur Ratenbegrenzung, da sie sich ausschließlich auf die durch ihre Geschäftslogik auferlegten Einschränkungen verlassen, wie etwa die Beschränkung der Anzahl von Anfragen auf der Grundlage eines Zahlungsmodells. Einige Anwendungen enthalten jedoch Ratenbegrenzungen, insbesondere für Vorgänge wie Anmeldeversuche, Registrierung und andere wichtige Funktionen. Diese Implementierungen sind häufig auf den X-Forwarded-For-Header für die IP-Adressverfolgung angewiesen.


Um ein einfaches Beispiel zu veranschaulichen, habe ich mir dieses Code-Snippet für Flask ausgedacht


 from flask import Flask, request, jsonify from flask_limiter import Limiter from flask_limiter.util import get_remote_address app = Flask(__name__) limiter = Limiter(    app,    key_func=get_remote_address,    storage_uri="memory://",) def get_ipaddr():    # Retrieve the client's IP address from the request    # X-Forwarded-For header is used to handle requests behind a proxy    ip_address = request.headers.get('X-Forwarded-For', request.remote_addr)    return ip_address # Rate limit to 5 requests per minute per IP @limiter.limit("5 per minute") @app.route('/') def index(): ip_address = get_ipaddr() return ip_address

In den folgenden Abschnitten erkläre ich verschiedene Ansätze zum Testen und Versuchen, Ratenbeschränkungen in Ihrer Anwendung zu umgehen.


Um Ihre App effizient auf diese Art von Schwachstelle zu testen, ist Automatisierung ein leistungsstarkes Werkzeug. Sie können dies erreichen, indem Sie Skripte wie die in Python verwenden (was ich oft tue) oder Tools wie Burp Suite verwenden (übrigens ein großartiges Tool für Tester und Cybersicherheitsexperten). Außerdem können Tools wie Postman verwendet werden, um Schecks relativ einfach zu automatisieren.

Testgeschwindigkeitsbegrenzung

Ändern des IP-Werts im X-Forwarded-For-Header

 X-Originating-IP: 127.0.0.1

Verwenden Sie in jeder von Ihnen gesendeten Anfrage unterschiedliche IP-Werte.


Verwenden Sie den doppelten X-Forwared-For-Header.

 X-Forwarded-For: X-Forwarded-For: 127.0.0.1

Versuchen Sie dasselbe mit verschiedenen Headern.

 X-Originating-IP: 127.0.0.1 X-Remote-IP: 127.0.0.1 X-Remote-Addr: 127.0.0.1 X-Client-IP: 127.0.0.1 X-Host: 127.0.0.1 X-Forwared-Host: 127.0.0.1

Andere Überschriften ändern

Versuchen Sie, den Benutzeragenten, den Inhaltstyp, die Akzeptanzsprache usw. oder Cookies zu ändern, also alles, was als Benutzerkennung verwendet werden könnte.


Wenn es ein Ratenlimit von 3 Versuchen pro IP gibt, ändern Sie alle drei Versuche den IP-Wert des Headers (oder anderer Header oder Parameter in Ihren Anfragen).

Fügen Sie Leerzeichen in Parametern hinzu

Versuchen Sie, die von Ihnen gesendeten Parameter zu ergänzen

 %00, %0d%0a, %0d, %0a, %09, %0C, %20

Zum Beispiel

 param1=value1%%0d%0a param2=value2%00

Wenn Sie beispielsweise OTP für die E-Mail-Verifizierung anfordern und nur drei Versuche haben, verwenden Sie die drei Versuche für

 [email protected] [email protected]%00 [email protected]%0d%0a And so on

Verwenden Sie ähnliche Endpunkte

Wenn Sie beispielsweise den Endpunkt /API/v1/signup testen, versuchen Sie, Brute-Force auf /Signup, /SignUp, /signup anzuwenden. Versuchen Sie, Leerzeichen (von oben) zu den ursprünglichen Endpunkten hinzuzufügen.

Hinzufügen zusätzlicher Parameter zum angeforderten API-Endpunkt

Wenn das Limit bei den Anfragen des Endpunkts /api/v1/resetpassword liegt, versuchen Sie es mit Brute-Force, indem Sie einige Abfrageparameter hinzufügen. Sobald das Ratenlimit erreicht ist, versuchen Sie es beispielsweise mit /api/v1/resetpassword?param1=value1

Anmeldungen sind wichtig

Es kann sein, dass die Logik einer App fehlerhaft ist. Wenn Sie sich vor jedem Versuch bzw. jeder Versuchsreihe bei Ihrem Konto anmelden, wird das Ratenlimit für Ihre IP zurückgesetzt und Sie können Ihren Passwort-Brute-Force-Angriff fortsetzen. Wenn Sie eine Anmeldefunktion testen, können Sie dies in Burp Suit mit einem Pitchfork-Angriff in den Einstellungen tun (oder Sie können dafür ein eigenes Skript schreiben) für jeden Versuch/eine Versuchsreihe.


Hier ist mein Beispiel dafür, wie ich eine einfache Prüfung für den X-Forwarded-For-Header automatisiert habe, um einen POW zu erhalten:


 from random import randint import requests import json url = "https://yourapp.net/api/v1/regconfirm-resend" data = {   "email": "[email protected]" } N = 100 def generate_random_ip():   return '.'.join(       str(randint(0, 255)) for _ in range(4)   ) for _ in range(N):   headers = {       "Host": "yourapp.net",       "Content-Type": "application/json",       "X-Forwarded-For": generate_random_ip()   }   response = requests.post(url, headers=headers, data=json.dumps(data))   print(headers)   print(f"Status Code: {response.status_code}, Response: {response.text}")

Wiederherstellung der ursprünglichen Besucher-IPs

Eine mögliche Lösung könnte der Einsatz von Cloudflare und seinen Mechanismen sein. Eine ausführliche Erklärung finden Sie hier restoring-original-visitor-ips . Ich werde nur einen kurzen Überblick über seine Abwehrmechanismen geben.


Wenn Sie Anwendungen verwenden, die von der eingehenden IP-Adresse des ursprünglichen Besuchers abhängig sind, wird standardmäßig eine Cloudflare-IP-Adresse protokolliert. Die ursprüngliche Besucher-IP-Adresse erscheint in einem angehängten HTTP-Header namens CF-Connecting-IP. Indem Sie unseren Webserveranweisungen folgen, können Sie die ursprüngliche Besucher-IP-Adresse auf Ihrem Ursprungsserver protokollieren. Wenn dieser HTTP-Header nicht verfügbar ist, wenn Anforderungen Ihren Ursprungsserver erreichen, überprüfen Sie die Konfiguration Ihrer Transformationsregeln und verwalteten Transformationen.


Wenn Pseudo-IPv4 auf „Header überschreiben“ eingestellt ist, überschreibt Cloudflare die vorhandenen Cf-Connecting-IP- und X-Forwarded-For-Header mit einer Pseudo-IPv4-Adresse, während die echte IPv6-Adresse im CF-Connecting-IPv6-Header erhalten bleibt.


HINWEIS: Denken Sie daran, bei der Implementierung eines solchen Abwehrmechanismus gründliche Tests durchzuführen. Dieser Ansatz könnte anschließend auf den gesamten Cluster angewendet werden und sich nachteilig auf bestimmte Funktionen und Mikrodienste auswirken, wenn dies unnötig ist. Kurz gesagt: Seien Sie bei der Behebung einer Sicherheitslücke vorsichtig, da diese möglicherweise Auswirkungen auf die gesamte Anwendung haben könnte. Analysieren Sie, welcher Teil Ihres Systems negativ beeinflusst werden könnte, und testen Sie alles, bevor Sie Änderungen an der Produktumgebung vornehmen.


Auch hier veröffentlicht.