La server-side template injection est une faille de sécurité souvent peu recherchée. Une injection de modèle côté serveur peut pourtant avoir des conséquences importantes. Afin de mieux protéger les sites et applications utilisant des moteurs de template, il est essentiel de s’informer. Cet article fait le point sur la définition des SSTI et sur les manières dont les attaquants peuvent les exploiter.
Qu’est-ce qu’une server-side template injection ?
Une server-side template injection est une attaque consistant à tirer profit de l’utilisation d’un moteur de template. Le hacker injecte des payloads malveillants via les entrées utilisateurs disponibles. Si les fichiers de template du framework web utilisé sont mal sécurisés, il est possible d’envoyer des directives de modèle arbitraires.
Le template visé est modifié avant rendering, et le code est exécuté côté serveur. Pour rappel, les moteurs de template permettent de faciliter la gestion et la présentation de données dynamiques sur les pages web. On parle de SSTI lorsque les user inputs sont interprétés en tant que données dynamiques, au lieu de données fixes.
Un exemple couramment utilisé consiste à personnaliser un email en fonction du nom de chaque utilisateur. Admettons pour cette démonstration que le user a la possibilité de personnaliser son nom, avant l’envoi du mail. Voici une ligne de code pouvant correspondre :
$output = $twig->render("Dear " . $_GET['name']);
Ici, on est bien en présence d’une vulnérabilité à une attaque SSTI. Il est en effet possible d’utiliser le paramètre GET name pour réaliser une server-side template injection comme ceci :
http://site-vulnerable.com/?name={{code-malicieux}}
NB : On retrouve le plus souvent des vulnérabilités SSTI au sein de CMS, d’applications web liées au marketing, de wikis ou encore de blogs.
Quelles sont les conséquences d’une attaque SSTI ?
Les sites et applications web vulnérables à une attaque SSTI s’exposent à différents types de dangers. Dans la majorité des cas, l’impact est critique, et mène à une exécution de code à distance (RCE). Une server-side template injection peut également exposer la victime à des fuites d’informations. Des payloads peuvent être utilisés pour créer une attaque par déni de service (DoS).
Le hacker a la possibilité de s'en prendre à d’autres utilisateurs. Il est parfois en mesure d’usurper leur identité, par exemple. Ce type de faille peut également permettre d’abuser d’une vulnérabilité d’élévation de privilèges. Les risques exacts d’une attaque SSTI varient cependant en fonction du moteur de template et du langage de templating associé.
Comment réaliser une server-side template injection ?
Les attaques server-side template injection se construisent en trois étapes clés. On commence systématiquement par confirmer la présence d’une vulnérabilité SSTI. Il faut ensuite identifier le framework web et le moteur de template associé. Un travail de recherche final permet de mettre en lumière les différentes exploitations possibles.
1 – Détecter la vulnérabilité SSTI
La principale manière de détecter une vulnérabilité SSTI est d’utiliser la technique du fuzzing. On injecte alors des payloads dans tous les champs de données accessibles aux utilisateurs. Il s’agit ici de séquences de caractères spéciaux, que l’on retrouve souvent dans les expressions de modèles. Un message d’erreur ou tout autre comportement étrange est généralement synonyme de faille de sécurité SSTI.
Il est important de noter que les techniques de détection de vulnérabilité utilisées dépendent du contexte. Une requête d’utilisateur peut être insérée dans un cadre de :
- Plaintext context, ou contexte en texte brut ;
- Code context, ou context de code.
Dans le cas du plaintext context, il est facile de confondre les failles trouvées avec un simple danger d’attaque de Cross-Site Scripting, ou XSS. Il faut alors vérifier que l’injection se fait bien côté serveur, et non côté client.
2 – Identifier le moteur de template
Dès lors qu’il y a une suspicion de faille SSTI, la deuxième étape consiste à tenter d’identifier le moteur de template utilisé. Si le serveur affiche les erreurs obtenues via les payloads utilisés, le travail d’enquête est grandement facilité. Dans le cas contraire, il faut procéder par élimination, grâce à une succession de payloads.
On peut ainsi voir quel type de syntaxe est interprété et commencer à en tirer des conclusions. Cependant, une même entrée peut obtenir une réponse de la part de différents moteurs de template. Les conclusions hâtives sont donc à proscrire. Des arbres de décision connus permettent d’accélérer le processus d’identification du moteur.
3 – Rechercher les exploitations possibles
Une fois que le moteur de template est identifié, un nouveau travail de recherche commence. Dans certains cas, des attaques de server-side template injection déjà connues sont répertoriées en ligne. Il suffit alors d’utiliser les payloads correspondants. La documentation du moteur elle-même peut également donner des pistes d’exploitation. En cas de résultats infructueux, l’attaquant effectue une exploration manuelle de l’environnement.
Il est important de noter qu’il existe deux types de moteurs de template :
- Les templates « logic-less »;
- Les templates « logical ».
Dans le cas d’un modèle logical, il est possible d’utiliser la logique de l’application afin de multiplier les possibilités. Après avoir trouvé les payloads utiles et confirmé la surface d’attaque disponible, on peut lancer l’exploitation de la faille SSTI.
.png)
.png)
.png)
