Lorsqu'ils travaillent avec Handlebars, les développeurs ignorent souvent qu'une mauvaise utilisation des modèles peut exposer à de graves failles d'injection. Bien que Handlebars JS échappe automatiquement à la sortie, des modèles non sécurisés, tels que des triples accolades ou des helpers Handlebars mal écrits, peuvent contourner les protections. Par conséquent, les attaquants peuvent injecter des charges utiles XSS, voler des données ou exécuter du code malveillant.
Ce guide vous montre comment appliquer une utilisation sécurisée du guidon, met en évidence des exemples dangereux par rapport à des exemples sécurisés et explique comment automatiser la validation des modèles dans pipelines avec des outils comme Xygeni.
Pourquoi les modèles de guidon peuvent être risqués
Par défaut, Handlebars JS échappe les valeurs pour bloquer l'injection directe. Cependant, de nombreux développeurs désactivent cette option sans en connaître les risques. Par exemple, l'utilisation de triples accolades affiche du code HTML brut :
<!-- Unsafe usage -->
<div>{{{userInput}}}</div>
If userInput is <script>alert('XSS')</script>, Le script s'exécute dans le navigateur. Par conséquent, un seul modèle non sécurisé peut compromettre l'application entière.
Ces erreurs fondamentales mettent en évidence le risque. Par conséquent, l'histoire a montré que l'utilisation abusive de Handlebars a conduit à des exploits majeurs dans la nature. Passons en revue quelques-uns des cas les plus marquants.
Exemples concrets de vulnérabilités du guidon
Bien que Guidon JS échappe aux valeurs par défaut, l'historique montre que les modèles non sécurisés ou faibles Aides au guidon ont causé de graves problèmes :
1. Pollution prototype dans les guidons (avis npm GHSA-2cf5-4w76-r9qv)
En 2021, un bug a été découvert dans le handlebars le paquet lui-même. La faille a permis pollution prototype, où les attaquants pourraient injecter des propriétés dans des objets globaux via des modèles conçus.
- Impact: La pollution des prototypes peut permettre aux attaquants d’exécuter du code, d’obtenir un accès plus élevé ou de voler des données.
- Exploit: Les attaquants ont envoyé des entrées malveillantes telles que
__proto__propriétés. Lorsque les modèles étaient rendus, ces objets pollués modifiaient le comportement de l'application. - Leçon: Même le moteur de modèles peut être risqué s'il n'est pas mis à jour. Il est donc essentiel d'analyser les dépendances et de maintenir les packages à jour.
2. XSS dans les assistants de guidon personnalisés d'Asana (2019)
En 2019, les chercheurs en sécurité ont découvert que Asana, un outil de gestion des tâches, exposait les utilisateurs à XSS à cause d'assistants personnalisés non sécurisés. Les développeurs ont écrit des assistants qui renvoyaient des chaînes brutes en utilisant SafeString, contournant l'échappement intégré du guidon.
- Impact: Les attaquants ont injecté du JavaScript malveillant dans des tâches ou des commentaires partagés.
- Exploit: Des charges utiles comme
<script>alert('XSS')</script>exécuté dans le navigateur de la victime lorsqu'elle a ouvert ces champs. - Leçon: Ne désactivez jamais l'échappement, sauf si vous n'avez pas d'autre choix. Vérifiez toujours les paramètres personnalisés. Aides au guidon avant de les déployer.
Types de vulnérabilités dans les guidons
Utilisation dangereuse de Guidon JS Les modèles peuvent exposer différentes classes de vulnérabilités. Les comprendre permet aux développeurs de savoir précisément quoi prévenir :
XSS (Cross-Site Scripting)
C'est l'erreur la plus courante. Elle survient lorsque les développeurs utilisent des accolades triples. {{{}}} ou des aides brutes qui désactivent l'échappement.
- Impact: Les attaquants peuvent injecter
<script>balises, HTML ou iframes qui s'exécutent dans le navigateur de l'utilisateur. - Exemple :
<!-- Unsafe -->
<div>{{{userInput}}}</div>
If
userInputcontient<script>alert('XSS')</script>, il s'exécute immédiatement.
Pollution prototype
Comme on le voit dans le npm advisory GHSA-2cf5-4w76-r9qv, une entrée malveillante peut modifier des objets globaux via des modèles conçus.
- Impact: Cela peut conduire à un comportement arbitraire, à une escalade des privilèges ou à une exfiltration de données.
- Leçon: Toujours garder
handlebarsmis à jour et exécuter des vérifications de dépendance dans CI/CD.
Injection de modèles côté serveur (SSTI)
Une SSTI se produit lorsqu'une entrée non fiable est transmise directement à un moteur de modèles exécuté sur le serveur. Guidon JS, si les développeurs compilent des modèles à l'aide d'entrées utilisateur brutes, un attaquant peut exécuter des charges utiles au niveau du serveur.
// Insecure Handlebars usage (server-side)
const template = Handlebars.compile(req.query.view);
res.send(template({}));
{{#with "require('fs').readdirSync('.')"}}
le moteur peut essayer de l'évaluer, exposant ainsi les fichiers côté serveur.
- Impact: Contrairement à XSS, qui affecte uniquement le navigateur, SSTI peut fournir un accès direct à l'environnement du serveur.
- La prévention: Ne compilez jamais de modèles provenant de sources non fiables. Utilisez plutôt des modèles prédéfinis et nettoyez les entrées avant le rendu.
Des risques similaires existent dans d'autres écosystèmes. Consultez par exemple notre guide sur Injection de dépendances Python pour apprendre des pratiques sécuritaires dans un contexte différent.
Abus de logique chez les assistants
Encadrement Sur Mesure Aides au guidon peuvent être dangereux s'ils autorisent des chaînes brutes ou fonctionnent avec des entrées non validées.
- Impact: Les attaquants peuvent contourner l'échappement ou tromper les assistants en exposant des données sensibles.
- Exemple :
Handlebars.registerHelper('raw', input => new Handlebars.SafeString(input));
Cet assistant désactive complètement l'échappement et doit être évité.
Fuite de données
Parfois, des assistants ou des modèles mal configurés révèlent des informations sensibles.
- Impact: Les jetons, les valeurs de configuration ou les informations d'identification de la base de données peuvent être rendus dans une sortie HTML.
- Leçon: Ne dévoilez jamais les secrets des modèles ; validez et analysez les fuites accidentelles dans vos référentiels.
Ensemble, ces catégories illustrent l'étendue des risques auxquels sont confrontés les développeurs. Par conséquent, même les plus petites erreurs dans Handlebars JS peuvent engendrer des problèmes dans la chaîne d'approvisionnement si elles ne sont pas corrigées.
Pourquoi cela est important pour les développeurs
Ces vulnérabilités prouvent que l'utilisation dangereuse n'est pas théorique, elle a été exploitée sur des plateformes réelles comme Asana et paquets npmDe plus, avec Handlebars JS largement utilisé dans Node.js et les projets frontend, les aides non sécurisées ou les dépendances obsolètes deviennent rapidement un risque pour la chaîne d'approvisionnement logicielle.
Vous souhaitez bloquer ces risques automatiquement ? Commencez un essai gratuit de Xygeni et ajouter guardrails dans votre pipeline dès aujourd’hui.
Meilleures pratiques pour une utilisation sûre du guidon
Pour éviter les failles d’injection, suivez ces pratiques de codage sécurisées :
1. Utilisez toujours des doubles accolades
<!-- Safe -->
<div>{{userInput}}</div>
Cela garantit que le moteur de modèle échappe au HTML avant le rendu.
2. Valider et assainir les entrées
De plus, validez les entrées avant de les transmettre aux modèles. Des bibliothèques comme validateur.js
3. Limitez les aides dangereuses
Mal conçu Aides au guidon provoquent souvent des vulnérabilités :
// Dangerous helper
Handlebars.registerHelper('raw', function (input) {
return new Handlebars.SafeString(input);
});
Cela permet d'éviter complètement l'échappement. Cependant, les assistants sécurisés doivent être limités à des opérations simples comme le formatage de dates ou la suppression de texte.
4. Utiliser la politique de sécurité du contenu (CSP)
De plus, appliquez des en-têtes CSP solides pour réduire le rayon d'explosion de toute injection.
Ces bonnes pratiques sont importantes pendant le développement. De plus, vous pouvez ajouter des contrôles automatisés pour éviter que du code non sécurisé ne soit mis en production.
Automatisation de la validation dans CI/CD Pipelines
Les vérifications manuelles ne suffisent pas. Pour clarifier les choses, des modèles de guidons non sécurisés peuvent s'infiltrer en production si des contrôles automatisés ne sont pas mis en place :
- SAST : Drapeau
{{{in.hbsfichiers. - Scanners de secrets:Détecter les informations d'identification intégrées dans les modèles.
- CI/CD guardrails: Interrompre les builds lorsqu'ils ne sont pas sécurisés Aides au guidon ou des accolades triples apparaissent.
Par exemple, vous pouvez appliquer une barrière de sécurité dans pipelines:
# Example Guardrail Rule
if: contains('{{{')
then: fail_build("Unsafe Handlebars triple braces detected")
Ces contrôles réduisent le risque de modèles non sécurisés, mais l'automatisation À grande échelle, une plateforme est nécessaire. C'est là que Xygeni ajoute une protection supplémentaire.
Vous pouvez également voir comment sécuriser pipelines dans Bitbucket fonctionne dans notre FAQ sur la sécurité de Bitbucket.
Comment Xygeni contribue à prévenir l'utilisation dangereuse du guidon
Écrire du code sûr est important, mais la véritable protection vient de l’automatisation. Xygéni fait Guidon JS plus sûr en ajoutant des contrôles à votre flux de travail :
- SAST pour les modèles: Scans
.hbsfichiers à intercepter dangereux{{{ou des assistants personnalisés risqués. - Guardrails: Définissez des règles simples dans GitHub, GitLab ou Bitbucket. Si du code JS Handlebars non sécurisé est détecté, la compilation s'arrête.
- Correction automatique: Suggère des correctifs sécurisés dans pull requests, en remplaçant les triples accolades par des doubles accolades sûres ou des appels d'aide de confiance.
- Secrets et vérifications de configuration : Recherche les jetons ou les informations d'identification cachés dans les modèles avant qu'ils ne fuient.
- CI/CD Sécurité: Bloque les extraits non sécurisés lors de la fusion, de sorte que seul le code sûr atteint la production.
Avec Xygeni, en toute sécurité Guidon JS L'utilisation n'est plus seulement une ligne directrice. Elle fait partie intégrante de votre système automatisé. pipeline.
Rassemblement
Le guidon est généralement sûr dès sa sortie d'usine, mais une mauvaise utilisation peut néanmoins ouvrir la voie à des attaques par injection. Le respect des bonnes pratiques, la validation des entrées et l'utilisation d'assistants sécurisés contribuent à réduire les risques. Cependant, le véritable avantage réside dans l'automatisation de ces contrôles. pipelines.
En conclusion, combiner de bonnes habitudes de codage avec des outils comme Xygeni permet d’éviter les failles d’injection et de sécuriser les modèles, sans ralentir la livraison.
