Un contrôle manqué qui pourrait vous coûter cher : Requests.get et formulaire de demande Flask
Imaginez : un développeur junior travaille sous pression pour livrer une fonctionnalité. Il ouvre une application Flask, ajoute une nouvelle route, récupère un paramètre de requête et passe à autre chose.
# 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
À première vue, cette utilisation de requête Flask semble correcte. Mais omettez-la. type=int et tu ouvres la porte à attaques par injection. Ce sont les types de risques qui échappent aux revues de code parce qu’« il s’agit simplement de récupérer une valeur ».
Où se cache le risque FDemande de lask et FFormulaire de demande de lask
Le flacon.request et formulaire de demande de flacon sont des points d'entrée non fiables. Chaque valeur renvoyée provient directement du client et doit être considérée comme potentiellement hostile.
Le fait de ne pas valider ou nettoyer ces données peut entraîner des problèmes de sécurité critiques, notamment :
- Injection SQL
- Scripts intersites (XSS)
- Injection de modèle
- Injection de commandes Shell
Ces risques ne s’appliquent pas uniquement aux bases de données ou au rendu frontal ; les attaquants peuvent également exploiter les entrées utilisées dans les modèles ou transmises aux sous-processus.
Modèles de pseudo-code sûrs :
python
# ⚠️ Educational example only — not functional
env_target = input("Enter deployment environment: ")
simulate_deploy(env_target) # Simulated for demonstration
Préventif CI/CD application de la loi:
# 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)
Même si la syntaxe semble sûre, l’utilisation de valeurs brutes ou non vérifiées dans les modèles ou les commandes système peut devenir un vecteur d’injection sérieux.
Flux d'injection pratique (simulation sûre)
Voici comment se déroule généralement une faille d'injection, à l'aide d'un scénario fictif et sûr :
- Un utilisateur envoie un paramètre de requête élaboré à l’application.
- L'application lit la valeur en utilisant request.args.get() sans validation.
- Cette valeur est concaténée directement dans une requête SQL, une chaîne de modèle ou une commande shell.
- Le système exécute cette logique, sans connaître le contenu injecté.
Pseudo-code (non sécurisé, à titre illustratif uniquement) :
# 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
Trace de journal fictive :
[INFO] Incoming request: /user?id=unexpected_input
[DEBUG] Parsed user_id: unexpected_input
[DEBUG] Constructed SQL: SELECT * FROM users WHERE id = unexpected_input
Même si cet exemple utilise des espaces réservés, il reflète la manière dont de petits oublis dans la gestion des entrées peuvent conduire à des vulnérabilités critiques.
Les tests automatisés peuvent manquer cela car ils testent généralement des types d'entrée valides, et non des types malformés ou malveillants.
Risques cachés dans les dépendances utilisant Demande de flacon et Formulaire de demande de flacon
Votre code peut être propre, mais les packages tiers peuvent toujours vous nuire.
Certains plugins ou bibliothèques Flask appellent en interne une demande Flask ou un formulaire de demande Flask sans validation.
Exemple avec des packages fictifs :
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, les mises à jour automatisées des dépendances peuvent introduire silencieusement des appels requests.get non sécurisés ou des modèles de gestion des entrées vulnérables.
À quel point c'est dangereux Demande de flacon Bons d'utilisation Avis sur les codes passés
Dans les environnements en évolution rapide, les erreurs petites mais dangereuses passent souvent inaperçues, surtout lorsque le changement semble inoffensif.
Exemple pull request différence:
# Insecure example — do not run in production
- user_id = request.args.get("id")
+ user_id = request.args.get("id") # Still missing type casting
Commentaire du réviseur :
« Ça a l'air bien, il faut juste ajouter un paramètre. »
Ce type d’oubli est courant en raison de :
- Biais cognitif: les réviseurs peuvent supposer que request.args.get() est sûr par défaut.
- La pression du temps:les contrôles de sécurité passent au second plan lorsque les délais approchent.
- Différent familiarité: le changement semble mineur, il ne fait donc pas l'objet d'un examen approfondi.
Sans règles claires ni application automatisée, ces risques subtils se glissent dans la production sans être remarqués.
La prévention qui fonctionne
Pour atténuer les risques d’injection, combinez la validation des entrées, l’analyse automatisée et la couverture des tests.
Validation des entrées avec casting et liste blanche :
user_id = request.args.get("id", type=int)
if user_id not in [1, 2, 3]:
abort(400, "Invalid ID")
Le casting force la valeur vers un type sûr, tandis que la liste blanche garantit que seules les valeurs connues comme bonnes continuent.
Tests de sécurité des applications statiques (SAST) dans CI/CD:
name: Run SAST scan
run: sast-tool --scan src/ --fail-on "request.args.get without type"
Cette étape permet de détecter les données non validées request.args.get() or request.form.get() appels avant qu'ils n'atteignent la production.
Tests unitaires pour renforcer la désinfection :
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
Ces tests garantissent que l’application rejette systématiquement les entrées malformées ou malveillantes.
Intégration dans DevSecOps Pipelines
Application du middleware :
@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
Analyse de votre code et des dépendances tierces aide à détecter les demandes non sécurisées.get, les demandes Flask et l'utilisation du formulaire de demande Flask avant qu'elles n'atteignent la production.
Ce problème va au-delà de Flask
La gestion des entrées non sécurisées n'est pas propre à Flask ; elle existe dans tous les frameworks web. Heureusement, la solution est cohérente : valider les entrées au plus tôt et de manière stricte.
Django (pseudo-code sécurisé) :
# 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 (sécurisé par conception grâce aux indications de type) :
from fastapi import Query
@app.get("/items")
def read_items(id: int = Query(..., ge=1, le=3)):
return {"id": id}
Les deux exemples imposent le type et la plage d'entrée, garantissant que les données entrantes sont fiables avant d'atteindre une logique sensible.
Qu'il s'agisse de Flask, Django ou FastAPI, chaque paramètre de requête est un point d'injection potentiel s'il n'est pas validé correctement.
Utilisation de Xygeni pour la détection dans DevSecOps
Dans un environnement DevSecOps, les révisions manuelles ne suffisent pas. Xygéni automatise la détection des demandes de flacons non sécurisées, du formulaire de demande de flacons et de l'utilisation de requests.get.
Applications pratiques de DevSecOps :
- Analyses statiques: Drapeaux quelconques request.args.get() sans tapez=, et les appels de formulaire de demande de flacon manquent de validation.
- Analyse des dépendances: Surveille les bibliothèques pour détecter les modèles dangereux qui pourraient apparaître via des appels indirects.
- Blocage des fusions non sécurisées: CI/CD échoue si le nouveau code introduit des requêtes risquées.get ou un accès au formulaire non validé.
- Application des normes de base:Suivi des modifications pour empêcher les appels sécurisés de régresser vers des appels non sécurisés.
L’automatisation de ces contrôles réduit le risque d’erreur humaine et maintient la sécurité continue sans ralentir la livraison.
Alors, validez, désinfectez, automatisez
Voici l'essentiel : requests.get, flask request et flask request form sont tous non fiable par défautIls vous livreront volontiers des données malveillantes à moins que vous n'agissiez.
Vos trois règles :
- Valider entrées utilisant le casting et les listes blanches.
- Assainir avant que les données ne touchent des opérations sensibles.
- Automatisez chèques dans votre pipeline pour arrêter le code non sécurisé avant le déploiement.
Un seul gestionnaire de requêtes Flask non sécurisé, un champ de formulaire de requête Flask non vérifié ou un appel requests.get non protégé peuvent compromettre votre application. Considérez chaque paramètre comme potentiellement hostile et laissez votre DevSecOps s'en charger. pipeline appliquer les règles à chaque fois.
