L'injection de modèles côté serveur (SSTI) est une vulnérabilité où les entrées de l'utilisateur sont évaluées par un moteur de modèles au lieu d'être rendues en texte brut, permettant à un attaquant d'exécuter du code arbitraire sur le serveur.
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
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
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 :
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
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.
Points clés à 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
Xygéni Xygeni analyse votre code source à la recherche de failles d'injection et autres schémas de codage non sécurisés dès leur apparition, détectant les constructions à risque comme le rendu de modèles non nettoyés avant leur mise en production, avec le taux de faux positifs le plus faible du benchmark OWASP. CI/CD et IaC security La numérisation étend cette même couverture à pipeline Xygeni analyse les configurations, les graphiques Helm et les scripts de compilation, en signalant les erreurs de configuration et les commandes malveillantes avant leur déploiement. Lorsqu'une vulnérabilité est détectée, la fonction AI AutoFix génère un correctif contextuel et prêt à l'emploi pour les développeurs directement dans le code source. pull request, afin que la correction n'attende pas le prochain sprint.
En DevSecOps, la détection des injections de modèles au niveau de la pipeline C’est l’étape de déploiement, et non la phase finale, qui empêche une seule charge utile de compromettre totalement la sécurité.
Commencez gratuitement. Aucune carte de crédit requise, numérisez votre premier dossier de saisie en quelques minutes.
QFP
Qu'est-ce que l'injection de modèles côté serveur ?
Une attaque SSTI se produit lorsque les données saisies par l'utilisateur sont transmises à un moteur de modèles et évaluées comme du code au lieu d'être affichées sous forme de texte, permettant ainsi à un attaquant d'exécuter des commandes dans le contexte du serveur.
SSTI est-il la même chose que XSS ?
Non. Une attaque XSS injecte un script qui s'exécute dans le navigateur de la victime ; une attaque SSTI injecte du code que le moteur de modèles évalue sur le serveur lui-même, ce qui explique pourquoi une attaque SSTI peut conduire directement à l'exécution de code à distance.
Quels moteurs de templates sont vulnérables aux attaques SSTI ?
Tout moteur qui évalue des expressions peut être vulnérable si les entrées de l'utilisateur lui parviennent sans être nettoyées, y compris Jinja2, Twig et Velocity, bien que chacun expose des objets différents et donc des chemins d'exploitation différents.
Comment prévenir les infections cutanées et des tissus mous (ICTM) ? CI/CD pipelines?
Recherchez les schémas dangereux comme render_template_string at commit temps, moteurs de modèles sandbox lorsqu'ils étaient pris en charge, et fusions de contrôles sur les résultats d'analyse statique avant que le code n'atteigne la production.
