A6:2017-Mauvaise configuration de sécurité
A05:2021-Mauvaise configuration de sécurité

Résumé :

Cookie sensible sans le drapeau 'HttpOnly'

Gravité : Moyen

CWE : CWE-1004

Description :

L'application définit explicitement httpOnly: false dans la configuration des cookies pour cookie-session ou express-session, ce qui permet à JavaScript côté client d'accéder aux cookies de session via document.cookie. Cela augmente considérablement le risque de détournement de session par des attaques de script inter-sites (XSS), car des scripts malveillants injectés dans l'application peuvent voler des identifiants de session et les envoyer vers des serveurs contrôlés par des attaquants. Le drapeau httpOnly est une mesure critique de défense en profondeur qui empêche l'accès JavaScript aux cookies, même lorsque des vulnérabilités XSS existent dans l'application.

Remédiation :

Envisagez de supprimer la configuration httpOnly: false ou de définir explicitement httpOnly: true dans vos options de middleware de session. Par exemple, utilisez session({ cookie: { httpOnly: true } }) lors de la configuration de la session. Notez que httpOnly est généralement activé par défaut dans la plupart des middlewares de session, vous devrez donc peut-être simplement supprimer le réglage explicite à false. Il existe très peu de cas d'utilisation légitimes pour permettre l'accès JavaScript aux cookies de session, et des approches alternatives, comme l'utilisation de jetons d'authentification séparés, devraient être envisagées si un accès côté client à l'état d'authentification est nécessaire. Le drapeau httpOnly fournit une protection même contre des attaques XSS sophistiquées qui pourraient contourner d'autres contrôles de sécurité.

OWASP :

A2:2017-Authentification rompue
A07:2021-Failles d'identification et d'authentification

Résumé :

Cookie sensible avec un attribut SameSite incorrect

Gravité : Moyenne

CWE : CWE-1275

Description :

L'application utilise le middleware cookie-session ou express-session sans configurer l'attribut sameSite sur 'strict' ou 'lax' dans les options du cookie, ce qui permet d'envoyer des cookies de session avec des requêtes inter-sites initiées par des sites tiers. Cette protection manquante rend l'application vulnérable aux attaques de type Cross-Site Request Forgery (CSRF), où des sites malveillants peuvent déclencher des actions authentifiées en s'appuyant sur la session active de l'utilisateur. Sans l'attribut sameSite, les navigateurs enverront les cookies de session avec toutes les requêtes, quel que soit l'origine, permettant ainsi aux attaquants d'effectuer des opérations non autorisées au nom des utilisateurs authentifiés.

Remédiation :

Envisagez de définir sameSite: 'strict' ou sameSite: 'lax' dans la configuration du cookie du middleware de session pour prévenir les attaques CSRF. Utilisez session({ cookie: { sameSite: 'strict' } }) pour une protection maximale, ce qui empêche le cookie d'être envoyé avec toute requête inter-sites. Pour les applications nécessitant de prendre en charge des liens entrants provenant de sites externes (comme des liens par email ou sur les réseaux sociaux), utilisez plutôt sameSite: 'lax', qui permet l'envoi de cookies avec une navigation de premier niveau mais les bloque pour les requêtes intégrées, comme les images ou les iframes. Dans les navigateurs modernes, 'lax' devient le paramètre par défaut, mais une configuration explicite garantit un comportement cohérent. Pour les API qui doivent accepter des requêtes inter-origines, envisagez d'utiliser une authentification basée sur des jetons au lieu de sessions basées sur des cookies.

OWASP :

A2:2017-Authentification Brisée
A07:2021-Failles d'Identification et d'Authentification

Résumé :

Cookie sensible dans une session HTTPS sans l'attribut 'Secure'

Sévérité : Moyenne

CWE : CWE-614

Description :

L'application utilise les middlewares cookie-session ou express-session sans configurer le drapeau secure: true dans les options des cookies, ce qui permet aux cookies de session d'être transmis sur des connexions HTTP non chiffrées. Cela expose les identifiants de session aux attaquants basés sur le réseau qui peuvent intercepter le trafic par le biais d'attaques de type homme du milieu, ce qui peut entraîner un détournement de session et un accès non autorisé au compte. Sans le drapeau sécurisé, les navigateurs envoient le cookie de session sur les connexions HTTP et HTTPS.

Remédiation :

Envisagez de définir secure: true dans la configuration des cookies du middleware de session pour garantir que les cookies de session ne soient transmis que sur des connexions HTTPS. Par exemple, utilisez session({ cookie: { secure: true } }) lors de l'initialisation du middleware. Dans les environnements de production, cela doit toujours être activé, mais notez que cela nécessite que l'application soit servie via HTTPS. Pour les environnements de développement utilisant HTTP, vous pouvez le définir de façon conditionnelle en fonction de l'environnement, comme secure: process.env.NODE_ENV === 'production'. De plus, envisagez d'utiliser le package express-session avec un magasin de session sécurisé comme Redis ou MongoDB plutôt qu'un stockage en mémoire pour les applications de production.

OWASP :

A2:2017-Authentification cassée
A07:2021-Failles d'identification et d'authentification

rules_lgpl_javascript_headers_rule-express-cors¶

Résumé :

Erreur de validation d'origine

Sévérité : Moyenne

CWE : CWE-346

Description :

L'application définit l'en-tête de réponse Access-Control-Allow-Origin sur '*' (joker) en utilisant des méthodes d'Express.js comme res.set(), res.header(), ou res.writeHead(), ou active le CORS en wildcard en utilisant app.options('*', cors()). Cela désactive le mécanisme de sécurité de la Politique de même origine, permettant à n'importe quel site web sur Internet d'effectuer des requêtes cross-origin vers cette application et de lire les réponses. Cela est particulièrement dangereux lorsque l'application manipule des données sensibles ou des authentifications, car des sites web malveillants peuvent faire des requêtes au nom d'utilisateurs authentifiés et accéder à leurs informations personnelles. L'origine wildcard contourne le modèle de sécurité fondamental du navigateur conçu pour empêcher un accès non autorisé aux données cross-origin.

