* Travaillez-vous dans une **entreprise de cybersécurité** ? Voulez-vous voir votre **entreprise annoncée dans HackTricks** ? ou voulez-vous avoir accès à la **dernière version de PEASS ou télécharger HackTricks en PDF** ? Consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop) !
* Découvrez [**The PEASS Family**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Obtenez le [**swag officiel PEASS & HackTricks**](https://peass.creator-spring.com)
* **Rejoignez le** [**💬**](https://emojipedia.org/speech-balloon/) [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Partagez vos astuces de piratage en soumettant des PR au** [**repo hacktricks**](https://github.com/carlospolop/hacktricks) **et au** [**repo 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 **pour mission de promouvoir les connaissances techniques**, ce congrès est un point de rencontre bouillonnant pour les professionnels de la technologie et de la cybersécurité dans chaque discipline.
Une injection de modèle côté serveur se produit lorsqu'un attaquant est capable d'utiliser la syntaxe de modèle native pour injecter une charge utile malveillante dans un modèle, qui est ensuite exécuté côté serveur.
Les **moteurs de modèle** sont conçus pour **générer des pages web** en **combinant** des modèles **fixes** avec des données **volatiles**. Les attaques d'injection de modèle côté serveur peuvent se produire lorsque l'**entrée utilisateur** est concaténée directement **dans un modèle**, plutôt que transmise 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 elle-même **générée dynamiquement** en utilisant le paramètre `name` de la méthode `GET`. Comme la syntaxe du modèle est évaluée côté serveur, cela permet potentiellement à un attaquant de placer une charge utile d'injection de modèle côté serveur dans le paramètre `name` comme suit :
Comme pour toute vulnérabilité, la première étape vers l'exploitation est de pouvoir la trouver. Peut-être la méthode la plus simple consiste à 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 **`${{<%[%'"}}%\`.**\
Afin de 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 la **charge utile donnée**.\
Si une **erreur est renvoyé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** la charge utile donnée et qu'il ne le fait **pas** 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 peut facilement être **confondu avec une vulnérabilité** [**XSS**](../xss-cross-site-scripting/) simple, mais il est facile de différencier si vous essayez de définir des **opérations mathématiques** dans une expression de modèle :
Si vous **modifiez** 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 modèle étaient **`}}`**).\
Si une **erreur** est générée pendant ces tests, il sera plus facile de trouver que le serveur est vulnérable.
Une fois que vous avez détecté le potentiel d'injection de modèle, la prochaine étape consiste à identifier le moteur de modèle.\
Bien qu'il existe un grand nombre de langages de modélisation, beaucoup d'entre eux 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 **imprimera les erreurs** et vous pourrez trouver le **moteur** utilisé **à l'intérieur** des erreurs. Certains payloads possibles qui peuvent causer des erreurs sont :
Sinon, vous devrez **tester manuellement différents payloads spécifiques à la langue** et étudier comment ils sont interprétés par le moteur de modèle. Une façon courante de faire cela est d'injecter des opérations mathématiques arbitraires en utilisant la syntaxe de différents moteurs de modèle. Vous pouvez ensuite observer s'ils sont évalués avec succès. Pour vous aider dans ce processus, vous pouvez utiliser un arbre de décision similaire à celui-ci :
La première étape après avoir trouvé l'injection de modèle et identifié le moteur de modèle consiste à lire la documentation. Les domaines clés d'intérêt sont :
* Les sections 'Pour les auteurs de modèles' couvrant la syntaxe de base.
* Les 'Considérations de sécurité' - il est probable que quiconque a développé l'application que vous testez n'a pas lu cela, et cela peut contenir des indices utiles.
* Les listes de méthodes, fonctions, filtres et variables intégrées.
* Les listes d'extensions/plugins - certaines peuvent être activées par défaut.
En supposant qu'aucune exploitation ne se soit présentée, la prochaine étape consiste à **explorer l'environnement** pour savoir exactement à quoi **vous avez accès**. Vous pouvez vous attendre à trouver à la fois des **objets par défaut** fournis par le moteur de modèle, et des **objets spécifiques à l'application** transmis au modèle par le développeur. De nombreux systèmes de modèles exposent un objet 'self' ou un espace de noms contenant tout ce qui est en portée, et une façon idiomatique de lister les attributs et méthodes d'un objet.
S'il n'y a pas d'objet self intégré, vous devrez 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 passe de Burp Intruder.
Les objets fournis par le développeur sont particulièrement susceptibles de contenir des informations sensibles, et peuvent varier entre différents modèles au sein d'une application, de sorte que ce processus devrait idéalement être appliqué à chaque modèle distinct individuellement.
À ce stade, vous devriez avoir une **idée ferme 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 trouver 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 modèle pour déclencher la création arbitraire d'objets, la lecture/écriture de fichiers arbitraires, l'inclusion de fichiers distants, la divulgation d'informations et l'escalade de privilèges.
Il est possible de récupérer les variables d'environnement du système en utilisant la classe `System` de Java. La méthode `getenv()` de cette classe permet de récupérer un objet `Map` contenant toutes les variables d'environnement du système.
Cette méthode peut être utilisée pour récupérer des informations sensibles telles que des clés d'API ou des informations d'identification stockées dans les variables d'environnement. Il est donc important de s'assurer que ces informations ne sont pas exposées ou accessibles à des tiers non autorisés.
Pour récupérer le contenu du fichier `/etc/passwd` sur un serveur distant, vous pouvez utiliser une injection de modèle côté serveur (SSTI) en Java. Tout d'abord, vous devez trouver un point d'injection SSTI dans l'application Web. Ensuite, vous pouvez utiliser la syntaxe de modèle Java pour exécuter du code arbitraire et récupérer le contenu du fichier `/etc/passwd`.
Vous pouvez insérer ce code dans un point d'injection SSTI dans l'application Web pour récupérer le contenu du fichier `/etc/passwd`. Notez que cette technique peut ne pas fonctionner sur toutes les applications Web, car certaines peuvent désactiver l'exécution de code Java arbitraire.
* 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 voulez 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 Thymeleaf spéciaux. S'il est nécessaire d'utiliser une expression à un autre endroit dans le modèle, Thymeleaf prend en charge l'_insertion d'expression_. Pour utiliser cette fonctionnalité, vous devez placer une expression entre `[[...]]` ou `[(...)]` (choisissez l'un ou l'autre en fonction de la nécessité d'échapper les symboles spéciaux). Par conséquent, une charge utile de détection SSTI simple pour Thymeleaf serait `[[${7*7}]]`.
Cependant, les chances que la charge utile de détection ci-dessus fonctionne sont très faibles. Les vulnérabilités SSTI se produisent généralement lorsqu'un modèle est généré dynamiquement dans le code. Thymeleaf, par défaut, n'autorise pas de 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 veut créer un modèle à partir d'une chaîne _à la volée_, il devra créer son propre résolveur de modèle. C'est possible mais cela arrive très rarement.
Si nous examinons de plus près la documentation du moteur de modèle Thymeleaf, nous trouverons une fonctionnalité intéressante appelée _**prétraitement d'expression**_. Les expressions placées entre deux tirets bas (`__...__`) 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 de Thymeleaf :
* [Payloads all the things](https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Server%20Side%20Template%20Injection/README.md#java---retrieve-etcpasswd)
Jinjava est un moteur de template Java qui permet l'injection de code côté serveur (SSTI). Il est utilisé par plusieurs frameworks Java tels que Jekyll et Pelican.
#### Comment l'exploiter
Pour exploiter une SSTI avec Jinjava, vous pouvez utiliser la syntaxe suivante :
```
{{ 7*'7' }}
```
Cela va évaluer l'expression `7*'7'` et afficher le résultat `49`.
Vous pouvez également accéder aux variables et aux fonctions de l'objet `context` en utilisant la syntaxe suivante :
//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 de l'application (beans gérés). EL est utilisé par **plusieurs technologies JavaEE**, telles que la technologie JavaServer Faces, la technologie JavaServer Pages (JSP) et l'injection de contextes et de dépendances pour Java EE (CDI).\
Consultez la page suivante pour en savoir plus sur l'**exploitation des interpréteurs EL** :
Cette méthode de contournement du gestionnaire de sécurité a été prise à partir de ce [**writeup**](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 pour mission de promouvoir les connaissances techniques, ce congrès est un point de rencontre bouillonnant 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)
Twig is a template engine for PHP that is used by many popular PHP frameworks, such as Symfony, Laravel, and Drupal. It is also used by some SaaS platforms, such as Shopify and CraftCMS.
Twig uses a syntax similar to Django templates and Jinja2 templates. It is a powerful and flexible template engine that allows developers to create complex templates with ease.
One of the most important things to keep in mind when using Twig is to properly sanitize any user input that is used in a template. Failure to do so can lead to server-side template injection vulnerabilities, which can allow an attacker to execute arbitrary code on the server.
Overall, Twig is a great choice for developers who want a powerful and flexible template engine that is easy to use and integrates well with popular PHP frameworks.
* Dans la section Twig et Twig (Sandboxed) de [https://portswigger.net/research/server-side-template-injection](https://portswigger.net/research/server-side-template-injection)
L'injection de modèle côté serveur (SSTI) est une vulnérabilité qui permet à un attaquant d'injecter du code dans un modèle côté serveur. Cette vulnérabilité peut être exploitée pour exécuter du code à distance, accéder à des données sensibles ou prendre le contrôle du serveur.
## Comment ça fonctionne
Les modèles sont utilisés pour générer des pages Web dynamiques. Les modèles peuvent contenir des variables qui sont remplacées par des valeurs spécifiques lorsqu'une page est générée. Les SSTI se produisent lorsque les variables du modèle sont mal gérées et qu'un attaquant peut injecter du code dans le modèle.
## Exploitation
Les SSTI peuvent être exploités de différentes manières, en fonction de la technologie utilisée pour générer les modèles. Les attaquants peuvent utiliser des balises spéciales pour injecter du code dans les modèles. Par exemple, dans les modèles Jinja2, les attaquants peuvent utiliser la balise `{{ }}` pour injecter du code.
Voici un exemple de code malveillant qui peut être injecté dans un modèle Jinja2:
```
{{config.items()[0]}}
```
Ce code malveillant peut être utilisé pour accéder à des données sensibles, telles que les informations d'identification de la base de données.
Pour prévenir les SSTI, il est important de valider toutes les entrées utilisateur qui sont utilisées pour générer des modèles. Les développeurs doivent s'assurer que les variables du modèle sont correctement échappées pour empêcher l'injection de code.
L'injection de modèle côté serveur (SSTI) est une vulnérabilité qui permet à un attaquant d'injecter du code dans un modèle côté serveur. Cette vulnérabilité peut être exploitée pour exécuter du code arbitraire sur le serveur.
## Comment cela fonctionne-t-il?
Les modèles sont utilisés pour générer des pages Web dynamiques. Les modèles peuvent contenir des variables qui sont remplacées par des valeurs lorsqu'une page est générée. Les SSTI se produisent lorsque les variables sont mal validées et qu'un attaquant peut injecter du code dans le modèle.
## Exploitation
Les SSTI peuvent être exploités de différentes manières, en fonction de la technologie utilisée pour générer les modèles. Les attaquants peuvent utiliser des balises spéciales pour injecter du code dans les modèles. Par exemple, dans les modèles Jinja2, les attaquants peuvent utiliser la balise `{{ }}` pour injecter du code.
Voici un exemple de code vulnérable en Python utilisant Jinja2:
Dans cet exemple, l'utilisateur fournit une valeur pour la variable `name`. Si l'utilisateur fournit une valeur malveillante, il peut injecter du code dans le modèle. Par exemple, si l'utilisateur fournit la valeur `{{2+2}}`, le modèle généré sera `Hello 4!`.
Pour prévenir les SSTI, il est important de valider toutes les entrées utilisateur. Les développeurs doivent s'assurer que les variables sont correctement validées avant d'être utilisées dans les modèles. Les frameworks de développement Web modernes, tels que Flask et Django, ont des mécanismes intégrés pour prévenir les SSTI. Les développeurs doivent également s'assurer que les modèles sont stockés en toute sécurité et que les utilisateurs n'ont pas accès aux fichiers de modèle.
La page `authors.php` affiche une liste d'auteurs avec leurs noms et leurs biographies. Elle est vulnérable à une injection de modèle côté serveur (SSTI) en raison d'une mauvaise validation des entrées utilisateur.
## Impact
Un attaquant peut exploiter cette vulnérabilité pour exécuter du code arbitraire sur le serveur, ce qui peut entraîner la divulgation de données sensibles, la prise de contrôle du serveur ou d'autres attaques.
## Exploitation
L'exploitation de cette vulnérabilité dépend du langage de modèle utilisé par l'application. Les exemples suivants montrent comment exploiter cette vulnérabilité en utilisant différents langages de modèle.
http://example.com/authors.php?name={{#with "s" as |string|}}{{#with "e"}}{{#with split as |conslist|}}{{this.pop}}${{this.pop}}(id){{/with}}{{/with}}{{/with}}
La meilleure façon de se protéger contre les attaques SSTI est de ne pas utiliser d'entrées utilisateur directement dans les modèles. Si cela n'est pas possible, il est important de valider et de filtrer soigneusement les entrées utilisateur pour s'assurer qu'elles ne contiennent pas de code malveillant.
Jade est un moteur de template pour Node.js qui permet de générer du HTML dynamique. Il est vulnérable aux attaques SSTI si les entrées utilisateur ne sont pas correctement validées et échappées.
Pour exploiter une vulnérabilité SSTI dans Jade, vous pouvez utiliser la syntaxe `#{}` pour exécuter du code arbitraire. Par exemple, si vous avez une variable `userInput` qui contient du code malveillant, vous pouvez l'injecter dans un template Jade comme ceci :
```
p Welcome #{userInput}
```
Si `userInput` contient du code qui peut être exécuté, il sera exécuté lors de la génération de la page.
Pour éviter les attaques SSTI dans Jade, vous devez toujours valider et échapper les entrées utilisateur avant de les utiliser dans un template.
* 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 qui ne compile pas et utilise des balises XML pour diviser un document en différentes parties.
> Jinja2 est un moteur de template complet pour Python. Il prend en charge l'unicode complet, un environnement d'exécution sandboxé intégré en option, est largement utilisé et sous licence BSD.
Jinja2 est un moteur de template pour Python. Il est utilisé pour générer des pages HTML, des courriels et d'autres types de documents. Les templates Jinja2 sont des fichiers texte qui contiennent des balises et des variables. Les balises sont utilisées pour contrôler la logique de la page, tandis que les variables sont utilisées pour afficher des données dynamiques.
Les balises Jinja2 sont entourées de `{%` et `%}`. Les variables sont entourées de `{{` et `}}`. Les commentaires sont entourés de `{#` et `#}`.
Dans cet exemple, `title` et `heading` sont des variables, tandis que `for` est une balise. La boucle `for` itère sur la liste `items` et affiche chaque élément dans un paragraphe.
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 shell web. 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 transmise en entrée au modèle
* Si les données transmises 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 de fin "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**, il est très facile de réaliser une XSS en fournissant simplement votre charge utile en entrée. Cependant, ce n'est pas le cas avec **html/template** car il encode la réponse en HTML : `{{"<script>alert(1)</script>"}}` --> `<script>alert(1)</script>`
La documentation pour les modules html/template et text/template peut être trouvée [ici](https://golang.org/pkg/html/template/) et [ici](https://golang.org/pkg/text/template/), et oui, ils 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 une RCE en go via SSTI, vous devriez savoir que comme vous pouvez accéder à l'objet donné au modèle avec `{{ . }}`, vous pouvez également **appeler les méthodes des objets**. Ainsi, imaginez que l'**objet transmis a une méthode appelée System** qui exécute la commande donnée, vous pourriez l'abuser avec : `{{ .System "ls" }}`\
Par conséquent, vous aurez probablement **besoin du code source**. Un code source potentiel pour quelque chose comme ça ressemblera à :
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 **pour mission de promouvoir les connaissances techniques**, ce congrès est un point de rencontre bouillonnant pour les professionnels de la technologie et de la cybersécurité dans toutes les disciplines.
* Travaillez-vous dans une **entreprise de cybersécurité** ? Voulez-vous voir votre **entreprise annoncée dans HackTricks** ? ou voulez-vous avoir accès à la **dernière version de PEASS ou télécharger HackTricks en PDF** ? Consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop)!
* Découvrez [**The PEASS Family**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFT**](https://opensea.io/collection/the-peass-family)
* Obtenez le [**swag officiel PEASS & HackTricks**](https://peass.creator-spring.com)
* **Rejoignez le** [**💬**](https://emojipedia.org/speech-balloon/) [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Partagez vos astuces de piratage en soumettant des PR au** [**repo hacktricks**](https://github.com/carlospolop/hacktricks) **et au** [**repo hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
