Trouver le sink RCE : repérer une injection eval() en Python
Le défi
Cette API de 'calcul rapide' exécute tout ce que vous envoyez. Une fonction native de Python transforme ça en exécution de code à distance. Lisez les deux fichiers et tapez le nom de cette fonction.
Ce que tu vas apprendre
- Reconnaître eval()/exec() sur une entrée non fiable comme un point d'exécution de code à distance (RCE)
- Suivre les données d'une requête depuis leur point d'entrée jusqu'à une fonction dangereuse, à travers plusieurs fichiers
- Distinguer l'exécution de code (eval) de l'analyse sûre de données (ast.literal_eval)
- Lire une petite base de code comme le ferait un relecteur : suivre l'entrée, trouver le sink
Compétences testées
Prérequis
- Lecture de base du Python
- Connaissance des paramètres de requête HTTP
Comment ça marche
L'exécution de code à distance (RCE) est la classe de vulnérabilité web la plus grave : l'attaquant fait exécuter au serveur du code de son choix. En Python, le sink classique est eval() (et sa cousine exec()). eval() prend une chaîne de caractères et l'évalue comme une expression Python, donc si une partie de cette chaîne vient de l'utilisateur, celui-ci peut exécuter du Python.
Cette application expose un endpoint de 'calcul rapide'. Elle lit expr depuis la chaîne de requête et le transmet directement à eval(). Une requête normale comme ?expr=2*21 renvoie 42, ce qui explique exactement pourquoi ce genre de bug passe inaperçu : ça ressemble à une calculatrice inoffensive. Mais un attaquant envoie ?expr=__import__('os').system('id') et le serveur exécute une commande shell. De là, il n'y a qu'un pas vers la lecture de fichiers, l'exfiltration de données ou l'implantation d'un shell.
Le correctif se trouve dans le second fichier. ast.literal_eval() n'analyse que les littéraux Python (nombres, chaînes, listes, dictionnaires) et refuse tout ce qui exécuterait du code. C'est le bon outil quand il faut transformer du texte en donnée. Le travail, dans une revue comme celle-ci, consiste à suivre la valeur non fiable (expr) depuis son point d'entrée jusqu'à ce qui la consomme, et à reconnaître que ce consommateur est une primitive d'exécution de code.
Erreurs fréquentes
- Supposer qu'une 'calculatrice' est inoffensive. Le nom sympathique de la fonctionnalité cache que eval exécute du code arbitraire, pas seulement de l'arithmétique.
- Pointer request.args au lieu du sink. Lire l'entrée n'est pas un problème ; le bug est ce que vous en faites. Nommez la fonction qui l'exécute.
- Confondre eval et literal_eval. Elles se ressemblent, mais une seule exécute du code : cette différence est toute la vulnérabilité.
Comment s'en protéger
Ne passez jamais d'entrée non fiable à eval() ou exec(). Pour de l'arithmétique, utilisez un véritable analyseur d'expressions ou une bibliothèque sûre. Pour transformer du texte en donnée, utilisez ast.literal_eval() ou json.loads().
- Interdisez
eval/execsur les données de requête en revue de code et via une règle de linter. - Considérez chaque paramètre de requête, en-tête et champ de corps comme contrôlé par l'attaquant.
- Préférez les listes blanches et l'analyse typée à l'évaluation de chaînes.
