SSTI : l'injection de template côté serveur
Moins connue que d'autres failles, l'injection de template côté serveur (SSTI) est pourtant à fort impact : elle mène souvent à l'exécution de code à distance sur le serveur. Une vulnérabilité à ne surtout pas sous-estimer.
Qu'est-ce qu'une vulnérabilité SSTI ?
De nombreuses applications utilisent un moteur de templates pour séparer la présentation (HTML, CSS) de la logique (PHP, Python…). Le template mêle des données fixes (la mise en page) et des données dynamiques (les variables) ; le moteur remplace les variables par leurs valeurs pour produire la page finale.
Une SSTI survient lorsqu'une donnée fournie par l'utilisateur est intégrée directement dans le template puis interprétée par le moteur, au lieu d'être traitée comme une simple valeur. L'attaquant peut alors injecter des expressions interprétées par le moteur, jusqu'à, dans certains cas, prendre le contrôle du serveur. C'est un sujet classique des tests d'intrusion applicatifs.
Où le risque apparaît
La personnalisation avancée
Sites offrant des fonctions de personnalisation poussées (wikis, blogs, applications marketing, CMS) où l'utilisateur peut modifier des modèles.
Les modèles d'e-mails
Une application qui laisse l'utilisateur éditer le gabarit d'un e-mail automatique : si ses expressions sont évaluées, la fonction devient vulnérable.
Jusqu'à l'exécution de code
Selon le contexte, une SSTI peut mener à l'exécution de code à distance (RCE) et à la compromission du serveur, l'impact maximal.
D'autres attaques possibles
Sans aller jusqu'à la RCE, elle peut permettre la lecture de fichiers, des fuites d'informations ou une élévation de privilèges.
Une faille discrète mais lourde de conséquences
La SSTI est moins recherchée que le XSS ou l'injection SQL, simplement parce qu'elle est moins connue. C'est précisément ce qui la rend dangereuse : elle passe souvent inaperçue lors des contrôles superficiels, alors que son impact peut être maximal. Dès qu'une fonctionnalité laisse un utilisateur influencer un template, le sujet mérite un examen attentif dans le cadre d'une démarche de sécurité applicative.
Le principe de défense : ne jamais rendre l'utilisateur « auteur » du template
La règle d'or : les données utilisateur doivent être passées comme valeurs au template, jamais concaténées dans le modèle lui-même. Quand une personnalisation de gabarit est nécessaire, on s'appuie sur un moteur en mode « bac à sable » (sandbox), on restreint sévèrement les fonctions accessibles, et on valide rigoureusement les entrées. La détection, elle, passe par l'injection de caractères spéciaux propres aux moteurs de templates, typiquement lors d'un test d'intrusion.
Prévenir une SSTI, étape par étape
Séparer données et template
Transmettre les données utilisateur en variables, sans jamais les insérer dans la structure du modèle.
Éviter l'édition de templates
Limiter au maximum les fonctions permettant à un utilisateur de modifier un gabarit ; les réserver à des profils de confiance.
Cloisonner le moteur
Utiliser un moteur en mode bac à sable et désactiver les fonctions dangereuses ou inutiles.
Valider les entrées
Filtrer les caractères et expressions propres aux moteurs de templates dans les champs concernés.
Appliquer le moindre privilège
Restreindre les droits du processus serveur pour limiter l'impact d'une exploitation réussie.
Tester spécifiquement
Faire chercher la SSTI lors d'un pentest, car elle échappe aux contrôles génériques.
Pourquoi se faire accompagner par BCIT ?
Une recherche spécialisée
Nous testons spécifiquement la SSTI, là où des contrôles automatiques passeraient à côté.
Des correctifs adaptés
Des recommandations en phase avec votre moteur de templates et vos cas d'usage réels.
Une couverture complète
De la sécurité applicative aux audits de sécurité, nous couvrons toute la chaîne.
Pas encore prêt à échanger ? Découvrez notre diagnostic cybersécurité →
Vos moteurs de templates sont-ils sous contrôle ?
Prenons 15 minutes pour évaluer l'exposition de vos applications à la SSTI et définir les mesures de prévention adaptées.
SSTI : l'injection de template côté serveur
Moins connue que d'autres failles, l'injection de template côté serveur (SSTI) est pourtant à fort impact : elle mène souvent à l'exécution de code à distance sur le serveur. Une vulnérabilité à ne surtout pas sous-estimer.
Qu'est-ce qu'une vulnérabilité SSTI ?
De nombreuses applications utilisent un moteur de templates pour séparer la présentation (HTML, CSS) de la logique (PHP, Python…). Le template mêle des données fixes (la mise en page) et des données dynamiques (les variables) ; le moteur remplace les variables par leurs valeurs pour produire la page finale.
Une SSTI survient lorsqu'une donnée fournie par l'utilisateur est intégrée directement dans le template puis interprétée par le moteur, au lieu d'être traitée comme une simple valeur. L'attaquant peut alors injecter des expressions interprétées par le moteur, jusqu'à, dans certains cas, prendre le contrôle du serveur. C'est un sujet classique des tests d'intrusion applicatifs.
Où le risque apparaît
La personnalisation avancée
Sites offrant des fonctions de personnalisation poussées (wikis, blogs, applications marketing, CMS) où l'utilisateur peut modifier des modèles.
Les modèles d'e-mails
Une application qui laisse l'utilisateur éditer le gabarit d'un e-mail automatique : si ses expressions sont évaluées, la fonction devient vulnérable.
Jusqu'à l'exécution de code
Selon le contexte, une SSTI peut mener à l'exécution de code à distance (RCE) et à la compromission du serveur, l'impact maximal.
D'autres attaques possibles
Sans aller jusqu'à la RCE, elle peut permettre la lecture de fichiers, des fuites d'informations ou une élévation de privilèges.
Une faille discrète mais lourde de conséquences
La SSTI est moins recherchée que le XSS ou l'injection SQL, simplement parce qu'elle est moins connue. C'est précisément ce qui la rend dangereuse : elle passe souvent inaperçue lors des contrôles superficiels, alors que son impact peut être maximal. Dès qu'une fonctionnalité laisse un utilisateur influencer un template, le sujet mérite un examen attentif dans le cadre d'une démarche de sécurité applicative.
Le principe de défense : ne jamais rendre l'utilisateur « auteur » du template
La règle d'or : les données utilisateur doivent être passées comme valeurs au template, jamais concaténées dans le modèle lui-même. Quand une personnalisation de gabarit est nécessaire, on s'appuie sur un moteur en mode « bac à sable » (sandbox), on restreint sévèrement les fonctions accessibles, et on valide rigoureusement les entrées. La détection, elle, passe par l'injection de caractères spéciaux propres aux moteurs de templates, typiquement lors d'un test d'intrusion.
Prévenir une SSTI, étape par étape
Séparer données et template
Transmettre les données utilisateur en variables, sans jamais les insérer dans la structure du modèle.
Éviter l'édition de templates
Limiter au maximum les fonctions permettant à un utilisateur de modifier un gabarit ; les réserver à des profils de confiance.
Cloisonner le moteur
Utiliser un moteur en mode bac à sable et désactiver les fonctions dangereuses ou inutiles.
Valider les entrées
Filtrer les caractères et expressions propres aux moteurs de templates dans les champs concernés.
Appliquer le moindre privilège
Restreindre les droits du processus serveur pour limiter l'impact d'une exploitation réussie.
Tester spécifiquement
Faire chercher la SSTI lors d'un pentest, car elle échappe aux contrôles génériques.
Pourquoi se faire accompagner par BCIT ?
Une recherche spécialisée
Nous testons spécifiquement la SSTI, là où des contrôles automatiques passeraient à côté.
Des correctifs adaptés
Des recommandations en phase avec votre moteur de templates et vos cas d'usage réels.
Une couverture complète
De la sécurité applicative aux audits de sécurité, nous couvrons toute la chaîne.
Pas encore prêt à échanger ? Découvrez notre diagnostic cybersécurité →
Vos moteurs de templates sont-ils sous contrôle ?
Prenons 15 minutes pour évaluer l'exposition de vos applications à la SSTI et définir les mesures de prévention adaptées.