Règles Semgrep pour JavaScript et TypeScript¶

rules_lgpl_javascript_eval_rule-grpc-insecure-connection¶

Résumé :

Désérialisation de données non fiables

Gravité : Critique

Description :

L'application utilise grpc.credentials.createInsecure() pour établir une connexion gRPC non cryptée, transmettant toutes les données en texte clair sans protection TLS/SSL. Cela permet aux attaquants sur le réseau d'intercepter et de lire des données sensibles transmises entre le client et le serveur gRPC, y compris les identifiants d'authentification, les clés API, les informations personnelles et les données commerciales. De plus, les attaquants peuvent effectuer des attaques de type "homme du milieu" pour modifier les messages gRPC en transit, injectant potentiellement des charges utiles malveillantes ou altérant le comportement de l'application. Les connexions gRPC non sécurisées sont particulièrement dangereuses dans les environnements de production et les architectures de microservices où les services communiquent sur des réseaux non fiables.

Remédiation :

Remplacez grpc.credentials.createInsecure() par grpc.credentials.createSsl() pour activer le cryptage TLS pour toutes les connexions gRPC. Pour les environnements de production, utilisez des certificats TLS appropriés d'une Autorité de Certification (CA) de confiance et configurez la validation des certificats pour prévenir les attaques de type "homme du milieu". Vous pouvez créer des identifiants sécurisés avec grpc.credentials.createSsl(rootCerts, privateKey, certChain) où rootCerts valide l'identité du serveur. Pour les environnements de développement et de test, utilisez des certificats auto-signés mais ne les déployez jamais en production. Envisagez de mettre en œuvre une authentification mutuelle TLS (mTLS) en utilisant grpc.credentials.createSsl() avec les certificats du client et du serveur pour une sécurité accrue dans les architectures de microservices. Assurez-vous toujours que les connexions gRPC utilisent TLS 1.2 ou supérieur et désactivez les suites de chiffrement non sécurisées.

OWASP :

A8:2017-Désérialisation non sécurisée
A08:2021-Échecs d'intégrité des logiciels et des données

rules_lgpl_javascript_eval_rule-node-deserialize¶

Résumé :

Désérialisation de données non fiables

Sévérité : Critique

CWE : CWE-502

Description :

L'application utilise la fonction unserialize() de la bibliothèque node-serialize pour désérialiser des données, ce qui est vulnérable aux attaques par exécution de code à distance. Le paquet node-serialize utilise eval() de JavaScript en interne lors de la désérialisation, permettant aux attaquants d'injecter du code malveillant à travers des objets sérialisés soigneusement conçus contenant des Expressions de Fonction Imédiatement Invocables (IIFE). Lorsque des données non fiables sont désérialisées, les attaquants peuvent exécuter du code JavaScript arbitraire sur le serveur Node.js, entraînant un compromis complet du système. Cette vulnérabilité est particulièrement sévère car elle ne nécessite aucune condition particulière - toute désérialisation de données contrôlées par un attaquant exécutera le code intégré.

Remédiation :

Retirez immédiatement le paquet node-serialize de votre application car il est intrinsèquement peu sûr et n'a pas de mode d'utilisation sécurisé. Remplacez-le par JSON.parse() pour désérialiser des données JSON, qui est sûr et ne peut pas exécuter de code arbitraire. Si vous devez sérialiser des objets JavaScript complexes, y compris des fonctions ou des références circulaires, envisagez d'utiliser des formats de données structurés comme JSON avec un schéma prédéfini. Pour les données de session ou les objets mis en cache, utilisez des bibliothèques de sérialisation sécurisées comme serialize-javascript (note : différente de node-serialize) qui échappent correctement le code, ou mieux encore, ne stockez que des types de données primitifs et reconstruisez des objets complexes après désérialisation. Ne désérialisez jamais de données provenant de sources non fiables sans validation stricte et vérification de type. Mettez en œuvre un contrôle d'intégrité en utilisant des signatures HMAC pour détecter la falsification des données sérialisées avant la désérialisation.

OWASP :

A8:2017-Désérialisation Insecure
A08:2021-Échecs d'Intégrité Logicielle et des Données

rules_lgpl_javascript_eval_rule-serializetojs-deserialize¶

Résumé :

Désérialisation de données non fiables

Sévérité : Critique

CWE : CWE-502

Description :

L'application utilise la fonction deserialize() de la bibliothèque serialize-to-js, qui peut exécuter du code arbitraire lors de la désérialisation. Le package serialize-to-js sérialise les objets JavaScript, y compris les fonctions, et peut les reconstruire lors de la désérialisation, mais cette fonctionnalité permet aux attaquants d'injecter du code malveillant via des données sérialisées spécialement conçues. Lorsque des entrées non fiables sont désérialisées, des fonctions ou des expressions de code intégrées sont exécutées dans le contexte du serveur Node.js, permettant l'exécution de code à distance. Cela est particulièrement dangereux, car la bibliothèque est conçue pour préserver le code exécutable à travers les frontières de sérialisation, la rendant inadaptée à la gestion de données provenant de sources non fiables.

Remédiation :