Remédiation :

Envisagez de configurer le CORS avec une liste blanche spécifique d'origines autorisées au lieu d'utiliser le joker. Pour les applications Express.js utilisant le middleware cors, utilisez l'option origin avec un tableau ou une fonction, tel que cors({ origin: ['https://trusted-site.com', 'https://another-trusted.com'] }). Pour une validation dynamique des origines, utilisez une fonction comme cors({ origin: (origin, callback) => { callback(null, allowedOrigins.includes(origin)) } }). Si vous devez prendre en charge plusieurs origines, validez chaque origine par rapport à une liste blanche avant de définir l'en-tête. N'utilisez jamais le CORS en wildcard pour les APIs qui gèrent l'authentification ou des données sensibles. Pour les APIs publiques qui ont réellement besoin d'un accès universel, envisagez d'utiliser des clés API ou d'autres mécanismes d'authentification au lieu de dépendre des restrictions CORS. Assurez-vous également que les informations d'identification ne soient pas autorisées lors de l'utilisation de politiques CORS plus larges.

OWASP :

A6:2017-Mauvaise configuration de la sécurité
A05:2021-Mauvaise configuration de la sécurité

rules_lgpl_javascript_headers_rule-generic-cors¶

Résumé :

Erreur de validation d'origine

Gravité : Moyenne

CWE : CWE-346

Description :

L'application utilise app.options('*', cors()) pour activer les réponses de pré-vol CORS pour toutes les routes avec correspondance générique, ce qui entraîne généralement le réglage de Access-Control-Allow-Origin: * pour les requêtes OPTIONS. Cette configuration désactive les protections de la politique de même origine à travers toute l'application, permettant à n'importe quel site web de faire des requêtes inter-origin. Bien que les requêtes OPTIONS elles-mêmes n'exposent pas de données, ce modèle indique souvent une configuration CORS trop permissive qui s'étend aux requêtes de données réelles. Les politiques CORS avec des jokers sapent fondamentalement les mécanismes de sécurité des navigateurs conçus pour prévenir l'accès non autorisé aux ressources sensibles.

Remédiation :

Envisagez de remplacer le gestionnaire d'options génériques par des configurations CORS spécifiques aux routes qui ne mettent sur liste blanche que les origines de confiance. Utilisez le middleware cors avec une configuration d'origine spécifique, comme app.options('/api/*', cors({ origin: 'https://trusted-domain.com' })) pour des modèles de routes spécifiques. Pour les applications qui doivent prendre en charge plusieurs origines de confiance, utilisez un tableau comme cors({ origin: ['https://site1.com', 'https://site2.com'] }) ou implémentez une validation dynamique avec une fonction d'origine. Supprimez l'appel global app.options('*', cors()) et appliquez plutôt le middleware CORS sélectivement aux routes qui nécessitent un accès inter-origine. Pour les API publiques, envisagez de mettre en œuvre une authentification par clé API plutôt que de compter sur CORS comme contrôle de sécurité. Documentez quelles origines sont autorisées et pourquoi dans votre code pour éviter des reconfigurations accidentelles lors des mises à jour.

OWASP :

A6:2017-Mauvaise configuration de sécurité
A05:2021-Mauvaise configuration de sécurité

rules_lgpl_javascript_headers_rule-header-xss-generic¶

Résumé :

Vérification de sécurité mal mise en œuvre pour la norme

Severité : Moyenne

CWE : CWE-358

Description :

L'application définit explicitement l'en-tête X-XSS-Protection à 0 en utilisant des méthodes Express.js comme res.header(), res.set(), ou res.writeHead(), ce qui désactive le filtre XSS intégré du navigateur. Bien que les navigateurs modernes avec le support de la politique de sécurité de contenu aient déprécié cet en-tête au profit de CSP, désactiver la protection contre les XSS pour les anciens navigateurs supprime une couche de défense importante contre les attaques de cross-site scripting reflétées. L'en-tête X-XSS-Protection défini à 0 indique explicitement aux navigateurs de ne pas tenter de détecter et de bloquer les attaques XSS, laissant ainsi les utilisateurs d'anciens navigateurs plus vulnérables. Cette configuration est particulièrement problématique si l'application manque d'une mise en œuvre complète de la politique de sécurité de contenu.

Remédiation :

Envisagez de supprimer la définition explicite de l'en-tête X-XSS-Protection: 0 ou de la changer en X-XSS-Protection: 1; mode=block pour activer la protection XSS du navigateur. Pour les applications Express.js, vous pouvez utiliser res.set('X-XSS-Protection', '1; mode=block') ou vous appuyer sur le middleware Helmet.js qui définit des valeurs par défaut sécurisées. La meilleure solution à long terme est de mettre en œuvre une politique de sécurité de contenu stricte qui empêche les attaques XSS à la source, rendant l'en-tête X-XSS-Protection redondant. Si vous utilisez Helmet, la configuration par défaut active une protection XSS appropriée. Pour les applications modernes, concentrez-vous sur la mise en œuvre de CSP avec des directives telles que default-src 'self'; script-src 'self' pour prévenir de manière exhaustive les attaques XSS. Ne désactivez l'en-tête X-XSS-Protection que si vous avez une mise en œuvre CSP robuste et avez documenté pourquoi la compatibilité avec les anciens navigateurs n'est pas nécessaire.

OWASP :

A6:2017-Mauvaise configuration de la sécurité
A05:2021-Mauvaise configuration de la sécurité

rules_lgpl_javascript_headers_rule-header-xss-lusca¶

Résumé :

Vérification de sécurité mal implémentée pour la norme

Gravité : Moyenne

CWE : CWE-358

Description :

