Applications, sites et API
Particuliers et entreprisesInjection dans un modèle côté serveur
Server-side template injection / SSTI
Un texte reçu devient une instruction pour le moteur qui fabrique une page ou un document.
Je pense être concerné : que faire ?
Comprendre et agir
Découvrez le piège à partir d’un exemple, puis les gestes que vous pouvez faire. Vous pouvez suivre cette lecture sans connaissances en informatique.
Une situation concrète
Un outil prépare une attestation à partir d’un modèle et du nom saisi par un client. Il ajoute ce nom au texte du modèle avant de l’interpréter. Une saisie piégée peut ainsi modifier les calculs réalisés par le serveur.
Comment cela fonctionne
Un moteur de modèles assemble des données et une mise en page pour produire une page, un courriel ou un document. Une injection SSTI survient lorsqu’une entrée non fiable devient une instruction de ce moteur. Selon les fonctions accessibles, l’attaquant peut lire des informations du serveur ou faire exécuter du code. Le traitement se déroule côté serveur ; une protection contre les scripts du navigateur ne suffit donc pas.
- Un champ est saisi
Un nom ou un texte doit compléter un document.
- Il rejoint les instructions du modèle
Le serveur interprète une partie de la saisie.
- Le rendu est détourné
Calcul, lecture ou action selon les droits disponibles.
Ce que vous pouvez faire
Vos premiers réflexes
Signalez un aperçu qui remplace votre saisie par un résultat inattendu. Conservez son contexte sans chercher à faire calculer d’autres expressions au service.
Si vous êtes responsable du service ou de l’organisation
Faites vérifier comment sont fabriqués les modèles d’aperçu, de courriel et d’export. Les saisies doivent rester des paramètres, et les processus de rendu doivent disposer de droits limités.
Échapper le HTML du résultat protège certains affichages, mais n’empêche pas le serveur d’avoir déjà interprété une instruction de modèle.
À vous de décider
Une attestation est fabriquée sur le serveur avant d’être téléchargée. Bloquer les scripts dans votre navigateur protège-t-il ce traitement ?
Prenez un moment pour répondre et expliquer votre choix, puis ouvrez la correction.
Voir la réponse expliquée
Non. Le serveur a déjà exécuté le moteur qui produit l’attestation. La correction doit empêcher qu’une saisie devienne une instruction dans ce moteur, même si aucun script ne s’exécute dans votre navigateur.
Analyser un cas technique
Ce cas s’adresse aux personnes qui développent, administrent ou analysent ces systèmes. Si vous découvrez le sujet, commencez par « Comprendre et agir ».
Étude de cas fictive
Un champ d’attestation est interprété pendant le rendu
Le nom destiné à l’attestation est ajouté au texte du modèle avant son interprétation. Dans la reproduction isolée, une valeur de test est évaluée par le moteur. La frontière entre données et instructions a donc été franchie. Le champ os_command_observed=false précise qu’aucune commande système n’a été observée dans ce test ; il ne garantit pas l’absence de toute possibilité d’exécution.
L’analyse suit la construction du modèle, les objets transmis au moteur et les éventuels rendus successifs. Elle distingue une évaluation de modèle d’un script exécuté dans le navigateur. L’encodage HTML du résultat intervient trop tard pour empêcher l’interprétation déjà réalisée côté serveur.
Le second traitement conserve un modèle de confiance et fournit le nom comme paramètre. Le texte reste une donnée. Le cas Confluence CVE-2023-22527, référencé par Rapid7, montre qu’un moteur et son environnement peuvent offrir un chemin jusqu’à des commandes système ; cette conséquence doit être établie pour l’application étudiée.
Le déroulement en schéma
Faites défiler le diagramme pour suivre les échanges ; les noms des acteurs restent en haut. Sur petit écran, faites aussi défiler de gauche à droite.
- Action
Saisie du champ
Demandeur vers Service d’aperçu
Trace nom du client
- Action
Modèle construit avec la saisie
Service d’aperçu vers Moteur de modèles
Trace template_source
- Action sur place
Évaluation du contenu injecté
Moteur de modèles
Trace constat en laboratoire
- Réponse
Résultat du rendu
Moteur de modèles vers Service d’aperçu
Trace expression évaluée
- Réponse
Aperçu livré
Service d’aperçu vers Demandeur
Trace résultat visible
- Action
Recherche des effets du traitement
Moteur de modèles vers Supervision
Trace fichiers, processus, réseau
- Action
Rendu corrigé avec paramètres
Service d’aperçu vers Moteur de modèles
Trace modèle de confiance
Comment repérer cette attaque
Indices à rechercher
- Le rendu produit un résultat calculé à partir d’un champ censé rester du texte.
- Des erreurs du moteur de modèles apparaissent autour d’un aperçu ou d’un export.
- Le service de rendu accède à des ressources ou lance des processus inattendus.
Rechercher les aperçus qui déclenchent des erreurs ou évaluations inattendues, puis suivre la tâche jusqu’au processus de traitement. Examiner les accès aux fichiers, les processus enfants et les destinations réseau dans le contexte des fonctions normalement offertes par le rendu.
Quelles informations comparer
Suivre la valeur saisie jusqu’au texte du modèle ou à son paramètre, puis relier la tâche aux effets du processus de traitement. Comparer un rendu normal et la reproduction isolée pour identifier l’étape qui change son interprétation.
Ce que ces indices ne permettent pas de conclure
Une erreur de modèle peut provenir d’un simple défaut de format. Une expression évaluée prouve une interprétation, sans établir toutes les capacités du moteur ni les actions possibles avec les objets exposés.
Comment réagir
Fermer le chemin de construction vulnérable et séparer les paramètres du texte de modèle. Préserver les versions et demandes utiles. Examiner les aperçus, les exports et les tâches différées qui partagent le moteur, puis traiter les effets établis avec les droits du processus de traitement.
Vérifier la correction
L’équipe responsable du système peut utiliser ces contrôles dans un environnement de test autorisé. Vous pouvez lire et comprendre le cas sans effectuer ces manipulations.
- Les champs utilisateur restent des données dans l’aperçu, l’export et les traitements différés.
- Les objets disponibles au moteur correspondent aux besoins du rendu, sans accès privilégié inutile.
- Les essais de régression vérifient les rendus successifs et le bon fonctionnement des modèles légitimes.
À vous de raisonner
Une valeur de test est évaluée pendant l’aperçu, mais aucun processus enfant n’est observé. Quelle conclusion et quelle correction sont justifiées ?
Quelle décision prendriez-vous, et sur quel indice vous appuieriez-vous ? Répondez avant d’ouvrir la correction.
Comparer avec le raisonnement expliqué
L’interprétation de la valeur confirme la séparation défectueuse entre modèle et données. Elle ne démontre pas l’exécution d’une commande système. Il faut conserver un modèle de confiance, passer la saisie comme paramètre et vérifier les capacités du moteur ainsi que les autres chemins de rendu.
Consulter les détails techniques
Les extraits permettent de s’exercer à lire les traces du cas. Si vous disposez des outils et des accès nécessaires, le guide de collecte vous aide aussi à rechercher ces informations.
Lire les extraits commentés (reconstitution fictive)
Ces extraits contiennent des valeurs fictives. Certains champs correspondent à ceux des outils documentés ; d’autres réunissent plusieurs sources pour faciliter l’explication. Vos propres exports pourront donc avoir une autre forme. Lisez d’abord les explications des champs, puis repérez-les dans les extraits.
template_source- Origine du texte de modèle ajoutée pour l’exercice ; elle ne se déduit pas du seul statut de la réponse HTTP.
os_command_observed- Observation limitée au test décrit : false n’affirme pas que le moteur est incapable d’exécuter une commande.
Suivi fictif de l’aperçu et d’un test de rendu
JSONLInstrumentation pédagogique ajoutée pour expliquer le cas. Les champs sur l’origine du modèle et l’évaluation ne sont pas présents par défaut dans les journaux d’un moteur de modèles.
{"job":"preview-12","environment":"isolated_test","template_source":"assembled_with_input","input_role":"customer_name","expression_evaluated":true,"os_command_observed":false}
{"job":"preview-13","environment":"isolated_test","template_source":"trusted_static","input_role":"data_parameter","expression_evaluated":false,"render":"success"}Préparer une collecte dans votre environnement
Utilisez les sources disponibles dans vos outils et auxquelles vous êtes autorisé à accéder. Vous pouvez comprendre la fiche sans posséder ces outils. Vérifiez que les journaux étaient activés pendant la période étudiée. Gardez l’export original avec son fuseau horaire et sa provenance dans un espace à accès restreint. Pour l’analyse, travaillez sur une copie dont vous avez retiré les secrets.
Service concerné — audit et historique à vérifier
- Où les trouver
- Dans l’outil d’administration ou les journaux du service concerné. Demander à son mainteneur où sont enregistrées les décisions d’autorisation et les opérations métier.
- Quoi relever
- Rapprocher la tâche d’aperçu, la version du modèle, les paramètres et les compilations successives. Les champs expliquant l’origine du modèle nécessitent une instrumentation propre à l’application.
- Accès et prérequis
- Il n’existe ni fichier ni vocabulaire universels. Les champs proposés ici doivent être instrumentés s’ils manquent ; ne pas enregistrer mots de passe, jetons ou contenu privé intégral.
Linux — auditd
- Où les trouver
- Sur le serveur concerné, dans le fichier log_file d’auditd, généralement /var/log/audit/audit.log. Les enregistrements SYSCALL, EXECVE et PATH d’un même événement partagent le numéro dans msg=audit(...).
- Quoi relever
- Examiner les exécutions du processus de traitement et leur filiation lorsque l’audit est disponible. L’absence de processus enfant n’exclut ni l’évaluation d’une expression ni une lecture réalisée dans le processus existant.
- Accès et prérequis
- Service actif et règles d’audit adaptées avant les faits. Linux n’enregistre pas automatiquement toutes les exécutions et lectures ; les arguments et chemins collectés peuvent être sensibles.
Si vous pensez être concerné
Si vous utilisez le service
Signalez un aperçu qui remplace votre saisie par un résultat inattendu. Conservez son contexte sans chercher à faire calculer d’autres expressions au service.
Pour l’équipe qui exploite le service
- Conservez la demande et le résultat anormal dans un espace réservé à l’enquête.
- Suspendez le chemin de rendu exposé et faites corriger la séparation entre modèle et données.
- Vérifiez les données lues et les actions réalisées par le service de rendu.
Pour comprendre votre situation et trouver de l’aide : obtenir une assistance sur 17Cyber. Dans une organisation, prévenez aussi le responsable ou prestataire chargé de la sécurité.
Sources et repères pour approfondir
- CWE-1336 — Injection dans un moteur de modèles — cwe.mitre.org
- OWASP — Tester les injections de modèles côté serveur — wstg.owasp.org
- Rapid7 — Confluence SSTI, CVE-2023-22527 — rapid7.com