N'utilisez jamais serialize-to-js pour désérialiser des données provenant de sources non fiables. Remplacez-le par JSON.parse() pour une désérialisation sécurisée qui ne peut pas exécuter de code. Si vous utilisez actuellement serialize-to-js pour sérialiser des fonctions ou des objets complexes, redessinez votre architecture pour utiliser des structures de données simples pouvant être sérialisées en toute sécurité en JSON. Pour l'état de l'application qui inclut un comportement, séparez les données (sérialisées en JSON) du code (stocké sous forme de logique d'application statique). Si vous devez absolument sérialiser du code exécutable pour une utilisation interne de confiance uniquement, assurez-vous de l'intégrité des données en utilisant des signatures HMAC cryptographiques et ne désérialisez jamais des données qui n'ont pas été vérifiées. Considérez que même avec des signatures, si un attaquant compromet votre clé de signature, il peut exécuter du code arbitraire. L'approche la plus sûre est d'éliminer complètement la sérialisation de code de l'architecture de votre application.

OWASP :

A8:2017-Désérialisation non sécurisée
A08:2021-Failles d'intégrité des logiciels et des données

rules_lgpl_javascript_eval_rule-yaml-deserialize¶

Résumé :

Désérialisation de données non fiables

Sévérité : Critique

CWE : CWE-502

Description :

L'application utilise la fonction load() de la bibliothèque js-yaml pour analyser les données YAML, ce qui peut exécuter du code JavaScript arbitraire lors de la désérialisation. Par défaut, la méthode load() de js-yaml prend en charge les balises YAML personnalisées qui peuvent instancier des objets JavaScript et exécuter des fonctions, permettant aux attaquants de créer des charges utiles YAML malveillantes qui exécutent du code arbitraire sur le serveur Node.js. Lorsque des données YAML non fiables sont analysées en utilisant load(), les attaquants peuvent atteindre l'exécution de code à distance en exploitant la capacité de YAML à représenter des constructions exécutables. Il s'agit d'une vulnérabilité critique particulièrement dangereuse lors de l'analyse de fichiers de configuration YAML, de requêtes API ou de tout contenu YAML fourni par l'utilisateur.

Remédiation :

Remplacez toutes les utilisations de yaml.load() par yaml.safeLoad() (js-yaml v3) ou yaml.load(data, {schema: yaml.SAFE_SCHEMA}) (js-yaml v4+) lors de l'analyse de données YAML. La fonction safeLoad() ou l'option SAFE_SCHEMA restreint l'analyse YAML aux types de données de base et empêche l'exécution de code arbitraire via des balises personnalisées. N'utilisez jamais yaml.load() sans le schéma sécurisé, même pour des données que vous considérez comme fiables, car il est facile pour des données non fiables d'entrer dans votre flux d'analyse. Pour les fichiers de configuration, envisagez de passer au format JSON qui n'a aucune capacité d'exécution de code et peut être analysé en toute sécurité avec JSON.parse(). Si vous devez prendre en charge des fonctionnalités avancées de YAML, vérifiez attentivement quelles balises personnalisées sont nécessaires et créez un schéma personnalisé minimal qui n'autorise que ces balises spécifiques sûres, jamais le schéma par défaut complet qui permet l'exécution de code.

OWASP :

A8:2017-Désérialisation Insecure
A08:2021-Failles d'Intégrité Logicielle et de Données

javascript_eval_rule-eval-avec-expression¶

Résumé :