L'application désactive explicitement la protection contre les XSS dans le middleware de sécurité Lusca en utilisant lusca.xssProtection(false) ou lusca({ xssProtection: false }), ce qui empêche l'en-tête X-XSS-Protection d'être défini ou le définit à 0. Lusca est un middleware de sécurité qui fournit plusieurs mécanismes de protection, et désactiver la protection XSS supprime une couche de défense importante contre les attaques de cross-site scripting réfléchi sur les anciens navigateurs. Alors que les navigateurs modernes ont déprécié X-XSS-Protection au profit de la Politique de Sécurité du Contenu, le fait de la désactiver explicitement dans la configuration du middleware laisse les utilisateurs de navigateurs obsolètes vulnérables. Cette configuration suggère un choix délibéré de supprimer la protection XSS au niveau du navigateur sans avoir nécessairement une alternative CSP complète en place.

Remédiation :

Envisagez de supprimer le paramètre xssProtection: false de votre configuration Lusca pour permettre la définition de l'en-tête XSS de protection par défaut. Lusca active X-XSS-Protection par défaut, vous pouvez donc simplement omettre cette option ou définir explicitement lusca({ xssProtection: true }). Si vous le désactivez à cause de conflits avec la Politique de Sécurité du Contenu, assurez-vous d'avoir une mise en œuvre robuste du CSP avant de supprimer les filtres XSS du navigateur. La meilleure pratique consiste à utiliser à la fois la protection XSS par défaut de Lusca et à mettre en œuvre une Politique de Sécurité du Contenu stricte avec des directives telles que script-src 'self' pour fournir une défense en couches. Si vous utilisez Helmet en même temps que Lusca, coordonnez le middleware pour éviter les conflits tout en maintenant une protection maximale. Gardez à l'esprit que les anciens navigateurs s'appuient toujours sur X-XSS-Protection, donc maintenir cette option activée offre une compatibilité ascendante et une défense en profondeur même lorsque CSP est votre principal mécanisme de prévention des XSS.

OWASP :

A6:2017-Misconfiguration de la sécurité
A05:2021-Misconfiguration de la sécurité

rules_lgpl_javascript_headers_rule-helmet-feature-disabled¶

Résumé :

Contrôle de sécurité mal implémenté pour le standard

Sévérité : Moyenne

CWE : CWE-358

Description :

L'application désactive explicitement une ou plusieurs fonctionnalités de sécurité dans le middleware Helmet.js en définissant des options telles que frameguard: false, contentSecurityPolicy: false, hsts: false, noSniff: false ou xssFilter: false. Helmet.js fournit par défaut des en-têtes de sécurité essentiels, et désactiver ces fonctionnalités supprime des protections critiques contre des vulnérabilités web courantes. Chaque fonctionnalité désactivée représente un vecteur d'attaque spécifique : frameguard empêche le clickjacking, contentSecurityPolicy bloque les attaques XSS, hsts empêche l'attaque par stripping SSL, noSniff arrête les attaques de sniffing de type MIME, et xssFilter active la protection XSS du navigateur. Définir ces paramètres sur false indique une décision consciente de supprimer des contrôles de sécurité, ce qui est rarement justifié et augmente considérablement la surface d'attaque.

Remédiation :

Envisagez de retirer les paramètres explicites false de votre configuration Helmet et de permettre aux en-têtes de sécurité par défaut d'être définis. Si vous devez désactiver des fonctionnalités spécifiques, documentez la justification commerciale ou technique dans les commentaires du code et limitez la désactivation à des routes spécifiques plutôt qu'à l'échelle globale. Pour le Content Security Policy, si la politique par défaut est trop stricte, personnalisez-la avec des directives appropriées plutôt que de la désactiver complètement, comme contentSecurityPolicy: { directives: { defaultSrc: ["'self'"], scriptSrc: ["'self'", "'unsafe-inline'"] } }. Pour frameguard, utilisez frameguard: { action: 'sameorigin' } si vous devez permettre le framing de même origine. Passez en revue chaque fonctionnalité désactivée et implémentez le contrôle de sécurité de la manière la moins permissive possible. Envisagez d'utiliser des configurations Helmet spécifiques aux routes si certaines routes ont des exigences de sécurité différentes. Privilégiez toujours la personnalisation des politiques plutôt que la désactivation complète des fonctionnalités de sécurité.

OWASP :

A6:2017-Misconfiguration de sécurité
A05:2021-Misconfiguration de sécurité

rules_lgpl_javascript_headers_rule-host-header-injection¶

Résumé :

Utilisation d'une source moins fiable

Gravité : Moyenne

CWE : CWE-348

Description :

L'application utilise la valeur non fiable req.host ou req.headers.host provenant de l'en-tête HTTP Host pour construire des URL, généralement en la concaténant avec des chaînes de protocole comme 'http://' ou 'https://'. L'en-tête Host est complètement contrôlé par l'attaquant et peut être manipulé pour injecter des domaines malveillants. Cela conduit à l'empoisonnement du cache web, où les réponses mises en cache contiennent des URL contrôlées par l'attaquant, à l'empoisonnement des réinitialisations de mot de passe, où les liens de réinitialisation pointent vers des serveurs contrôlés par l'attaquant, et à des opportunités de falsification de requêtes côté serveur (SSRF). Ces attaques sont particulièrement graves lorsque les URL générées sont intégrées dans des e-mails, stockées dans des bases de données ou mises en cache par des CDN, permettant aux attaquants de compromettre des utilisateurs qui n'ont jamais interagi directement avec la requête malveillante.

Remédiation :

Envisagez d'utiliser un nom de domaine codé en dur ou basé sur une configuration au lieu de compter sur l'en-tête Host pour la génération d'URL. Définissez le domaine canonique de l'application dans des variables d'environnement ou des fichiers de configuration, tels que const baseUrl = process.env.APP_BASE_URL || 'https://example.com' et utilisez ceci pour construire des URL. Si vous devez utiliser l'en-tête Host, appliquez une validation stricte par rapport à une liste blanche de domaines autorisés et rejetez toute requête avec des valeurs Host inattendues. Pour les applications Express.js, vous pouvez utiliser un middleware pour valider l'en-tête Host tôt dans le pipeline de requête. Lors du déploiement derrière des proxys inversés ou des équilibres de charge, configurez-les pour supprimer ou valider l'en-tête Host avant qu'il n'atteigne votre application. Pour les scénarios de réinitialisation de mot de passe et d'e-mail, utilisez toujours le domaine de l'application configuré plutôt que de refléter l'en-tête Host. Envisagez d'utiliser req.protocol avec un domaine configuré au lieu de req.host pour la construction d'URL.

