Comment fonctionne l'injection de modèles côté serveur en coulisses
Une injection de modèles côté serveur se produit lorsque les données utilisateur sont intégrées directement dans un moteur de création de modèles et évaluées sans nettoyage ni isolation appropriés. Cela crée une vulnérabilité SSTI permettant à un attaquant d'injecter des charges utiles SSTI spécialement conçues (par exemple, {{7*7}} dans Jinja2), que le moteur évaluera, permettant ainsi tout, de la divulgation de données à l'exécution de code arbitraire dans le contexte du serveur. Comme les différents moteurs de modèles exposent des objets et des API différents, les charges utiles SSTI varient selon la plateforme, mais partagent le même danger : elles laissent des entrées non fiables échapper au flux de rendu attendu et s'exécuter pendant l'exécution de l'application, ce qui conduit souvent à une exécution complète de code à distance ou à un déplacement latéral si elles ne sont pas contrôlées.
Exemple minimal vulnérable dans Jinja2
from flask import request, render_template_string
@app.route("/hello")
def hello():
name = request.args.get("name", "world")
# ❌ Vulnerable: directly rendering user input
return render_template_string("Hello " + name)
Si un utilisateur envoie ?nom={{7*7}}, l'application l'évaluera et renverra Bonjour 49C'est une vulnérabilité SSTI typique.
Exemple minimal vulnérable dans Twig
// ❌ Vulnerable Twig usage
$template = $twig->createTemplate("Welcome " . $_GET['user']);
echo $template->render([]);
Un attaquant peut injecter des charges utiles SSTI comme {{7*7}} pour prouver l'exécution du code. Le danger : une simple injection peut entraîner la lecture de fichiers, l’exécution de commandes du système d’exploitation ou une pénétration plus profonde dans l’infrastructure.
Exploits du monde réel : charges utiles SSTI qui déclenchent l'exécution de code à distance
Une fois qu'une vulnérabilité SSTI existe, les attaquants tentent de passer des mathématiques de preuve de concept à la preuve complète. RCEDifférents moteurs de modèles gèrent les charges utiles différemment.
Charges utiles Jinja2
- {{7*7}} → exécution arithmétique
- {{config.items()}} → fuites de configurations de serveur.
- {{ ”.__class__.__mro__[2].__subclasses__() }} → chemin vers RCE
Charges utiles de vitesse
- #set($x=”7″)${x} → dérivation d'injection
- #set($a=$class.inspect(“java.lang.Runtime”)) → accès direct à l'exécution
Charges utiles Twig
- {{7*7}} → arithmétique
- {{app.request.server.all}} → variables d'environnement
- {{_self.env.registerUndefinedFilterCallback(‘system’)}} → exécution de code
Ces charges utiles SSTI démontrent comment la même vulnérabilité dans différents moteurs conduit à des résultats différents. exploiter les chemins, mais ils sont toujours dangereux.
Où se cache l'injection de modèles côté serveur CI/CD-Applications pilotées
L'injection de modèles côté serveur n'est pas seulement un risque pour les applications Web ; elle apparaît dans moderne CI/CD pipelines également. Les cachettes typiques comprennent :
- Cartes de barre dans Kubernetes, où les valeurs des modèles sont rendues dynamiquement
- Modèles de courriel qui concatènent les entrées contrôlées par l'utilisateur
- Dashboards où les chaînes de requête ou les données de configuration sont injectées dans les modèles
- Scripts DevOps qui génèrent du HTML/Markdown à l'aide de moteurs de création de modèles.
Exemple :
# ❌ Insecure Helm values with user input
configMap:
appMessage: "{{ .Values.message }}"
If.Valeurs.message provient d'une entrée non fiable, elle introduit une injection de modèle côté serveur dans votre déploiement pipeline elle-même.
Prévention des infections sexuellement transmissibles (IST) grâce à des modèles plus sûrs et à l'analyse statique
L’atténuation des vulnérabilités SSTI nécessite de meilleurs modèles de codage et une détection précoce.
Modèles sécurisés
- ❌ Ne pas utiliser chaîne_de_modèle_de_rendu ou équivalent
- ✅ Utilisez des fichiers de modèles prédéfinis et transmettez des variables aseptisées
- ✅ Moteurs de modèles Sandbox lorsqu'ils sont disponibles
- ✅ Valider et échapper la saisie utilisateur avant le rendu
Gestion des cookies non sécurisée ou sécurisée (risque d'entrée associé)
# ❌ Insecure: session cookie without flags
response.set_cookie("session", token)
# ✅ Secure: session cookie hardened
response.set_cookie("session", token, httponly=True, secure=True, samesite="Strict")
Mini-liste de contrôle pour les développeurs
- Ne jamais restituer directement les entrées utilisateur brutes
- Utiliser des modèles sandboxés lorsque cela est pris en charge
- Désinfecter et valider toutes les variables du modèle
- Évitez les évaluateurs de modèles personnalisés
- Scannez le code pour chaîne_de_modèle_de_rendu ou des modèles de concaténation de chaînes
Analyse statique et les linters peuvent signaler les constructions risquées avant qu'elles n'atteignent la production.
Intégration des contrôles SSTI dans DevSecOps Pipelines
Détecter précocement l'injection de modèles côté serveur est moins coûteux et plus sûr que de la corriger ultérieurement. Les équipes DevSecOps devraient intégrer des contrôles. pipelines:
- Commit hooks: rejeter commits avec des fonctions dangereuses (chaîne_de_modèle_de_rendu)
- Analyseurs statiques: recherche de risque d'injection de modèle côté serveur dans le code de création de modèles
- Validation des dépendances: signaler les moteurs de modèles obsolètes présentant des vulnérabilités SSTI connues
- Pipeline portes: le bloc fusionne jusqu'à ce que les contrôles SSTI réussissent
En faisant de la détection de charge utile SSTI une partie de CI/CD, vous empêchez l'expédition de code exploitable.
Ne laissez pas l'injection de modèles côté serveur s'infiltrer dans votre pile
Une seule injection de modèle côté serveur peut aller jusqu'à des astuces mathématiques ({{7*7}}) à l'exécution complète de code à distance. Les vulnérabilités SSTI apparaissent non seulement dans les applications Web, mais aussi dans CI/CD pipelines, graphiques Helm et modèles d'e-mails.
Principaux points à retenir
- Ne jamais restituer les entrées utilisateur brutes dans des modèles
- Valider et assainir toutes les variables dynamiques
- Différents moteurs (Jinja2, Velocity, Twig) ont des charges utiles SSTI différentes, mais tous peuvent être militarisés
- Utiliser l'analyse statique et les portes de défaillance rapide dans pipelines
- Auditez régulièrement les modèles de votre pile
Des outils comme Xygéni aider les équipes à détecter l'utilisation non sécurisée des modèles, à bloquer les vulnérabilités SSI et à appliquer des pratiques sécurisées pipelines et dépendances. Dans DevSecOps, traiter les charges utiles SSTI comme un risque de premier ordre est essentiel car une seule injection dans votre pipeline ou une application peut compromettre l'ensemble de votre environnement.