Neutralisation incorrecte des directives dans le code évalué dynamiquement ('Injection d'Eval')

Sévérité : Élevée

CWE : CWE-95

Description :

L'application utilise des fonctions d'exécution de code dangereuses, notamment eval(), le constructeur Function(), ou des appels basés sur des chaînes de caractères à setTimeout()/setInterval() avec des entrées contrôlées par l'utilisateur. Ces fonctions JavaScript exécutent du code arbitraire au moment de l'exécution, ce qui permet aux attaquants d'injecter du JavaScript malveillant s'exécutant avec les privilèges de l'application. Dans les applications Node.js, cela peut entraîner un compromis complet du serveur et une exécution de code à distance. Dans les applications de navigateur, cela crée des vulnérabilités de type Cross-Site Scripting (XSS) qui permettent aux attaquants de voler des informations d'identification, d'effectuer des actions non autorisées ou de compromettre les sessions utilisateur.

Remédiation :

Supprimez toutes les utilisations de eval(), du constructeur Function() et des fonctions de minuterie basées sur des chaînes, remplacez-les par des alternatives plus sûres. Pour l'accès dynamique aux propriétés, utilisez la notation par crochets (par exemple, obj[userInput]) combinée avec une liste blanche pour valider les noms de propriété contre un ensemble prédéfini de valeurs sûres. Pour analyser les données JSON, utilisez JSON.parse() au lieu de eval(). Pour setTimeout() et setInterval(), passez toujours des références de fonction plutôt que des chaînes. Envisagez de mettre en œuvre des en-têtes de Politique de Sécurité de Contenu (CSP) avec script-src 'self' pour empêcher l'exécution de scripts en ligne et fournir une protection en profondeur. Si l'exécution de code dynamique est absolument nécessaire, isolez-la dans un environnement isolé avec des capacités restreintes et validez soigneusement toutes les entrées contre une liste blanche stricte. Pour plus d'informations, consultez https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/eval#never_use_eval!

OWASP :

A1:2017-Injection
A03:2021-Injection

javascript-rule-xss-angular¶

Résumé :

Utilisation de la méthode bypassSecurityTrust* dans Angular ('Cross-site Scripting')

Gravité : Moyenne

CWE : CWE-79

Description :

L'application utilise la famille de méthodes bypassSecurityTrust*() d'Angular qui désactive explicitement les mécanismes de protection intégrés en matière de types de confiance et de XSS d'Angular. Ces méthodes incluent bypassSecurityTrustHtml(), bypassSecurityTrustScript(), bypassSecurityTrustStyle(), bypassSecurityTrustUrl(), et bypassSecurityTrustResourceUrl(). Lorsque des données contrôlées par l'utilisateur passent par ces méthodes, elles contournent le DomSanitizer d'Angular et peuvent entraîner des vulnérabilités XSS (Cross-Site Scripting). Les attaques XSS permettent aux attaquants d'exécuter du JavaScript arbitraire dans le navigateur de la victime, potentiellement pour voler des jetons de session, effectuer des actions non autorisées ou défigurer l'application.

Remédiation :

Envisagez de supprimer complètement l'utilisation des méthodes bypassSecurityTrust*() et de vous fier à la sanitisation automatique d'Angular qui applique une échappement contextuel aux liaisons de templates. Si le rendu HTML dynamique est absolument nécessaire, nettoyez les entrées utilisateur en utilisant DOMPurify avant de les transmettre à la liaison [innerHTML] d'Angular, ou mieux encore, refactorisez le code pour utiliser la composition de composants d'Angular et la syntaxe de template sécurisée. Pour les cas où vous devez rendre du HTML de confiance à partir d'une source connue et sûre (comme du contenu CMS statique), assurez-vous que la source de données elle-même est sécurisée et envisagez de mettre en œuvre des en-têtes Content Security Policy (CSP) avec strict-dynamic pour limiter l'impact des XSS potentiels. Validez toujours que les données transmises aux méthodes bypass proviennent de sources contrôlées et de confiance, et jamais directement d'entrées utilisateur ou de paramètres d'URL.

OWASP :

A7:2017-Cross-Site Scripting (XSS)
A03:2021-Injection

règle-javascript-xss-react¶

Résumé :

Neutralisation inappropriée des entrées lors de la génération de pages web ('Cross-site Scripting')

Sévérité : Moyenne

CWE : CWE-79

Description :

L'application utilise la propriété dangerouslySetInnerHTML de React, qui contourne la protection XSS intégrée de React et la désinfection du DOM. Par défaut, React échappe automatiquement toutes les valeurs dans les expressions JSX avant de les rendre, empêchant ainsi l'injection de scripts. Cependant, dangerouslySetInnerHTML désactive explicitement cette protection et rend le code HTML brut directement dans le DOM. Si des données contrôlées par l'utilisateur passent dans la propriété __html de dangerouslySetInnerHTML, des attaquants peuvent injecter du JavaScript arbitraire qui s'exécute dans le contexte du navigateur de la victime, ce qui peut mener au détournement de session, au vol d'identifiants ou à des actions non autorisées. Cette vulnérabilité affecte à la fois le XSS basé sur le DOM (où des données non fiables proviennent de sources côté client comme les paramètres d'URL) et le XSS stocké/réfléchi (où du contenu malveillant est persistant ou renvoyé par le serveur).

Remédiation :

Envisagez de refactoriser le composant pour éviter complètement dangerouslySetInnerHTML en utilisant la syntaxe JSX standard de React qui échappe automatiquement le contenu. Si vous devez rendre du HTML provenant d'une source de confiance (comme un parseur Markdown ou un éditeur de texte enrichi), désinfectez-le d'abord en utilisant DOMPurify avec une configuration stricte qui supprime les gestionnaires d'événements et les balises de script : DOMPurify.sanitize(html, { ALLOWED_TAGS: ['p', 'b', 'i', 'em', 'strong'] }). Pour du contenu Markdown, envisagez d'utiliser react-markdown qui rend du Markdown de manière sécurisée sans innerHTML. De plus, implémentez des en-têtes de Politique de Sécurité de Contenu (CSP) avec script-src 'self' pour fournir une défense en profondeur contre le XSS, même si la désinfection est contournée. Ne passez jamais les entrées des utilisateurs, les paramètres d'URL ou les données provenant d'API externes directement à dangerouslySetInnerHTML sans une validation et une désinfection rigoureuses côté serveur.

OWASP :

A7:2017-Cross-Site Scripting (XSS)
A03:2021-Injection

règle-javascript-xss-svelte¶

Résumé :

Utilisation de {@html * } dans Svelte ('Cross-site Scripting')

Sévérité : Moyenne

CWE : CWE-79

Description :

L'application utilise la directive {@html ...} de Svelte qui rend du contenu HTML brut directement dans le DOM sans aucune sanitisation ou encodage. Par défaut, Svelte échappe automatiquement les valeurs dans les liaisons standard comme {variable} pour prévenir les attaques XSS. Cependant, la directive {@html} contourne explicitement cette protection et traite le contenu comme un balisage HTML de confiance. Si des données contrôlées par l'utilisateur sont introduites dans une expression {@html}, des attaquants peuvent injecter des scripts malveillants qui s'exécutent dans le navigateur de la victime, pouvant potentiellement voler des jetons d'authentification, effectuer des actions non autorisées ou exfiltrer des données sensibles. Cela est particulièrement dangereux dans les applications Svelte car la nature réactive du framework peut rendre facile une liaison accidentelle entre une entrée utilisateur et des expressions {@html}.

Remédiation :

Envisagez d'utiliser la syntaxe de liaison texte standard de Svelte {variable} au lieu de {@html}, qui échappe automatiquement les entités HTML et prévient l'injection de scripts. Si vous devez rendre du contenu HTML enrichi d'une source de confiance (comme du markdown converti en HTML), sanitez-le d'abord en utilisant DOMPurify : {@html DOMPurify.sanitize(content)} avec une configuration restrictive qui élimine les gestionnaires d'événements et les balises script. Pour le rendu de markdown, envisagez d'utiliser un composant markdown Svelte qui convertit en toute sécurité le markdown en nœuds DOM sans innerHTML. De plus, implémentez des en-têtes de Politique de Sécurité de Contenu (CSP) pour fournir une défense en profondeur. Ne jamais utiliser {@html} avec des données provenant de paramètres d'URL, d'entrées de formulaires, de localStorage ou de toute API externe sans une validation rigoureuse côté serveur et une sanitisation côté client.