OWASP :

A1:2017-Injection
A03:2021-Injection

rules_lgpl_javascript_ssrf_rule-wkhtmltoimage-ssrf¶

Résumé :

Falsification de requêtes côté serveur (SSRF)

Sévérité : Moyenne

CWE : CWE-918

Description :

Cette règle a détecté des URLs contrôlées par l'utilisateur passées à la fonction wkhtmltoimage.generate() sans validation. La bibliothèque wkhtmltoimage utilise un moteur WebKit sans interface graphique pour rendre des pages web sous forme d'images, et lorsque l'entrée de l'utilisateur contrôle le paramètre URL, des vulnérabilités de falsification de requêtes côté serveur (SSRF) apparaissent. Les attaquants peuvent en profiter pour forcer le serveur à accéder à des ressources internes, à des points de terminaison de métadonnées cloud (169.254.169.254), ou à analyser des services réseau internes. Cela peut exposer des APIs internes, des interfaces administratives, des fichiers sensibles via des URLs file://, ou permettre une cartographie du réseau qui contourne les protections de pare-feu et la segmentation du réseau.

Remédiation :

Envisagez de mettre en œuvre une liste blanche d'URLs stricte qui valide l'entrée de l'utilisateur par rapport aux domaines approuvés avant de passer les URLs à wkhtmltoimage.generate(). Utilisez le parsing d'URL Node.js avec new URL() pour valider le schéma, le nom d'hôte et le port, et rejetez toute URL qui ne correspond pas à la liste blanche. Limitez les protocoles autorisés à http:// et https:// uniquement, en refusant explicitement file://, data://, et d'autres schémas dangereux qui pourraient permettre l'accès à des fichiers locaux. Mettez en œuvre une protection contre le rebinding DNS en résolvant les noms d'hôte en adresses IP et en bloquant les plages d'adresses IP privées (127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) et les adresses de métadonnées cloud (169.254.169.254). Les défenses au niveau du réseau peuvent inclure l'exécution de wkhtmltoimage dans un environnement sandbox avec des règles de filtrage sortant pour empêcher les connexions aux réseaux internes. Envisagez d'utiliser une approche de mappage côté serveur où l'entrée de l'utilisateur fournit des clés qui mappent à des URLs sûres préconfigurées plutôt que d'accepter des URLs arbitraires.

OWASP :

A1:2017-Injection
A10:2021-Falsification de Requêtes Côté Serveur

rules_lgpl_javascript_traversal_rule-admzip-path-overwrite¶

Résumé :

Limitation incorrecte d'un chemin d'accès à un répertoire restreint ('Traversée de chemin')

Sévérité : Moyenne

CWE : CWE-22

Description :

Cette application extrait des archives ZIP en utilisant le package adm-zip avec fs.createWriteStream(), fs.writeFile() ou fs.writeFileSync() sans sanitiser correctement les chemins d'accès des entrées. Des archives ZIP malveillantes peuvent contenir des entrées avec des séquences de traversée de chemin (par exemple, ../../etc/passwd) qui permettent aux attaquants de remplacer des fichiers arbitraires en dehors du répertoire d'extraction prévu, ce qui peut potentiellement mener à une injection de code ou à un compromis du système.

Remédiation :

Considérez la possibilité de valider tous les chemins d'accès des entrées avant l'extraction en vérifiant les séquences de traversée de chemin à l'aide de entry.entryName.indexOf('..') ou en normalisant les chemins avec path.basename(). Il est recommandé de combiner path.join() avec path.basename() lors de la construction des chemins d'extraction, garantissant que les fichiers sont écrits uniquement dans le répertoire prévu. Par exemple, utilisez fs.createWriteStream(path.join(extractDir, path.basename(entry.entryName))) au lieu d'utiliser directement entry.entryName. De plus, envisagez d'utiliser la méthode adm-zip extractEntryTo() qui fournit une validation de chemin intégrée, ou mettez en œuvre une liste blanche d'extensions de fichiers autorisées pour restreindre l'extraction aux types de fichiers sûrs uniquement.

OWASP :

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

rules_lgpl_javascript_traversal_rule-express-lfr¶

Résumé :

Traversée de chemin relative

Gravité : Moyenne

CWE : CWE-23

Description :

Cette application transmet des entrées de l'utilisateur non fiables provenant de req.body, req.params, req.query, req.cookies, ou d'autres propriétés de la requête directement à la fonction Express res.render(). Lors de l'utilisation de moteurs de modèle comme Handlebars (hbs), Pug ou EJS, cela permet des vulnérabilités de lecture de fichiers locaux où des attaquants peuvent créer des entrées malveillantes contenant des séquences de traversée de chemin (par exemple, ../../etc/passwd) pour accéder à des fichiers arbitraires sur le système de fichiers en dehors du répertoire de modèle prévu.

Remédiation :

Envisagez d'utiliser une approche de liste blanche où les noms de modèle sont mappés à des valeurs codées en dur plutôt que d'accepter directement les entrées de l'utilisateur. Par exemple, créez un objet de mappage comme { home: 'index', profile: 'user-profile' } et utilisez res.render(templateMap[req.query.page]) au lieu de res.render(req.query.page). Il est recommandé de valider l'entrée de l'utilisateur par rapport à un modèle strict (par exemple, uniquement alphanumérique) en utilisant des expressions régulières avant de la transmettre à render(). Si la sélection dynamique de modèles est nécessaire, normalisez les chemins en utilisant path.basename() pour éliminer les séquences de traversée de répertoires, bien que la liste blanche soit l'approche la plus sécurisée. De plus, configurez votre moteur de modèle pour restreindre la résolution des modèles à un répertoire spécifique et désactivez l'accès au système de fichiers en dehors de cette limite lorsque cela est possible.

