Injection de Code.

L'injection de code (CWE-94) est la grande famille de failles dans lesquelles une entrée non fiable est intégrée à un élément que l'application traite ensuite comme du code, ce qui amène le runtime à l'exécuter. Contrairement à l'injection de commandes (qui atteint le shell de l'OS), l'injection de code s'exécute dans l'interpréteur propre de l'application. Cas concrets : injections basées sur eval en JavaScript ou Python, injection de templates côté serveur, injection de langages d'expression (OGNL, SpEL), désérialisation non sûre déclenchant des chaînes de gadgets, et chargement dynamique de classes depuis des données utilisateur. Une exploitation réussie procure typiquement l'exécution distante de code sous l'identité de l'application, souvent tremplin vers la compromission de l'hôte ou du cluster.

Trois cas emblématiques illustrent l'impact. Apache Struts CVE-2017-5638 permettait d'exécuter des expressions OGNL dans un en-tête Content-Type malformé ; une instance non corrigée a causé la brèche Equifax de 2017, exposant ~147 millions d'enregistrements. Log4Shell (CVE-2021-44228), CVSS 10.0, transformait toute chaîne journalisée contenant une recherche JNDI en chargement distant de classe Java. Spring4Shell (CVE-2022-22965) détournait le data-binding de Spring pour manipuler le ClassLoader et déposer un web shell.

flowchart TD
  A[Entrée non fiable] --> B{Atteint un sink qui évalue du code ?}
  B -->|eval / template / OGNL / deserialize| C[L'interpréteur exécute le code de l'attaquant]
  B -->|Validée / paramétrée| D[Traitée comme donnée inerte]
  C --> E[RCE sous l'identité de l'app]
  E --> F[Compromission de l'hôte / cluster]
  D --> G[Sûr]

Défenses : ne jamais construire de code, de templates ou d'expressions depuis l'entrée ; utiliser des API paramétrées et à liste d'autorisation ; désactiver ou isoler l'évaluation dynamique et la désérialisation ; corriger les frameworks rapidement ; et s'exécuter au moindre privilège pour que le RCE ait la plus petite portée possible.