OWASP :

A7:2017-Cross-Site Scripting (XSS)
A03:2021-Injection

javascript-rule-xss-vuejs¶

Résumé :

Utilisation de v-html dans Vue js ('Cross-site Scripting')

Gravité : Moyenne

CWE : CWE-79

Description :

L'application utilise la directive v-html de Vue qui rend du contenu HTML brut directement dans le DOM sans sanitation, ou a désactivé la règle ESLint vue/no-v-html qui avertit de cette pratique dangereuse. La syntaxe standard d'interpolation de Vue {{ variable }} échappe automatiquement les entités HTML pour prévenir les XSS, mais v-html contourne explicitement cette protection. Lorsque des données contrôlées par l'utilisateur transitent par v-html, les attaquants peuvent injecter du JavaScript malveillant qui s'exécute dans le contexte du navigateur de la victime, potentiellement volants des cookies de session, accédant à local storage ou effectuant des appels API non autorisés. Désactiver la règle ESLint vue/no-v-html augmente encore le risque en supprimant les avertissements d'analyse statique qui alertent les développeurs sur les potentielles vulnérabilités XSS durant le développement.

Remédiation :

Envisagez d'utiliser la syntaxe standard des accolades de Vue {{ variable }} au lieu de v-html, qui échappe automatiquement HTML et prévient l'injection de scripts. Si le rendu de HTML riche est absolument nécessaire (comme le contenu généré par un utilisateur à partir d'un éditeur WYSIWYG), nettoyez-le d'abord en utilisant DOMPurify avec des paramètres stricts : v-html="$sanitize(content)" où $sanitize est une méthode globale englobant DOMPurify. Réactivez la règle ESLint vue/no-v-html dans votre configuration pour intercepter les usages non sécurisés lors de la révision de code. Pour le contenu markdown, utilisez un composant markdown Vue qui rend les nœuds DOM en toute sécurité. Mettez en œuvre des en-têtes de politique de sécurité de contenu (CSP) avec script-src 'self' pour limiter l'impact des XSS. N'utilisez jamais v-html avec des paramètres d'URL, des paramètres de route, l'état Vuex rempli à partir d'entrées utilisateur, ou des données provenant d'API externes sans validation côté serveur et sanitation robuste côté client.

OWASP :

A7:2017-Cross-Site Scripting (XSS)
A03:2021-Injection

javascript_buf_rule-detect-new-buffer¶

Résumé :

Allocation de ressources sans limites ni régulation

Sévérité : Moyenne

CWE : CWE-770

Description :

L'application utilise le constructeur new Buffer() qui a été déprécié depuis Node.js 8. En passant une valeur non littérale à ce constructeur, un adversaire pourrait allouer de grandes quantités de mémoire, entraînant une interruption de service. De plus, les versions antérieures de Node.js retournent de la mémoire non initialisée lors de l'utilisation de new Buffer(size), ce qui pourrait divulguer des informations sensibles telles que des mots de passe, des jetons ou des clés de cryptage qui occupaient précédemment cette région mémoire. Le constructeur new Buffer() est également ambigu car son comportement varie en fonction du type d'argument, ce qui rend difficile la détermination des données qu'un Buffer contient lorsqu'une valeur non littérale est transmise.

Remédiation :

Envisagez de migrer vers Buffer.alloc() pour créer des buffers remplis de zéros ou Buffer.from() pour créer des buffers à partir de données existantes. Utilisez Buffer.alloc(size) lorsque vous avez besoin d'un buffer d'une taille spécifique rempli de zéros, ce qui est sécurisé et empêche les fuites d'informations. Utilisez Buffer.from(array) ou Buffer.from(string) lors de la conversion de données existantes en Buffer. Pour les applications qui doivent prendre en charge des versions plus anciennes de Node.js, envisagez d'utiliser le paquet safe-buffer qui fournit un polyfill pour les méthodes Buffer sécurisées. Notez que Buffer.allocUnsafe() doit être évité sauf si vous avez des exigences de performance spécifiques et que vous écrivez immédiatement sur tout le contenu du buffer, car cela retourne de la mémoire non initialisée. Des conseils détaillés sur la migration sont disponibles sur https://nodejs.org/en/docs/guides/buffer-constructor-deprecation

OWASP :

A9:2017-Utiliser des composants avec des vulnérabilités connues
A06:2021-Composants vulnérables et périmés

javascript_dos_rule-non-literal-regexp¶

Résumé :

Expression régulière avec une valeur non littérale

Sévérité : Moyenne

CWE : CWE-185

Description :

Le constructeur RegExp() ou new RegExp() est appelé avec une valeur non littérale, ou les méthodes de chaîne comme match() et search() sont invoquées avec des motifs non littéraux. Lorsque des adversaires peuvent fournir des expressions régulières malveillantes contenant des motifs de remboursement catastrophiques, ils peuvent provoquer des attaques de déni de service par expression régulière (ReDoS) rendant l'application non réactive. Dans les applications Node.js, cela bloque la boucle d'événements et empêche l'ensemble de l'application de répondre aux requêtes d'autres utilisateurs, mettant effectivement le service hors service.

Remédiation :

Il est recommandé d'utiliser toujours des expressions régulières littérales codées en dur (par exemple, /pattern/flags) au lieu d'accepter des motifs regex fournis par l'utilisateur. Si un appariement de motifs dynamique est absolument nécessaire, envisagez de migrer vers le package node-re2 (npm install re2), qui implémente le moteur RE2 de Google ne supportant pas le remboursement et offrant des garanties de temps linéaire. Lors de l'utilisation de RE2, créez des instances avec new RE2(pattern) au lieu de new RegExp(pattern). Notez que RE2 ne prend pas en charge toutes les fonctionnalités regex de JavaScript comme les lookaheads et les références arrière, donc testez la compatibilité avec soin. Pour les cas d'utilisation de recherche/appariement, envisagez d'utiliser des opérations simples sur les chaînes comme indexOf(), includes(), ou startsWith() lorsque la complexité de l'appariement des motifs n'est pas requise. Vous pouvez également mettre en œuvre une validation stricte sur l'entrée utilisateur pour rejeter les motifs contenant des constructeurs dangereux, bien que cela soit complexe et sujet à erreurs par rapport à l'utilisation de RE2.

OWASP :

A1:2017-Injection
A03:2021-Injection

javascript_pathtraversal_rule-non-literal-fs-filename¶

Résumé :

Limitation incorrecte d'un chemin d'accès à un répertoire restreint ('Path Traversal')

Gravité : Moyenne

CWE : CWE-22

Description :

Des chemins de fichiers non littéraux sont utilisés avec les fonctions du module fs de Node.js telles que readFile(), writeFile(), readdir(), ou des opérations similaires. Si ces chemins sont construits à partir d'entrées utilisateur, les attaquants peuvent utiliser des séquences de traversée de chemin comme ../ pour échapper aux répertoires prévus et accéder à des fichiers arbitraires sur le système. Cela peut entraîner une divulgation, une modification ou une suppression non autorisée de fichiers.

Remédiation :

Envisagez d'utiliser path.join() pour construire des chemins de fichiers avec un répertoire de base fixe, puis validez que path.normalize(fullPath) commence toujours par le répertoire de base en utilisant fullPath.startsWith(basePath). Il est recommandé d'éviter d'utiliser directement les entrées utilisateur comme noms de fichiers ; utilisez plutôt des identifiants générés aléatoirement comme crypto.randomUUID() et mappez-les à des noms fournis par l'utilisateur dans une base de données. Résolvez et normalisez toujours les chemins avant les opérations sur les fichiers.

OWASP :

A5:2017-Contrôle d'accès brisé
A01:2021-Contrôle d'accès brisé

javascript_random_rule-pseudo-random-bytes¶

Résumé :

Utilisation d'un générateur de nombres pseudo-aléatoires (PRNG) cryptographiquement faible

Gravité : Moyenne

CWE : CWE-338

Description :

La fonction obsolète crypto.pseudoRandomBytes() est utilisée, ce qui génère des données aléatoires cryptographiquement faibles. Cette fonction utilise un PRNG non cryptographique qui peut être prévisible et qui est inadapté aux opérations sensibles à la sécurité comme la génération de jetons, d'identifiants de session, de nonces ou de clés cryptographiques. Des valeurs aléatoires prévisibles peuvent entraîner le détournement de session, la contrefaçon de jetons ou des échecs cryptographiques.

Remédiation :

Envisagez de remplacer crypto.pseudoRandomBytes() par crypto.randomBytes(), qui fournit des données aléatoires cryptographiquement solides adaptées aux opérations de sécurité. Il est recommandé d'utiliser crypto.randomBytes(size) pour générer des jetons, des identifiants de session, des nonces ou toute clé cryptographique. La fonction randomBytes() utilise le PRNG cryptographique du système et est la norme pour toute génération de nombres aléatoires sensibles à la sécurité dans Node.js.

OWASP :

A3:2017-Exposition de données sensibles
A02:2021-Échecs cryptographiques

javascript_xss_rule-mustache-escape¶

Résumé :

Neutralisation inadéquate des entrées lors de la génération de pages web (XSS)

Sévérité : Moyenne

CWE : CWE-79

Description :

L'application désactive l'échappement HTML de Mustache en remplaçant soit la fonction mustache.escape pour retourner un texte non échappé, soit en utilisant la syntaxe triple moustache {{{variable}}} ou la syntaxe ampersand {{&variable}} qui génèrent du HTML brut sans échappement. La syntaxe par défaut de Mustache avec double accolade {{variable}} échappe automatiquement les entités HTML comme <, >, et & pour prévenir le Cross-Site Scripting (XSS). En remplaçant la fonction d'échappement par return text; ou en utilisant une syntaxe d'interpolation non échappée, l'application supprime cette protection de sécurité essentielle. Lorsque des données contrôlées par l'utilisateur passent par ces contextes non échappés, des attaquants peuvent injecter des scripts malveillants qui s'exécutent dans le navigateur de la victime, pouvant potentiellement voler des jetons de session, accéder à des données sensibles ou effectuer des actions non autorisées.

Remédiation :

Envisagez de supprimer le remplacement de la fonction mustache.escape et de vous appuyer sur le comportement d'échappement HTML par défaut de Mustache qui utilise la syntaxe à double accolade {{variable}}. Si vous devez rendre du HTML de confiance à des endroits spécifiques, utilisez la syntaxe triple accolade {{{variable}}} ou ampersand {{&variable}} de manière sélective et uniquement avec des données provenant de sources sûres, jamais avec des entrées utilisateur. Pour les contenus générés par l'utilisateur qui nécessitent un formatage HTML, nettoyez-les d'abord en utilisant DOMPurify avant de les passer au modèle : mustache.render(template, { content: DOMPurify.sanitize(userInput) }). Implémentez la validation des entrées côté serveur et des en-têtes Content Security Policy (CSP) pour fournir une protection en profondeur. Passez en revue tous les modèles Mustache pour garantir que les interpolations non échappées ne sont utilisées qu'avec du contenu statique de confiance ou des données correctement assainies, et non avec des paramètres de requête, des entrées de formulaire, ou des données provenant d'API externes.

OWASP :

A7:2017-Cross-Site Scripting (XSS)
A03:2021-Injection

rules-javascript-xss-generic¶

Résumé :

Neutralisation inadéquate des entrées lors de la génération de pages web ('Cross-site Scripting')

Gravité : Moyenne

CWE : CWE-79

Description :

L'application passe des entrées d'utilisateur non assainies à des méthodes de manipulation DOM dangereuses ou à des fonctions de réponse HTTP pouvant conduire à du Cross-Site Scripting (XSS). Cette règle détecte les données provenant de sources non fiables comme req.query, req.body, location.href, document.querySelector().value, et les arguments de fonction dans des puits sensibles incluant innerHTML, outerHTML, document.write(), document.writeln(), des méthodes jQuery comme $.html(), $.append(), et des méthodes de réponse Express comme res.send(). Ces puits rendent le contenu directement dans le DOM ou les réponses HTTP sans évasion automatique. Lorsque des données contrôlées par l'utilisateur pénètrent ces voies, des attaquants peuvent injecter du JavaScript malveillant qui s'exécute dans le navigateur de la victime, potentiellement en volant des cookies de session, en accédant au stockage local, en détournant des comptes utilisateurs ou en effectuant des appels API non autorisés. Cette vulnérabilité affecte à la fois le XSS basé sur le DOM (sources côté client comme les fragments d'URL), le XSS réfléchi (entrées renvoyées par le serveur) et le XSS stocké (contenu malveillant persisté).

Remédiation :

Envisagez d'utiliser des méthodes de manipulation DOM sûres qui n'interprètent pas le HTML : remplacez element.innerHTML par element.textContent ou element.innerText qui échappent automatiquement le contenu. Pour jQuery, utilisez $.text() au lieu de $.html(). Si vous devez rendre du HTML à partir d'entrées d'utilisateur (comme du markdown ou du texte enrichi), assainissez-le d'abord en utilisant DOMPurify avec une liste d'autorisation stricte : element.innerHTML = DOMPurify.sanitize(userInput, { ALLOWED_TAGS: ['p', 'b', 'i', 'em'] }). Pour les réponses du serveur, utilisez des moteurs de templating avec évasion automatique comme Pug, EJS (avec la syntaxe <%=), ou Handlebars. Implémentez des en-têtes de politique de sécurité de contenu (CSP) avec script-src 'self' et évitez unsafe-inline. Pour les contextes d'URL, utilisez encodeURIComponent() pour échapper les caractères spéciaux. Ne passez jamais d'entrées d'utilisateur à eval(), setTimeout(string), Function(), ou document.write(). Validez et assainissez toutes les entrées côté serveur avant de les stocker ou de les rendre.

OWASP :

A7:2017-Cross-Site Scripting (XSS)
A03:2021-Injection

rules_javascript_xss_bad_csp¶

Résumé :

En-tête CSP non sécurisée

Sévérité : Moyenne

CWE : CWE-79

Description :

L'application configure un en-tête de Politique de Sécurité du Contenu (CSP) avec des directives non sécurisées qui affaiblissent considérablement la protection contre les XSS. La règle détecte des valeurs CSP dangereuses incluant unsafe-eval (qui permet l'exécution de JavaScript via eval(), setTimeout(string) et Function()), unsafe-inline (qui permet les balises <script> en ligne et les attributs de gestionnaires d'événements comme onclick), les URI data: et blob: (qui permettent le chargement de ressources à partir d'URL de données potentiellement contrôlées par des attaquants) et les sources génériques * (qui autorisent le chargement de contenu depuis n'importe quelle origine). Ces directives permissives compromettent le but principal du CSP de prévenir les XSS en restreignant les origines d'où les scripts peuvent se charger et comment ils s'exécutent. Un CSP faible offre une fausse confiance en la sécurité tout en rendant l'application vulnérable aux attaques par injection de scripts, en particulier lorsqu'il est combiné avec d'autres vulnérabilités comme les XSS basés sur le DOM ou les XSS réfléchis.

Remédiation :

Envisagez de mettre en place une Politique de Sécurité du Contenu stricte qui supprime les directives non sécurisées. Remplacez unsafe-inline par un filtrage de scripts basé sur des nonces ou des hachages : script-src 'nonce-{random}' où chaque balise script inclut l'attribut nonce correspondant. Supprimez complètement unsafe-eval et refactorisez le code pour éviter eval() et les minuteries basées sur des chaînes de caractères. Remplacez les jokers * par des domaines de confiance explicites : script-src 'self' https://trusted-cdn.example.com. Interdisez les URI data: et blob: dans les directives script-src, object-src et worker-src. Utilisez default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none' comme politique de base sécurisée. Pour les applications modernes, implémentez script-src 'strict-dynamic' avec des nonces, ce qui permet au CSP de fonctionner avec des scripts chargés dynamiquement tout en maintenant la sécurité. Testez soigneusement les changements de CSP en utilisant d'abord l'en-tête Content-Security-Policy-Report-Only pour éviter de casser les fonctionnalités.

OWASP :

A7:2017-Cross-Site Scripting (XSS)
A03:2021-Injection

règles_lgpl_javascript_règle_xss-handlebars-noescape¶

Résumé :

Neutralisation incorrecte des balises HTML liées aux scripts dans une page web (XSS basique)

Sévérité : Moyenne

CWE : CWE-80

Description :

L'application compile des modèles Handlebars en utilisant Handlebars.compile() avec l'option de configuration non sécurisée {noEscape: true}, qui désactive l'échappement par défaut des entités HTML du moteur de modèle. Handlebars échappe automatiquement les interpolations de variables de modèle en utilisant la syntaxe {{variable}} pour prévenir les attaques de Cross-Site Scripting (XSS) en convertissant des caractères comme <, >, &, et " en leurs équivalents d'entités HTML. En réglant noEscape: true, on supprime cette protection vitale de sécurité, permettant à du HTML et du JavaScript bruts d'être rendus dans le DOM. Lorsque des données contrôlées par l'utilisateur transitent par des modèles Handlebars non échappés, les attaquants peuvent injecter des scripts malveillants qui s'exécutent dans le navigateur de la victime, potentiellement volés des cookies de session, accédant à des données sensibles, ou exécutant des actions non autorisées au nom de l'utilisateur.

Remédiation :

Envisagez de supprimer l'option {noEscape: true} des appels à Handlebars.compile() pour rétablir l'échappement HTML automatique, qui est le comportement par défaut sécurisé. Si vous devez rendre du HTML de confiance à des endroits spécifiques, utilisez la syntaxe de triple accolades {{{variable}}} de manière sélective pour le contenu connu comme étant sûr tout en conservant l'échappement par défaut pour toutes les autres variables. Pour le contenu généré par l'utilisateur qui doit inclure un formatage, nettoyez-le d'abord en utilisant DOMPurify avant de le passer à Handlebars : Handlebars.compile(template)({ content: DOMPurify.sanitize(userInput) }). De plus, implémentez des en-têtes de Content Security Policy (CSP) pour fournir une protection en profondeur contre le XSS. Passez en revue tous les modèles Handlebars pour vous assurer que la syntaxe de triple accolades et noEscape ne sont utilisés qu'avec des données provenant de sources de confiance et contrôlées, jamais avec des entrées utilisateur ou des données d'APIs externes.

OWASP :

A7:2017-Cross-Site Scripting (XSS)
A03:2021-Injection

rules_lgpl_javascript_xss_rule-handlebars-safestring¶

Résumé :

Neutralisation inadéquate des entrées lors de la génération de pages web (Cross-site Scripting)

Sévérité : Moyenne

CWE : CWE-79

Description :

L'application utilise new Handlebars.SafeString() pour envelopper le contenu qui sera rendu sans échappement HTML dans les modèles Handlebars. Le constructeur SafeString marque explicitement le contenu comme digne de confiance et sûr pour un rendu HTML direct, contournant la protection par défaut de Handlebars contre le Cross-Site Scripting (XSS). Lorsque des données contrôlées par l'utilisateur sont introduites dans un SafeString sans désinfection appropriée, des attaquants peuvent injecter du JavaScript malveillant qui s'exécute dans le contexte du navigateur de la victime. Cela est particulièrement dangereux car SafeString est conçu pour désactiver l'échappement, et si des données non fiables l'atteignent (par exemple, depuis req.query, req.body ou des paramètres d'URL), l'application devient vulnérable aux attaques XSS qui peuvent voler des jetons d'authentification, accéder au stockage local ou effectuer des actions non autorisées au nom de la victime.

Remédiation :

Envisagez d'éviter complètement SafeString et de vous fier à la syntaxe par défaut de Handlebars {{variable}} qui échappe automatiquement les entités HTML. Si vous devez construire des chaînes HTML de manière programmatique (comme dans les helpers Handlebars), échappez toujours les portions contrôlées par l'utilisateur en utilisant Handlebars.escapeExpression() avant de les envelopper dans SafeString : new Handlebars.SafeString('<div>' + Handlebars.escapeExpression(userInput) + '</div>'). Pour le contenu riche nécessitant un formatage HTML, désinfectez-le à l'aide de DOMPurify avant de créer le SafeString. Mieux encore, refactorisez le code pour utiliser des partials et des helpers de bloc Handlebars qui permettent de composer des modèles en toute sécurité sans construction brute de HTML. Implémentez une validation des entrées côté serveur et des en-têtes de Politique de Sécurité du Contenu (CSP) pour fournir une protection supplémentaire contre les XSS. Examinez toute utilisation de SafeString pour vous assurer qu'elle enveloppe uniquement du contenu statique de confiance ou des données dynamiques correctement échappées.

OWASP :

A7:2017-Cross-Site Scripting (XSS)
A03:2021-Injection

règles_lgpl_javascript_xss_rule-squirrelly-autoescape¶

Résumé :

Neutralisation inadéquate des entrées lors de la génération de pages web ('Cross-site Scripting')

Gravité : Moyenne

CWE : CWE-79

Description :

L'application appelle Sqrl.autoEscaping(false) qui désactive l'échappement HTML automatique dans le moteur de template Squirrelly. Par défaut, Squirrelly (souvent abrégé en Sqrl) échappe automatiquement les interpolations de variables de template en utilisant la syntaxe {{variable}} pour prévenir les Cross-Site Scripting (XSS) en convertissant des caractères comme <, >, &, et " en entités HTML. Appeler autoEscaping(false) désactive globalement cette protection pour tous les rendus de template suivants, permettant l'injection de HTML brut et de JavaScript dans le DOM. Lorsque des données contrôlées par l'utilisateur provenant de sources telles que req.query, req.body, des paramètres d'URL ou des entrées de formulaire passent par des templates avec l'auto-échappement désactivé, les attaquants peuvent injecter des scripts malveillants qui s'exécutent dans le navigateur de la victime, potentiellement volant des cookies de session, accédant à des données sensibles de l'application, ou effectuant des actions non autorisées au nom de l'utilisateur.

Remédiation :

Envisagez de supprimer l'appel Sqrl.autoEscaping(false) et de vous fier au comportement par défaut de Squirrelly autoEscaping(true) qui fournit un échappement automatique des entités HTML. Si vous devez rendre du HTML de confiance dans des sections de template spécifiques, utilisez le filtre brut de Squirrelly {{variable | raw}} sélectivement pour du contenu connu comme sûr tout en maintenant l'auto-échappement activé globalement. Pour le contenu généré par l'utilisateur qui nécessite un formatage HTML (comme la sortie d'un éditeur de texte riche), nettoyez-le d'abord avec DOMPurify avant de le passer au template : Sqrl.Render(template, { content: DOMPurify.sanitize (userInput) }). Mettez en œuvre une validation des entrées côté serveur, des en-têtes de politique de sécurité de contenu (CSP), et assurez-vous que toute utilisation du filtre brut est limitée aux données provenant de sources fiables et contrôlées. Passez en revue tous les templates Squirrelly pour vérifier que les entrées utilisateur ne sont jamais rendues avec l'auto-échappement désactivé.