OWASP :

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

rules_lgpl_javascript_traversal_rule-express-lfr-warning¶

Résumé :

Traversée de chemin relative

Gravité : Moyenne

CWE : CWE-23

Description :

Cette application utilise Express avec la fonction res.render() et passe des entrées utilisateur non fiables provenant de req.query, req.body, ou d'autres sources de requête en tant que paramètres de modèle ou noms de vues. Associé au moteur de templating Handlebars (hbs), ce modèle peut permettre des vulnérabilités de lecture de fichiers locaux où les attaquants exploitent les mécanismes de résolution de modèles pour accéder à des fichiers en dehors du répertoire de vues prévu via des séquences de traversée de chemin.

Remédiation :

Envisagez de mettre en œuvre une liste blanche stricte des noms de modèles autorisés et utilisez un objet d'énumération ou de mappage pour traduire les entrées utilisateur en chemins de modèles sûrs. Par exemple, au lieu de res.render(req.query.view, data), utilisez une recherche comme const validViews = { home: 'index', about: 'about-us' }; et res.render(validViews[req.query.view] || 'default', data). Il est recommandé d'éviter de passer les entrées utilisateur comme paramètre de vue entièrement lorsque cela est possible. Si des données de modèle dynamiques sont nécessaires, assurez-vous que les entrées utilisateur ne sont utilisées que dans l'objet de données passé en tant que deuxième paramètre à render(), jamais en tant que chemin de vue lui-même. De plus, configurez les paramètres du moteur de vue Express pour restreindre la résolution des modèles à un répertoire spécifique en utilisant app.set('views', path.join(__dirname, 'views')) et envisagez d'utiliser des chemins absolus.

OWASP :

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

rules_lgpl_javascript_traversal_rule-generic-path-traversal¶

Résumé :

Traversée de chemin relative

Sévérité : Moyenne

CWE : CWE-23

Description :

Cette application transmet des entrées utilisateur non fiables provenant d'objets de requête directement aux fonctions du système de fichiers Node.js, notamment fs.readFile(), fs.readFileSync(), fs.readFileAsync() ou fs.createReadStream(). Cela permet des attaques par traversée de répertoire où des attaquants créent des entrées malveillantes contenant des séquences de traversée de chemin (par exemple, ../../../../etc/passwd) pour lire des fichiers arbitraires en dehors du répertoire prévu, exposant potentiellement des fichiers de configuration sensibles, des identifiants, du code source ou des fichiers système.

Remédiation :

Envisagez de mettre en œuvre une liste blanche de noms de fichiers ou de chemins de fichiers autorisés plutôt que d'accepter des entrées d'utilisateur arbitraires. Par exemple, utilisez un objet de mappage pour traduire les entrées utilisateur en chemins sûrs, ou validez que le fichier demandé correspond à un modèle attendu. Il est recommandé d'utiliser path.basename() pour supprimer toute composante de répertoire de l'entrée utilisateur, combiné avec path.join() pour construire le chemin complet relatif à un répertoire de base sûr. Par exemple, utilisez fs.readFile(path.join(safeDir, path.basename(userInput))) pour garantir que les fichiers ne sont accessibles que dans safeDir. De plus, utilisez path.resolve() pour normaliser le chemin construit et vérifiez qu'il commence par votre répertoire sûr à l'aide de startsWith() pour prévenir les attaques de traversée. Envisagez de mettre en œuvre une validation des extensions de fichier pour restreindre l'accès à des types de fichiers spécifiques uniquement.

OWASP :

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

règles_lgpl_javascript_règle-de-parcours-join-résoudre-chemin-traversée¶

Résumé :

Limitation inadéquate d'un chemin d'accès à un répertoire restreint ('Traversée de chemin')

Gravité : Moyenne

CWE : CWE-22

Description :

Cette application construit des chemins de fichiers en utilisant path.join() ou path.resolve() avec des entrées non fiables de req.body, req.query ou d'autres sources de requête. Bien que ces fonctions du module de chemin normalisent les chemins, elles ne préviennent pas intrinsèquement les attaques de traversée de chemin. Les attaquants peuvent fournir des entrées contenant des séquences de traversée (par ex., ../../etc/passwd) qui, lorsqu'elles sont joints ou résolus, peuvent échapper au répertoire prévu et accéder à des fichiers arbitraires sur le système de fichiers lors d'opérations de fichiers ultérieures.

Remédiation :

Envisagez de sanitiser l'entrée de l'utilisateur avant de la passer à path.join() ou path.resolve() en utilisant path.basename() pour supprimer tout composant de répertoire. Par exemple, utilisez path.join(baseDir, path.basename(userInput)) plutôt que path.join(baseDir, userInput) pour vous assurer que seule la portion du nom de fichier est utilisée. Il est recommandé de mettre en œuvre une liste blanche de noms de fichiers ou de motifs autorisés et de valider l'entrée de l'utilisateur par rapport à cette liste avant la construction du chemin. Après avoir construit le chemin, vérifiez que le chemin absolu résolu commence par votre répertoire de base prévu en utilisant path.resolve() et startsWith() pour attraper toute tentative de traversée. Par exemple, const fullPath = path.resolve(baseDir, sanitizedInput); if (!fullPath.startsWith(baseDir)) throw error. De plus, envisagez d'utiliser path.normalize() avec précaution car il ne prévient pas à lui seul les attaques de traversée.

OWASP :

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

règles_lgpl_javascript_règle-parcours-tar-chemin-surcharge¶

Résumé :

Limitation inappropriée d'un chemin d'accès à un répertoire restreint ('Traversée de chemin')

Sévérité : Moyenne

CWE : CWE-22

Description :

Cette application extrait des archives TAR en utilisant le package tar-stream avec fs.createWriteStream(), fs.writeFile() ou fs.writeFileSync() dans un gestionnaire d'événements 'entry' sans correctement assainir les chemins d'accès des entrées. Des archives TAR malveillantes peuvent contenir des entrées avec des séquences de traversée de chemin (par exemple, ../../etc/cron.d/backdoor) qui permettent aux attaquants d'écrire des fichiers arbitraires en dehors du répertoire d'extraction prévu, ce qui peut potentiellement mener à une injection de code, à une compromission du système ou à une élévation de privilèges en écrasant des fichiers système critiques.

