<summary><strong>Apprenez le piratage AWS de zéro à héros avec</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Si vous souhaitez voir votre **entreprise annoncée dans HackTricks** ou **télécharger HackTricks en PDF**, consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop)!
* Obtenez le [**merchandising officiel PEASS & HackTricks**](https://peass.creator-spring.com)
* Découvrez [**La Famille PEASS**](https://opensea.io/collection/the-peass-family), notre collection d'[**NFTs**](https://opensea.io/collection/the-peass-family) exclusifs
* **Rejoignez le** 💬 [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe telegram**](https://t.me/peass) ou **suivez**-moi sur **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Partagez vos astuces de piratage en soumettant des PR aux dépôts github** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
[**RootedCON**](https://www.rootedcon.com) est l'événement de cybersécurité le plus pertinent en **Espagne** et l'un des plus importants en **Europe**. Avec **la mission de promouvoir la connaissance technique**, ce congrès est un point de rencontre bouillonnant pour les professionnels de la technologie et de la cybersécurité dans toutes les disciplines.
Une injection de modèle côté serveur se produit lorsqu'un attaquant est capable d'utiliser la syntaxe native du modèle pour injecter une charge malveillante dans un modèle, qui est ensuite exécutée côté serveur.
Les **moteurs de modèles** sont conçus pour **générer des pages web** en **combinant** des modèles **fixes** avec des données **volatiles**. Les attaques par injection de modèle côté serveur peuvent se produire lorsque **l'entrée de l'utilisateur** est concaténée directement **dans un modèle**, plutôt que passée en tant que données. Cela permet aux attaquants d'**injecter des directives de modèle arbitraires** afin de manipuler le moteur de modèle, leur permettant souvent de prendre le **contrôle complet du serveur**.
Dans l'exemple précédent, **une partie du modèle** est **générée dynamiquement** en utilisant le paramètre `GET``name`. Comme la syntaxe du modèle est évaluée côté serveur, cela permet potentiellement à un attaquant de placer un payload d'injection de modèle côté serveur à l'intérieur du paramètre `name` comme suit :
Comme pour toute vulnérabilité, la première étape vers l'exploitation est de pouvoir la trouver. Peut-être que l'approche initiale la plus simple est d'essayer de **fuzzer le modèle** en injectant une séquence de caractères spéciaux couramment utilisés dans les expressions de modèle, tels que le polyglotte **`${{<%[%'"}}%\`.**\
Pour vérifier si le serveur est vulnérable, vous devez **repérer les différences** entre la réponse avec des **données régulières** sur le paramètre et le **payload donné**.\
Si une **erreur est déclenchée**, il sera assez facile de déterminer que **le serveur est vulnérable** et même quel **moteur est en cours d'exécution**. Mais vous pourriez également trouver un serveur vulnérable si vous vous attendiez à ce qu'il **reflète** le payload donné et qu'il **n'est pas reflété**, ou s'il y a des **caractères manquants** dans la réponse.
L'entrée donnée est **rendue et reflétée** dans la réponse. Cela est facilement **confondu avec une simple** vulnérabilité [**XSS**](../xss-cross-site-scripting/), mais il est facile de différencier si vous essayez de définir des **opérations mathématiques** à l'intérieur d'une expression de modèle :
Si vous **changez** le paramètre **`greeting`** pour une **valeur différente**, la **réponse ne contiendra pas le nom d'utilisateur**, mais si vous accédez à quelque chose comme : `http://vulnerable-website.com/?greeting=data.username}}hello`, alors, **la réponse contiendra le nom d'utilisateur** (si les caractères de fermeture de l'expression de template étaient **`}}`**).\
Si une **erreur** est générée lors de ces tests, il sera plus facile de détecter que le serveur est vulnérable.
Une fois que vous avez détecté le potentiel d'injection de template, l'étape suivante est d'identifier le moteur de template.\
Bien qu'il existe un grand nombre de langages de templating, beaucoup utilisent une syntaxe très similaire qui est spécifiquement choisie pour ne pas entrer en conflit avec les caractères HTML.
Si vous avez de la chance, le serveur **affichera les erreurs** et vous pourrez trouver le **moteur** utilisé **à l'intérieur** des erreurs. Voici quelques charges utiles qui peuvent provoquer des erreurs :
Sinon, vous devrez **tester manuellement différentes charges utiles spécifiques au langage** et étudier comment elles sont interprétées par le moteur de template. Une manière courante de faire cela est d'injecter des opérations mathématiques arbitraires en utilisant la syntaxe de différents moteurs de template. Vous pouvez ensuite observer si elles sont évaluées avec succès. Pour faciliter ce processus, vous pouvez utiliser un arbre de décision similaire au suivant :
La première étape après avoir trouvé une injection de template et identifié le moteur de template est de lire la documentation. Les domaines clés d'intérêt sont :
* Les sections 'Pour les auteurs de templates' couvrant la syntaxe de base.
* 'Considérations de sécurité' - il y a des chances que celui qui a développé l'application que vous testez n'ait pas lu cela, et cela peut contenir des indices utiles.
* Listes de méthodes, fonctions, filtres et variables intégrés.
* Listes d'extensions/plugins - certains peuvent être activés par défaut.
En supposant qu'aucune faille ne se soit présentée, l'étape suivante est d'**explorer l'environnement** pour découvrir exactement à **quoi vous avez accès**. Vous pouvez vous attendre à trouver à la fois des **objets par défaut** fournis par le moteur de template, et des **objets spécifiques à l'application** passés dans le template par le développeur. De nombreux systèmes de template exposent un objet 'self' ou un espace de noms contenant tout ce qui est dans le scope, et une manière idiomatique de lister les attributs et méthodes d'un objet.
S'il n'y a pas d'objet self intégré, vous allez devoir forcer les noms de variables en utilisant [SecLists](https://github.com/danielmiessler/SecLists/blob/25d4ac447efb9e50b640649f1a09023e280e5c9c/Discovery/Web-Content/burp-parameter-names.txt) et la collection de listes de mots de Burp Intruder.
Les objets fournis par les développeurs sont particulièrement susceptibles de contenir des informations sensibles et peuvent varier entre différents templates au sein d'une application, donc ce processus devrait idéalement être appliqué à chaque template distinct individuellement.
À ce stade, vous devriez avoir une **idée précise de la surface d'attaque disponible** et être en mesure de procéder avec les techniques d'audit de sécurité traditionnelles, en examinant chaque fonction pour des vulnérabilités exploitables. Il est important d'aborder cela dans le contexte de l'application plus large - certaines fonctions peuvent être utilisées pour exploiter des fonctionnalités spécifiques à l'application. Les exemples à suivre utiliseront l'injection de template pour déclencher la création d'objets arbitraires, la lecture/écriture de fichiers arbitraires, l'inclusion de fichiers distants, la divulgation d'informations et les vulnérabilités d'élévation de privilèges.
### [Tableau d'injection de modèles](https://github.com/Hackmanit/template-injection-table)
un tableau interactif contenant les polyglottes d'injection de modèles les plus efficaces ainsi que les réponses attendues des 44 moteurs de modèles les plus importants.
* Dans la section FreeMarker de [https://portswigger.net/research/server-side-template-injection](https://portswigger.net/research/server-side-template-injection)
* Dans la section Velocity de [https://portswigger.net/research/server-side-template-injection](https://portswigger.net/research/server-side-template-injection)
L'expression de test typique pour SSTI est `${7*7}`. Cette expression fonctionne également dans Thymeleaf. Si vous souhaitez réaliser une exécution de code à distance, vous pouvez utiliser l'une des expressions de test suivantes :
Cependant, comme nous l'avons mentionné précédemment, les expressions ne fonctionnent que dans des attributs spéciaux de Thymeleaf. Si vous devez utiliser une expression dans un autre emplacement du modèle, Thymeleaf prend en charge _l'insertion d'expressions_. Pour utiliser cette fonctionnalité, vous devez placer une expression à l'intérieur de `[[...]]` ou `[(...)]` (choisissez l'un ou l'autre en fonction de la nécessité d'échapper aux symboles spéciaux). Par conséquent, un payload de détection SSTI simple pour Thymeleaf serait `[[${7*7}]]`.
Cependant, les chances que le payload de détection ci-dessus fonctionne sont très faibles. Les vulnérabilités SSTI se produisent généralement lorsque un modèle est généré dynamiquement dans le code. Par défaut, Thymeleaf ne permet pas de tels modèles générés dynamiquement et tous les modèles doivent être créés au préalable. Par conséquent, si un développeur souhaite créer un modèle à partir d'une chaîne _à la volée_, il devra créer son propre TemplateResolver. C'est possible mais cela arrive très rarement.
Si nous examinons plus en détail la documentation du moteur de modèles Thymeleaf, nous trouverons une fonctionnalité intéressante appelée _**prétraitement des expressions**_. Les expressions placées entre doubles underscores (`__...__`) sont prétraitées et le résultat du prétraitement est utilisé comme partie de l'expression pendant le traitement régulier. Voici un exemple officiel de la documentation Thymeleaf :
* [Payloads all the things](https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Server%20Side%20Template%20Injection/README.md#java---retrieve-etcpasswd)
//Here, I created a variable 'ji' with new instance of com.hubspot.jinjava.Jinjava class and obtained reference to the newInterpreter method. In the next block, I called the render method on 'ji' with expression {{1*2}}.
EL fournit un mécanisme important pour permettre à la couche de présentation (pages web) de communiquer avec la logique d'application (managed beans). EL est utilisé par **plusieurs technologies JavaEE**, telles que la technologie JavaServer Faces, la technologie JavaServer Pages (JSP) et l'injection de dépendances et de contextes pour Java EE (CDI).\
Cette méthode de contournement du Security Manager a été prise de ce [**compte-rendu**](https://security.humanativaspa.it/groovy-template-engine-exploitation-notes-from-a-real-case-scenario/).
[**RootedCON**](https://www.rootedcon.com/) est l'événement de cybersécurité le plus pertinent en **Espagne** et l'un des plus importants en **Europe**. Avec **la mission de promouvoir le savoir-faire technique**, ce congrès est un point de rencontre incontournable pour les professionnels de la technologie et de la cybersécurité dans toutes les disciplines.
* Dans la section Smarty de [https://portswigger.net/research/server-side-template-injection](https://portswigger.net/research/server-side-template-injection)
* Dans la section Twig et Twig (Sandboxed) de [https://portswigger.net/research/server-side-template-injection](https://portswigger.net/research/server-side-template-injection)
* Dans la section Jade de [https://portswigger.net/research/server-side-template-injection](https://portswigger.net/research/server-side-template-injection)
> [patTemplate](https://github.com/wernerwa/pat-template) est un moteur de template PHP non-compilant, qui utilise des balises XML pour diviser un document en différentes parties
> Jinja2 est un moteur de template complet pour Python. Il prend entièrement en charge l'unicode, dispose d'un environnement d'exécution optionnel intégré et sécurisé, est largement utilisé et sous licence BSD.
[**Exécution de code à distance non dépendante de**](https://podalirius.net/en/articles/python-vulnerabilities-code-execution-in-jinja-templates/) `__builtins__`:
La méthode `System.Diagnostics.Process.Start` de .NET peut être utilisée pour démarrer n'importe quel processus sur le serveur et ainsi créer un webshell. Vous pouvez trouver un exemple d'application web vulnérable sur [https://github.com/cnotin/RazorVulnerableApp](https://github.com/cnotin/RazorVulnerableApp)
*`{{ . }}` = structure de données passée en entrée au template
* Si les données passées sont un objet qui contient l'attribut Password par exemple, la charge utile précédente le divulguerait, mais vous pourriez également faire : `{{ .Password }}`
*`{{printf "%s" "ssti" }}` = devrait afficher la chaîne ssti dans la réponse
*`{{html "ssti"}}`, `{{js "ssti"}}` = Ce sont quelques autres charges utiles qui devraient afficher la chaîne "ssti" sans les mots suivants "js" ou "html". Vous pouvez vous référer à plus de mots-clés dans le moteur [ici](https://golang.org/pkg/text/template).
Si le serveur **utilise le package text/template**, l'exploitation XSS est très facile à réaliser en **fournissant simplement** votre **charge utile** en entrée. Cependant, ce **n'est pas le cas avec html/template** car il encode en HTML la réponse : `{{"<script>alert(1)</script>"}}` --> `<script>alert(1)</script>`
La documentation pour le module html/template peut être trouvée [ici](https://golang.org/pkg/html/template/), et la documentation pour le module text/template peut être trouvée [ici](https://golang.org/pkg/text/template/), et oui, elles varient beaucoup. Par exemple, dans **text/template**, vous pouvez **appeler directement n'importe quelle fonction publique avec la valeur “call”**, ce qui n'est pas le cas avec html/template.
Si vous voulez trouver un RCE en Go via SSTI, vous devez savoir que comme vous pouvez accéder à l'objet donné au template avec `{{ . }}`, vous pouvez également **appeler les méthodes de l'objet**. Ainsi, imaginez que l'**objet passé a une méthode appelée System** qui exécute la commande donnée, vous pourriez en abuser avec : `{{ .System "ls" }}`\
Consultez le reste de [https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Server%20Side%20Template%20Injection](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Server%20Side%20Template%20Injection) pour plus d'exploits. Vous pouvez également trouver des informations intéressantes sur les balises dans [https://github.com/DiogoMRSilva/websitesVulnerableToSSTI](https://github.com/DiogoMRSilva/websitesVulnerableToSSTI)
[**RootedCON**](https://www.rootedcon.com/) est l'événement de cybersécurité le plus pertinent en **Espagne** et l'un des plus importants en **Europe**. Avec **la mission de promouvoir la connaissance technique**, ce congrès est un point de rencontre incontournable pour les professionnels de la technologie et de la cybersécurité dans toutes les disciplines.
<summary><strong>Apprenez le piratage AWS de zéro à héros avec</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Si vous souhaitez voir votre **entreprise annoncée dans HackTricks** ou **télécharger HackTricks en PDF**, consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop)!
* Obtenez le [**merchandising officiel PEASS & HackTricks**](https://peass.creator-spring.com)
* **Rejoignez le** 💬 [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe Telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Partagez vos astuces de piratage en soumettant des PR aux dépôts github** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