OWASP :

A7:2017-Cross-Site Scripting (XSS)
A03:2021-Injection

rules_lgpl_javascript_xss_rule-xss-serialize-javascript¶

Résumé :

Neutralisation inappropriée des balises HTML liées aux scripts dans une page web (XSS basique)

Gravité : Moyenne

CWE : CWE-80

Description :

L'application utilise la bibliothèque serialize-javascript avec l'option de configuration {unsafe: true}, ce qui désactive les mécanismes de protection XSS de la bibliothèque. Le package serialize-javascript est conçu pour sérialiser en toute sécurité les objets JavaScript en chaînes pouvant être intégrées dans du HTML (typiquement dans des balises <script> pour le r rendu côté serveur). Par défaut, il échappe les caractères dangereux comme <, >, et / pour prévenir les attaques XSS lorsque la sortie sérialisée est injectée dans le HTML. L'option unsafe: true désactive cet échappement, permettant au code JavaScript brut et aux balises HTML de passer sans modification. Lorsque des données contrôlées par l'utilisateur sont sérialisées avec le drapeau unsafe et ensuite intégrées dans le HTML, les attaquants peuvent injecter du JavaScript malveillant qui s'exécute lorsque la page se charge, ce qui peut potentiellement voler des jetons d'authentification, accéder à des données sensibles ou effectuer des actions non autorisées dans le navigateur de la victime.