Remédiation :

Envisagez de valider tous les chemins d'entrée dans le gestionnaire d'événements 'entry' en vérifiant les séquences de traversée de chemin à l'aide de header.name.indexOf('..') !== -1 avant d'écrire des fichiers. Il est recommandé de normaliser les chemins avec path.basename() pour supprimer les composants de répertoire et de les combiner avec path.join() lors de la construction des chemins d'extraction. Par exemple, utilisez fs.createWriteStream(path.join(extractDir, path.basename(header.name))) au lieu d'utiliser directement header.name. De plus, utilisez path.resolve() pour obtenir le chemin absolu et vérifiez qu'il commence par votre répertoire d'extraction prévu avant l'écriture, en rejetant toute entrée qui dépasse la limite. Envisagez de mettre en œuvre une liste blanche d'extensions de fichiers autorisées et de rejeter les archives contenant des liens symboliques ou des liens physiques qui pourraient être utilisés pour des attaques de traversée.

OWASP :

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

règles_lgpl_règle_traversée_javascript-chemin-zip-surcharge¶

Résumé :

Limitations inappropriées d'un chemin d'accès à un répertoire restreint ('Traversée de chemin')

Gravité : Moyenne

CWE : CWE-22

Description :

Cette application extrait des archives ZIP en utilisant le package unzipper avec fs.createWriteStream(), fs.writeFile() ou fs.writeFileSync() dans un gestionnaire d'événements 'entry' sans bien nettoyer les chemins d'entrée. Le modèle détecte les cas où entry.path est utilisé directement pour écrire des fichiers sans validation en utilisant path.basename() ou en vérifiant les séquences de traversée de chemin avec indexOf(). Les archives ZIP malveillantes peuvent contenir des entrées avec des séquences de traversée (par exemple, ../../var/www/shell.php) qui permettent aux attaquants d'écrire des fichiers arbitraires en dehors du répertoire d'extraction prévu, ce qui peut mener à une exécution de code à distance ou à une compromission du système.

Remédiation :

Envisagez de nettoyer tous les chemins d'entrée avant d'écrire des fichiers en validant d'abord avec entry.path.indexOf('..') pour détecter les séquences de traversée et rejeter les entrées malveillantes. Il est recommandé d'utiliser path.basename(entry.path) pour extraire uniquement le composant du nom de fichier, puis de le combiner avec un répertoire d'extraction sûr en utilisant path.join(extractDir, path.basename(entry.path)). Pour préserver la structure des répertoires en toute sécurité, normalisez le chemin et vérifiez qu'il reste dans les limites en utilisant path.resolve() pour obtenir le chemin absolu et en vérifiant s'il commence par votre répertoire d'extraction. Par exemple : const safePath = path.resolve(extractDir, entry.path); if (!safePath.startsWith(extractDir)) rejeter. De plus, mettez en œuvre une liste blanche des extensions de fichiers autorisées et envisagez de valider le contenu de l'archive avant l'extraction pour prévenir les vulnérabilités d'upload de fichiers non restreints.

OWASP :

A5:2017-Control d'accès rompu
A01:2021-Control d'accès rompu

Résumé :

Identifiants insuffisamment protégés

Sévérité : Info

CWE : CWE-522

Description :

L'application utilise les middleware cookie-session ou express-session avec le nom de cookie par défaut (typiquement 'connect.sid' pour express-session ou 'session' pour cookie-session), ce qui fournit des informations inutiles aux attaquants potentiels concernant la pile technologique utilisée. Cette divulgation d'informations permet aux attaquants d'identifier le serveur et d'adapter les attaques spécifiquement aux vulnérabilités connues dans les frameworks ou versions de middleware détectés. Bien que cela ne soit pas directement exploitable, cela réduit l'effort requis pour la reconnaissance lors des attaques ciblées.

Remédiation :

Envisagez de définir un nom de cookie personnalisé en utilisant l'option name dans la configuration de votre middleware de session, comme session({ name: 'sid' }) ou un autre identifiant non descriptif. Choisissez un nom générique qui ne révèle pas d'informations sur votre pile technologique ou votre approche de gestion des sessions. C'est une mesure de défense en profondeur qui complique la reconnaissance pour les attaquants. Notez que changer le nom du cookie à lui seul ne fournit pas une sécurité forte, donc assurez-vous que d'autres contrôles de sécurité de session comme les drapeaux secure, httpOnly et sameSite sont correctement configurés. Certains scanners et audits de sécurité requièrent des noms de cookies personnalisés dans le cadre de leurs critères de conformité.

OWASP :

A2:2017-Authentication Brisée
A07:2021-Échecs d'Identification et d'Authentification

Résumé :

Informations sur des identifiants insuffisamment protégés

Gravité : Info

CWE : CWE-522

Description :

L'application utilise le middleware cookie-session ou express-session sans configurer explicitement l'attribut domain dans les options de cookie, ce qui signifie que le cookie par défaut sera associé au domaine exact qui l'a défini. Bien que ce comportement par défaut soit souvent sécurisé pour les applications à domaine unique, il peut entraîner des problèmes dans des environnements à plusieurs sous-domaines où le partage ou l'isolement de session n'est pas clairement défini. Ne pas définir l'attribut de domaine peut provoquer des comportements inattendus lorsque les applications s'étendent sur plusieurs sous-domaines ou lors de la migration entre différentes configurations de domaine.

Remédiation :

