Eine verpasste Prüfung, die Sie teuer zu stehen kommen könnte: Requests.get und Flask-Anforderungsformular
Stellen Sie sich Folgendes vor: Ein Junior-Entwickler arbeitet unter Druck, um eine Funktion auszuliefern. Er öffnet eine Flask-App, fügt eine neue Route hinzu, greift auf einen Abfrageparameter zu und macht weiter.
# Demonstrative example only — NOT executable, not exploitable
from flask import Flask, request
@app.route("/items")
def get_items():
# Type casting avoids unsafe string injection
item_id = request.args.get("id", type=int)
# Safe usage: forces integer input, prevents injection
Auf den ersten Blick sieht diese Flask-Anforderungsverwendung gut aus. Aber weglassen Typ=int und du öffnest die Tür zu Injektionsangriffe. Dies sind die Arten von Risiken, die bei Codeüberprüfungen übersehen werden, weil „es nur darum geht, einen Wert abzurufen“.
Wo das Risiko lauert Flask-Anfrage , Flask Anfrageformular
Beides flask.request , flask.request.form sind nicht vertrauenswürdige Einstiegspunkte. Jeder von ihnen zurückgegebene Wert stammt direkt vom Client und sollte als potenziell feindlich behandelt werden.
Wenn diese Daten nicht validiert oder bereinigt werden, kann dies zu kritischen Sicherheitsproblemen führen, darunter:
- SQL-Injection
- Cross-Site-Scripting (XSS)
- Vorlageninjektion
- Shell-Befehlsinjektion
Diese Risiken gelten nicht nur für Datenbanken oder Front-End-Rendering. Angreifer können auch Eingaben ausnutzen, die in Vorlagen verwendet oder an Unterprozesse übergeben werden.
Sichere Pseudocode-Muster:
python
# ⚠️ Educational example only — not functional
env_target = input("Enter deployment environment: ")
simulate_deploy(env_target) # Simulated for demonstration
Präventiv CI/CD Durchsetzung:
# 1. Query parameter — Safe with casting
user_id = request.args.get("id", type=int) # Enforces integer type
# 2. Form parameter — Safe with casting
username = request.form.get("username", type=str) # Enforces string type
# 3. Template rendering safeguard
template_data = {"name": request.args.get("name", type=str)} # Avoids untrusted HTML injection
# 4. Shell command safe handling
filename = request.args.get("file", type=str)
# Validate filename against known safe values before use in subprocess (not shown)
Auch wenn die Syntax sicher aussieht, kann die Verwendung von Rohwerten oder ungeprüften Werten in Vorlagen oder Systembefehlen zu einem ernstzunehmenden Einschleusungsvektor werden.
Praktischer Injektionsfluss (Sichere Simulation)
So entwickelt sich ein Injektionsfehler typischerweise anhand eines fiktiven, sicheren Szenarios:
- Ein Benutzer sendet einen manipulierten Abfrageparameter an die Anwendung.
- Die App liest den Wert mit Anfrage.Argumente.Get() ohne Validierung.
- Dieser Wert wird direkt in eine SQL-Abfrage, eine Vorlagenzeichenfolge oder einen Shell-Befehl eingefügt.
- Das System führt diese Logik aus, ohne den eingefügten Inhalt zu kennen.
Pseudocode (unsicher, nur zur Veranschaulichung):
# Insecure example — do not run in production
user_id = request.args.get("id") # Missing type casting, no validation
query = f"SELECT * FROM users WHERE id = {user_id}" # Risk of injection
Fiktiver Log-Trace:
[INFO] Incoming request: /user?id=unexpected_input
[DEBUG] Parsed user_id: unexpected_input
[DEBUG] Constructed SQL: SELECT * FROM users WHERE id = unexpected_input
Obwohl in diesem Beispiel Platzhalter verwendet werden, zeigt es, wie kleine Versehen bei der Eingabeverarbeitung zu kritischen Sicherheitslücken führen können.
Bei automatisierten Tests kann dies übersehen werden, da sie normalerweise auf gültige Eingabetypen prüfen und nicht auf fehlerhafte oder bösartige.
Versteckte Risiken bei Abhängigkeiten mit Flask-Anforderung , Flaschenanforderungsformular
Ihr Code ist möglicherweise sauber, aber Pakete von Drittanbietern können ihn dennoch beschädigen.
Einige Flask-Plugins oder -Bibliotheken rufen intern Flask-Anfragen oder Flask-Anforderungsformulare ohne Validierung auf.
Beispiel mit fiktiven Paketen:
python
# Insecure example — do not run in production
return AutoFormHandler.process() # May use request.form.get() without validation
python
# Insecure example — do not run in production
query = build_query(request.args) # May use request.args.get() without casting
In CI/CD, automatisierte Abhängigkeitsaktualisierungen können unbemerkt unsichere Requests.Get-Aufrufe oder anfällige Eingabeverarbeitungsmuster einführen.
Wie unsicher Flask-Anforderung Die Nutzung geht über Code-Überprüfungen hinaus
In schnelllebigen Umgebungen bleiben kleine, aber gefährliche Fehler oft unbemerkt, insbesondere wenn die Änderung harmlos erscheint.
Beispiel pull request Unterschied:
# Insecure example — do not run in production
- user_id = request.args.get("id")
+ user_id = request.args.get("id") # Still missing type casting
Kommentar des Rezensenten:
„Sieht gut aus, es wird nur ein Parameter abgerufen.“
Diese Art von Versehen kommt häufig vor, weil:
- Kognitive Verzerrung: Prüfer können davon ausgehen, dass request.args.get() standardmäßig sicher ist.
- Zeitdruck: Sicherheitskontrollen treten in den Hintergrund, wenn Fristen drohen.
- Unterschiedliche Vertrautheit: Die Änderung scheint geringfügig zu sein und wird daher nicht näher untersucht.
Ohne klare Regeln oder automatisierte Durchsetzung schleichen sich diese subtilen Risiken unbemerkt in die Produktion ein.
Prävention, die funktioniert
Um die Risiken einer Injektion zu minimieren, kombinieren Sie Eingabevalidierung, automatisiertes Scannen und Testabdeckung.
Eingabevalidierung mit Casting und Whitelisting:
user_id = request.args.get("id", type=int)
if user_id not in [1, 2, 3]:
abort(400, "Invalid ID")
Durch das Casting wird der Wert auf einen sicheren Typ umgestellt, während durch die Whitelist sichergestellt wird, dass nur bekanntermaßen gute Werte verarbeitet werden.
Statische Anwendungssicherheitstests (SAST) in CI/CD:
name: Run SAST scan
run: sast-tool --scan src/ --fail-on "request.args.get without type"
Dieser Schritt hilft, nicht validierte Anfrage.Argumente.Get() or Anfrage.Formular.Get() Anrufe, bevor sie die Produktion erreichen.
Unit-Tests zur Durchsetzung der Bereinigung:
def test_invalid_type(client):
response = client.get("/items?id=abc")
assert response.status_code == 400
These tests ensure the app rejects malformed or malicious input consistently.
Integrating Into DevSecOps Pipelines
Middleware enforcement:
@app.before_request
Diese Tests stellen sicher, dass die App fehlerhafte oder böswillige Eingaben konsequent ablehnt.
Integration in DevSecOps Pipelines
Middleware-Durchsetzung:
@app.before_request
def sanitize_input():
if "id" in request.args and not request.args.get("id", type=int):
abort(400, "Invalid ID")
Pre-commit hook:
bash
if grep -R "request.args.get(" . | grep -v "type="; then
echo "Unsafe request.args.get detected — please add type casting."
exit 1
fi
Scannen Sie sowohl Ihren Code als auch Abhängigkeiten von Drittanbietern hilft dabei, unsichere Requests.get-, Flask-Request- und Flask-Request-Formularnutzungen abzufangen, bevor sie die Produktion erreichen.
Dieses Problem geht über Flask hinaus
Unsichere Eingabeverarbeitung ist nicht nur bei Flask ein Problem, sondern kommt in allen Web-Frameworks vor. Glücklicherweise ist die Lösung einheitlich: Eingaben frühzeitig und streng validieren.
Django (sicherer Pseudocode):
# Enforces integer type and applies whitelist
user_id = int(request.GET.get("id", "0"))
if user_id not in [1, 2, 3]:
return HttpResponseBadRequest()
FastAPI (von Haus aus sicher durch Typhinweise):
from fastapi import Query
@app.get("/items")
def read_items(id: int = Query(..., ge=1, le=3)):
return {"id": id}
Beide Beispiele erzwingen Eingabetyp und -bereich und stellen sicher, dass eingehende Daten vertrauenswürdig sind, bevor sie sensible Logik erreichen.
Egal ob Flask, Django oder FastAPI, jeder Anforderungsparameter ist ein potenzieller Injektionspunkt, wenn er nicht richtig validiert wird.
Verwendung von Xygeni zur Erkennung in DevSecOps
In einer DevSecOps-Umgebung reichen manuelle Überprüfungen nicht aus. Xygeni Automatisiert die Erkennung unsicherer Flask-Anfragen, Flask-Anforderungsformulare und der Verwendung von requests.get.
Praktische DevSecOps-Anwendungen:
- Statische Scans: Markiert alle Anfrage.Argumente.Get() ohne Typ =, und Flask-Anforderungsformularaufrufe ohne Validierung.
- Abhängigkeitsanalyse: Überwacht Bibliotheken auf unsichere Muster, die durch indirekte Aufrufe auftreten könnten.
- Blockieren unsicherer Zusammenführungen: CI/CD schlägt fehl, wenn neuer Code riskante Requests.get oder nicht validierten Formularzugriff einführt.
- Durchsetzung der Grundlinie: Verfolgt Änderungen, um zu verhindern, dass aus sicheren Anrufen unsichere werden.
Die Automatisierung dieser Prüfungen verringert das Risiko menschlicher Fehler und sorgt für kontinuierliche Sicherheit, ohne die Bereitstellung zu verlangsamen.
Also: Validieren, Bereinigen, Automatisieren
Hier ist das Fazit: requests.get, Flask Request und Flask Request Form sind alle standardmäßig nicht vertrauenswürdig. Wenn Sie nichts unternehmen, übermitteln sie gerne schädliche Daten.
Ihre drei Regeln:
- Bestätigen Eingaben mithilfe von Casting und Whitelists.
- Desinfizieren bevor die Daten sensible Vorgänge berühren.
- Automatisiere Prozesse mit Technologie
Schecks in Ihrem pipeline um unsicheren Code vor der Bereitstellung zu stoppen.
Ein einzelner unsicherer Flask-Request-Handler, ein ungeprüftes Flask-Request-Formularfeld oder ein ungeschützter requests.get-Aufruf können Ihre Anwendung gefährden. Behandeln Sie jeden Parameter als potenziell feindlich und lassen Sie Ihre DevSecOps pipeline Setzen Sie die Regeln jedes Mal durch.