Remédiation :

Envisagez de supprimer l'option {unsafe: true} des appels à serialize-javascript et reposez-vous sur le comportement de sérialisation sécurisée par défaut de la bibliothèque qui échappe les caractères spéciaux HTML. La configuration par défaut protège contre les XSS lors de l'intégration de données sérialisées dans des balises <script> : <script>window.__DATA__ = ${serialize(data)}</script>. Si vous êtes certain que les données sérialisées proviennent d'une source entièrement fiable sans entrée utilisateur, documentez clairement cette hypothèse dans les commentaires du code et envisagez de mettre en œuvre des assertions runtime pour vérifier les sources de données. Pour les applications modernes, envisagez des approches alternatives comme le passage de données via JSON dans des attributs data (<div data-config='${JSON.stringify(config)}'>) ou l'utilisation d'une solution de gestion d'état propre qui ne nécessite pas d'intégrer du JavaScript dans le HTML. Implémentez des en-têtes de politique de sécurité de contenu (CSP) et assurez-vous que toutes les entrées utilisateur sont validées sur le serveur avant la sérialisation.

OWASP :

A7:2017-Cross-Site Scripting (XSS)
A03:2021-Injection

javascript_require_rule-non-literal-require¶

Résumé :

Neutralisation inadéquate des directives dans le code évalué dynamiquement ('Injection Eval')

Sévérité : Faible

CWE : CWE-95

Description :

L'application importe dynamiquement des modules en utilisant require() avec un argument de chaîne non littérale. Cela permet des attaques potentielles par injection de code où un adversaire pourrait manipuler le chemin du module pour lire le contenu de fichiers arbitraires ou, avec un accès en écriture au système de fichiers, exécuter du code malveillant. Le chargement dynamique de modules rompt l'analyse statique et crée des limites de sécurité imprévisibles.

Remédiation :

Envisagez d'utiliser des instructions import statiques ES6 au lieu de require() pour permettre la résolution des modules à la compilation. Si des imports dynamiques sont nécessaires, il est recommandé de valider le chemin du module par rapport à une liste blanche stricte de modules autorisés avant le chargement. Ne passez jamais des entrées contrôlées par l'utilisateur directement à require(). Pour les scénarios de chargement de code dynamique, envisagez d'utiliser un objet de mappage où l'entrée de l'utilisateur sélectionne une clé qui correspond à un chemin de module codé en dur.

OWASP :

A1:2017-Injection
A03:2021-Injection