Envisagez de définir explicitement l'attribut domain dans votre configuration de middleware de session en fonction des besoins de votre application. Pour les applications à domaine unique, vous pouvez définir domain: 'example.com' pour restreindre les cookies à ce domaine spécifique. Pour les applications qui ont besoin de partager des sessions entre sous-domaines, utilisez domain: '.example.com' (avec un point au début) pour permettre aux cookies d'être envoyés à tous les sous-domaines. Soyez prudent avec le partage entre sous-domaines, car cela peut augmenter la surface d'attaque si un sous-domaine est compromis. Pour les applications qui ne doivent pas partager des sessions entre sous-domaines, soit omettez l'attribut de domaine, soit définissez-le explicitement sur le sous-domaine actuel. Documentez votre choix de configuration de domaine dans le code afin d'éviter des problèmes de sécurité lors des changements d'infrastructure.

OWASP :

A2:2017-Authentification compromise
A07:2021-Échecs d'identification et d'authentification

Résumé :

Expiration de session insuffisante

Sévérité : Info

CWE : CWE-613

Description :

L'application utilise le middleware cookie-session ou express-session sans configurer l'attribut maxAge dans les options de cookie, ce qui entraîne des cookies de session persistants comme des cookies de session de navigateur qui sont supprimés lorsque le navigateur se ferme. Bien que ce comportement par défaut fournisse une certaine sécurité en limitant la durée de vie de la session, cela peut entraîner une mauvaise expérience utilisateur avec des demandes fréquentes de ré-authentification et ne fournit pas de contrôle explicite sur la durée de la session. Sans un maxAge défini, la gestion de la durée de vie de la session dépend entièrement du comportement du navigateur, qui varie selon les différents navigateurs et configurations utilisateur.

Remédiation :

Envisagez de définir une valeur appropriée pour maxAge en millisecondes dans la configuration de votre middleware de session, comme session({ cookie: { maxAge: 3600000 } }) pour une session d'1 heure. La valeur appropriée dépend des exigences de sécurité de votre application et des besoins d'expérience utilisateur - des durées plus courtes (15-30 minutes) sont plus sécurisées pour les applications sensibles, tandis que des durées plus longues (heures ou jours) peuvent être acceptables pour des applications à risque plus faible. N'oubliez pas que maxAge est spécifié en millisecondes, donc utilisez des constantes ou des calculs comme 24 * 60 * 60 * 1000 pour plus de clarté. Pour les applications à haute sécurité, envisagez de mettre en œuvre une expiration de session glissante en mettant à jour le maxAge à chaque demande. Envisagez également d'implémenter à la fois un délai d'inactivité (maxAge) et un délai de session absolu pour une défense en profondeur.

OWASP :

A2:2017-Authentification rompue
A07:2021-Échecs d'identification et d'authentification

Résumé :

Identifiants insuffisamment protégés

Gravité : Info

CWE : CWE-522

Description :

L’application utilise le middleware cookie-session ou express-session sans configurer explicitement l’attribut path dans les options du cookie, qui par défaut est '/' et rend le cookie accessible à tous les chemins du domaine. Bien que ce paramètre par défaut soit souvent approprié pour les applications où l'authentification s'applique à l'ensemble du site, il peut entraîner des problèmes de sécurité dans des environnements d'hébergement partagé ou lorsque plusieurs applications fonctionnent sur différents chemins du même domaine. Ne pas définir explicitement l'attribut path peut entraîner l'envoi inutile de cookies de session avec des requêtes vers des chemins d'application non liés, augmentant l'exposition aux attaques inter-applications.

Remédiation :

Envisagez de définir explicitement l'attribut path dans la configuration de votre middleware de session en fonction du modèle de déploiement de votre application. Pour la plupart des applications, utiliser path: '/' (le par défaut) est approprié et devrait être défini explicitement pour plus de clarté, comme session({ cookie: { path: '/' } }). Pour les applications montées sur des préfixes de chemin spécifiques (par exemple, '/app'), définissez path: '/app' pour restreindre la portée du cookie uniquement à ce chemin et à ses sous-chemins. Cela empêche le cookie d'être envoyé à d'autres applications sur le même domaine. Soyez prudent lors de la modification de l'attribut path en production, car cela peut rendre les sessions existantes inaccessibles. Documentez votre choix de configuration de chemin, en particulier dans les environnements où plusieurs applications partagent un domaine ou lors de l'utilisation de proxys inverses avec un routage basé sur le chemin.

OWASP :

A2:2017-Authentification cassée
A07:2021-Failles d'identification et d'authentification

rules_lgpl_javascript_xss_rule-xss-disable-mustache-escape¶

Résumé :

Aucun

Gravité : Avertissement

Description :

L'application définit escapeMarkup = false, ce qui désactive l'échappement des entités HTML dans les bibliothèques de rendu de templates comme Select2, Typeahead, ou d'autres composants UI qui utilisent cette option de configuration. Lorsque escapeMarkup est défini sur false, le contenu contrôlé par l'utilisateur est rendu directement dans le DOM sans convertir les caractères dangereux tels que <, >, et " en leurs équivalents d'entités HTML. Cela permet aux attaquants d'injecter du JavaScript malveillant via des champs de saisie, des options de menu déroulant ou des suggestions de saisie semi-automatique. La vulnérabilité est particulièrement dangereuse dans les interfaces de recherche et de saisie semi-automatique où l'entrée de l'utilisateur est immédiatement renvoyée dans l'UI. Les attaques XSS via ces vecteurs peuvent voler des jetons d'authentification, détourner des sessions utilisateur, ou effectuer des actions au nom de la victime.

Remédiation :

Envisagez de supprimer la configuration escapeMarkup: false et de vous fier au comportement d'échappement HTML par défaut de la bibliothèque, qui protège contre les XSS. Si vous devez rendre du contenu formaté dans des options de menu déroulant ou des résultats de typeahead, utilisez une approche plus sûre, comme fournir une fonction de template personnalisée qui sanitise explicitement les parties contrôlées par l'utilisateur tout en permettant une structure HTML sûre : templateResult: function(data) { return $('<div>').text(data.userInput).html(); }. Pour les bibliothèques comme Select2, utilisez la fonction escapeMarkup avec DOMPurify pour assainir le HTML tout en préservant le formatage : escapeMarkup: function(markup) { return DOMPurify.sanitize(markup); }. Implémentez des en-têtes de Content Security Policy (CSP) pour limiter l'impact XSS et validez toutes les entrées utilisateur côté serveur avant de les stocker ou de les afficher.

Règles Semgrep pour JavaScript¶

rules_lgpl_javascript_database_rule-node-knex-sqli-injection¶

règles_lgpl_javascript_base_de_données_règle-no-sqli-injection¶

rules_lgpl_javascript_database_rule-node-nosqli-js-injection¶

rules_lgpl_javascript_database_rule-node-sqli-injection¶

rules_lgpl_javascript_database_rule-sequelize-weak-tls¶

règles_lgpl_javascript_electronjs_règle-electron-autoriser-http¶

rules_lgpl_javascript_electronjs_rule-electron-disable-websecurity¶

rules_lgpl_javascript_electronjs_rule-electron-experimental-features¶

rules_lgpl_javascript_eval_rule-eval-require¶

rules_lgpl_javascript_eval_rule-sandbox-code-injection¶

règles_lgpl_javascript_eval_rule-injection-de-modèle-côté-serveur¶

rules_lgpl_javascript_eval_rule-vm-code-injection¶

rules_lgpl_javascript_eval_rule-vm-compilefunction-injection¶

règles_lgpl_javascript_eval_rule-vm-runincontext-injection¶

règles_lgpl_javascript_eval_rule-vm-runinnewcontext-injection¶

rules_lgpl_javascript_eval_rule-vm2-code-injection¶

rules_lgpl_javascript_eval_rule-vm2-context-injection¶

rules_lgpl_javascript_exec_rule-shelljs-os-command-exec¶

rules_lgpl_javascript_headers_rule-generic-header-injection¶

rules_lgpl_javascript_jwt_rule-jwt-express-hardcoded¶

rules_lgpl_javascript_jwt_rule-node-jwt-none-algorithm¶

rules_lgpl_javascript_redirect_rule-express-open-redirect¶

rules_lgpl_javascript_redirect_rule-express-open-redirect2¶

rules_lgpl_javascript_ssrf_rule-phantom-ssrf¶

rules_lgpl_javascript_ssrf_rule-playwright-ssrf¶

rules_lgpl_javascript_ssrf_rule-puppeteer-ssrf¶

rules_lgpl_javascript_ssrf_rule-wkhtmltopdf-ssrf¶

rules_lgpl_javascript_xml_rule-node-entity-expansion¶

rules_lgpl_javascript_xml_rule-node-xpath-injection¶

rules_lgpl_javascript_xml_rule-node-xxe¶

rules_lgpl_javascript_xml_rule-xxe-expat¶

rule-js-ts-child-process-exec-injection¶

règles_lgpl_javascript_database_rule-sequelize-tls-cert-validation¶

rules_lgpl_javascript_eval_rule-eval-nodejs¶

rules_lgpl_javascript_jwt_rule-hardcoded-jwt-secret¶

règles_lgpl_javascript_jwt_rule-jwt-exposed-credentials¶

rules_lgpl_javascript_jwt_rule-jwt-exposed-data¶

rules_lgpl_javascript_jwt_rule-jwt-not-revoked¶

rules_lgpl_javascript_ssrf_rule-node-ssrf¶

javascript_buf_rule-buffer-noassert-read¶

javascript_buf_rule-buffer-noassert-write¶

javascript_timing_rule-possible-timing-attacks¶

rules_lgpl_javascript_crypto_rule-node-aes-ecb¶

rules_lgpl_javascript_crypto_rule-node-aes-noiv¶

rules_lgpl_javascript_crypto_rule-node-insecure-random-generator¶

rules_lgpl_javascript_crypto_rule-node-md5¶

rules_lgpl_javascript_crypto_rule-node-sha1¶

rules_lgpl_javascript_crypto_rule-node-timing-attack¶

rules_lgpl_javascript_crypto_rule-node-tls-reject¶

rules_lgpl_javascript_crypto_rule-node-weak-crypto¶

rules_lgpl_javascript_database_rule-sequelize-tls¶

rules_lgpl_javascript_dos_rule-layer7-object-dos¶

rules_lgpl_javascript_dos_rule-regex-dos¶

rules_lgpl_javascript_electronjs_rule-electron-blink-integration¶

rules_lgpl_javascript_electronjs_rule-electron-context-isolation¶

rules_lgpl_javascript_electronjs_rule-electron-nodejs-integration¶

rules_lgpl_javascript_headers_rule-cookie-session-no-httponly¶

rules_lgpl_javascript_headers_rule-cookie-session-no-samesite¶

rules_lgpl_javascript_headers_rule-cookie-session-no-secure¶

rules_lgpl_javascript_headers_rule-express-cors¶

rules_lgpl_javascript_headers_rule-generic-cors¶

rules_lgpl_javascript_headers_rule-header-xss-generic¶

rules_lgpl_javascript_headers_rule-header-xss-lusca¶

rules_lgpl_javascript_headers_rule-helmet-feature-disabled¶

rules_lgpl_javascript_headers_rule-host-header-injection¶

rules_lgpl_javascript_ssrf_rule-wkhtmltoimage-ssrf¶

rules_lgpl_javascript_traversal_rule-admzip-path-overwrite¶

rules_lgpl_javascript_traversal_rule-express-lfr¶

rules_lgpl_javascript_traversal_rule-express-lfr-warning¶

rules_lgpl_javascript_traversal_rule-generic-path-traversal¶

règles_lgpl_javascript_règle-de-parcours-join-résoudre-chemin-traversée¶

règles_lgpl_javascript_règle-parcours-tar-chemin-surcharge¶

règles_lgpl_règle_traversée_javascript-chemin-zip-surcharge¶

rules_lgpl_javascript_headers_rule-cookie-session-default¶

règles_lgpl_javascript_headers_rule-cookie-session-no-domain¶

rules_lgpl_javascript_headers_rule-cookie-session-no-maxage¶

règles_lgpl_javascript_headers_rule-cookie-session-no-path¶

rules_lgpl_javascript_xss_rule-xss-disable-mustache-escape¶