[signet] 23 recommandations pour protéger les applications Node.js

De nos jours, les services Web sont constamment exposés à une variété d'attaques. Par conséquent, la sécurité est quelque chose à retenir à toutes les étapes du cycle de vie du projet. Les auteurs du matériel, dont nous publions la traduction aujourd'hui, maintiennent un référentiel sur GitHub contenant environ 80 recommandations pour sécuriser les applications s'exécutant sur la plate-forme Node.js. Ce matériel, basé sur de nombreuses publications de sécurité, contient plus de deux douzaines de recommandations concernant Node.js et quelques conseils généraux. De plus, ce matériel couvre les 10 principales vulnérabilités de la liste du projet OWASP.

1. Utilisez les règles du linter, visant à vérifier la sécurité du code

Recommandations

Pendant le développement, utilisez un plug-in de sécurité pour le linter, tel que eslint-plugin-security . Cela vous permet d'identifier très tôt les vulnérabilités et les problèmes de sécurité - au moment de la rédaction du code approprié. Cette approche permet de détecter les faiblesses de la sécurité du programme. Parmi eux, l'utilisation de la commande eval , l'invocation de processus enfants, l'importation de modules avec le transfert à la commande correspondante de quelque chose de différent d'un littéral de chaîne (par exemple, une certaine chaîne formée sur la base de données transmises au serveur par l'utilisateur).

→ Voici quelques informations utiles sur les règles de linter

Adam Baldwin dit ce qui suit sur le peluchage: «Linter ne devrait pas être juste un outil qui suit méticuleusement les règles concernant le nombre d'espaces utilisés, les points-virgules et l'utilisation de la commande eval. ESLint fournit au développeur une plate-forme puissante qui peut détecter et éliminer un large éventail de modèles potentiellement dangereux dans le code. Nous parlons, par exemple, d'expressions régulières, de la vérification des entrées utilisateur, etc. Je crois que le linter offre aux développeurs qui sont préoccupés par les problèmes de sécurité un nouvel outil puissant qui mérite d'être étudié. »

Problèmes possibles

Ce qui ressemble à une faille de sécurité mineure pendant le développement devient une grave vulnérabilité dans la production. De plus, si tous les développeurs de projets ne respectent pas des règles de sécurité uniformes lorsqu'ils travaillent avec du code, cela peut entraîner des vulnérabilités dans celui-ci ou, par exemple, la pénétration de données confidentielles dans des référentiels publics.

2. Limitez le nombre de demandes de serveur simultanées

Recommandations

Les attaques DoS sont très populaires parmi les cybercriminels et elles sont relativement faciles à réaliser. Vous pouvez implémenter un système pour limiter le nombre de demandes à une application à l'aide d'un service externe, tel qu'un équilibreur de charge cloud, un pare-feu cloud, un serveur nginx ou, pour les petites applications qui ne sont pas critiques, utiliser un middleware pour limiter le nombre de demandes comme le débit express -limit .

→ Voici le matériel sur la mise en place du système de limitation de la fréquence des requêtes au serveur

Problèmes possibles

Une application qui ne fournit pas de système pour limiter le nombre de requêtes simultanées peut être attaquée, ce qui entraînera son échec. Cela se traduit par le fait que les utilisateurs d'une telle application auront soit des difficultés à travailler avec elle, soit ne pourront pas du tout interagir avec elle.

3. Supprimez les informations confidentielles des fichiers de configuration ou chiffrez-les

Recommandations

Ne stockez jamais de données sensibles en texte brut dans des fichiers de configuration ou dans du code. Utilisez plutôt des systèmes de gestion des données sensibles tels que les produits Vault ou les systèmes Kubernetes / Docker Secrets, ou utilisez des variables d'environnement pour stocker ces données. Les données confidentielles stockées dans le système de contrôle de version doivent être cryptées, des mesures doivent être prises pour leur stockage et leur utilisation en toute sécurité. Parmi ces mesures figurent l'utilisation de clés dynamiques, l'utilisation de dates d'expiration de mot de passe, des audits de sécurité, etc. Utilisez des systèmes pour vérifier le code avant de le valider ou avant de l'envoyer au référentiel pour éviter l'envoi accidentel de données sensibles au référentiel public.

→ Voici des informations sur la gestion des données sensibles

Problèmes possibles

Même si le code est stocké dans un référentiel fermé, un jour, par erreur, il peut devenir accessible au public. À ce stade, toutes les données confidentielles qui y sont stockées deviendront du domaine public. Par conséquent, un accès tiers au référentiel avec le code les conduira par inadvertance à accéder aux systèmes qui lui sont associés (bases de données, API, services, etc.).

4. Empêchez les vulnérabilités d'injection de code

Recommandations

Afin d'empêcher les injections SQL / NoSQL et autres attaques similaires, utilisez toujours des bibliothèques ORM / ODM ou des mécanismes SGBD visant à nettoyer les données ou à prendre en charge des requêtes paramétrées nommées ou indexées et à vérifier ce qui vient de l'utilisateur. N'utilisez jamais, pour incorporer certaines valeurs dans des textes de requête, uniquement des chaînes JavaScript de modèle ou une concaténation de chaînes, car cette approche ouvre votre application à un large éventail de vulnérabilités. Toutes les bibliothèques respectables pour Node.js utilisées pour travailler avec des données (par exemple, Sequelize , Knex , mangouste ) contiennent une protection intégrée contre les attaques par injection de code.

→ Voici le matériel sur la prévention des injections à l'aide des bibliothèques ORM / ODM

Problèmes possibles

L'utilisation de données non vérifiées et non nettoyées reçues de l'utilisateur dans les requêtes peut entraîner une attaque en introduisant un opérateur lors de l'utilisation d'une base de données NoSQL telle que MongoDB. Si vous n'utilisez pas de système de nettoyage de données ou de bibliothèque ORM lorsque vous travaillez avec une base de données SQL, cela entraînera la possibilité d'une attaque par injection SQL, ce qui crée un énorme trou de sécurité dans l'application.

5. Évitez les attaques DoS en définissant explicitement les conditions de fin anormale du processus

Recommandations

Le processus Node se bloque lorsqu'une erreur non gérée se produit. Mais dans de nombreuses recommandations reflétant les meilleures pratiques pour Node, il est recommandé de mettre fin aux processus même lorsqu'une erreur a été interceptée et traitée. Express, par exemple, se bloque lorsqu'une erreur asynchrone se produit - à moins que les routes ne soient enveloppées dans catch expressions catch . Ce fait offre aux attaquants une opportunité très intéressante. Après avoir découvert que lorsqu'une certaine demande arrive, le processus se bloque, ils commencent à lui envoyer de telles demandes. Il n'y a aucune recommandation qui résoudrait ce problème d'un seul coup, cependant, certaines astuces peuvent l'atténuer. Ainsi, à la fin du processus en raison d'une erreur non gérée, vous devez en informer l'administrateur, en accordant à cette notification la plus haute priorité. Il est nécessaire de vérifier ce qui vient au processus dans les demandes et d'éviter les situations de fin anormale du processus en raison de demandes qui, accidentellement ou intentionnellement, sont mal formées. Toutes les routes doivent être enveloppées dans catch expressions catch et le système doit être configuré de sorte que, si la demande était la cause de l'erreur, le processus ne se bloque pas (contrairement à ce qui se passe au niveau de l'application globale).

Problèmes possibles

Analysons la situation suivante. Il existe de nombreuses applications Node.js. Que se passe-t-il si nous commençons à leur envoyer des requêtes POST avec JSON vide comme corps de requête? Cela entraînera le blocage de bon nombre de ces applications.

Maintenant, si nous devions jouer le rôle de cybercriminels, pour que nous empêchions les applications de se bloquer, il suffirait de continuer à leur envoyer des demandes similaires.

6. Configurer les en-têtes de réponse HTTP pour augmenter la sécurité du projet

Recommandations

Une application doit utiliser des en-têtes HTTP orientés sécurité pour empêcher les attaquants de recourir à des techniques d'attaque courantes telles que le scriptage intersite (XSS), le détournement de clics et autres. La personnalisation des en-têtes est facile en utilisant des modules spéciaux tels que le casque .

→ Voici des informations sur l'utilisation des en-têtes sûrs

Problèmes possibles

Si des en-têtes HTTP sécurisés ne sont pas utilisés, les attaquants pourront effectuer des attaques contre les utilisateurs de vos applications, ce qui entraîne d'énormes vulnérabilités.

7. En continu, automatiquement, vérifiez vos projets pour l'utilisation des dépendances vulnérables en eux

Recommandations

Dans l'écosystème NPM, les projets avec de nombreuses dépendances sont très courants. Les dépendances doivent toujours être contrôlées, compte tenu de la découverte de nouvelles vulnérabilités. Utilisez des outils tels que npm audit , nsp ou snyk pour détecter, surveiller et corriger les dépendances vulnérables. Intégrez ces outils dans votre système d'intégration continue. Cela vous permettra de détecter les dépendances vulnérables avant leur mise en production.

→ Voici des informations sur la sécurité des dépendances du projet

Problèmes possibles

Un attaquant peut déterminer le framework web utilisé dans le projet et mener des attaques contre toutes les vulnérabilités connues.

8. Essayez de ne pas utiliser le module cryptographique Node.js standard pour le traitement des mots de passe, utilisez plutôt Bcrypt

Recommandations

Les mots de passe ou autres données sensibles (clés API, par exemple) doivent être stockés en les traitant avec des fonctions cryptographiques utilisant du «sel», comme Bcrypt. Il vaut la peine d'utiliser exactement quelque chose de similaire, et non le module de crypto Node.js standard pour des raisons de sécurité et de performances.

→ Voici le matériel sur Bcrypt

Problèmes possibles

Les mots de passe ou certaines données confidentielles qui sont stockés sans l'application de mesures appropriées pour les protéger sont vulnérables aux attaques par force brute et aux attaques de dictionnaire, qui, par conséquent, conduisent à la divulgation de ces données.

9. Utilisez des systèmes d'échappement de caractères dans les données HTML, JS et CSS envoyées à l'utilisateur

Recommandations

Si certaines données sont envoyées au navigateur de l'utilisateur à partir d'une source non fiable, même si elles doivent simplement être affichées, ces données peuvent être un code qui peut être exécuté. Ceci est communément appelé script intersite (XSS). Vous pouvez réduire le risque que de telles attaques soient possibles en utilisant des bibliothèques spéciales qui traitent les données afin qu'elles ne puissent pas être exécutées. C'est ce qu'on appelle l'encodage ou le blindage des données.

→ Voici des informations sur le blindage de la sortie

Problèmes possibles

Si vous ne vous souciez pas du blindage des données, un attaquant peut, par exemple, enregistrer du code JavaScript malveillant dans votre base de données, qui peut être transmis aux clients inchangé et lancé.

10. Vérifiez les données JSON arrivant sur le serveur

Recommandations

Contrôlez le contenu des corps des demandes entrantes, en vérifiant si elles correspondent à ce que vous attendez de voir dans de telles demandes. Si la demande ne se présente pas comme prévu, arrêtez rapidement de la traiter. Afin d'éviter l'opération fastidieuse d'écriture du code de vérification des demandes pour chaque itinéraire, vous pouvez utiliser des outils JSON légers pour la validation des données, tels que jsonschema ou joi .

→ Voici le matériel sur la vérification des données JSON entrantes

Problèmes possibles

Si le serveur accepte les demandes cordialement sans les examiner minutieusement, cela augmente considérablement la surface d'attaque de l'application et incite les attaquants à essayer de trouver bon nombre d'entre elles qui conduisent à un «plantage» du système.

11. Maintenir les jetons JWT sur liste noire

Recommandations

Lorsque vous utilisez des jetons JWT (par exemple, si vous travaillez avec Passport.js ), par défaut, il n'existe aucun mécanisme standard pour révoquer les privilèges d'accès au système pour les jetons déjà émis. Même si vous constatez qu'un certain utilisateur fait quelque chose de manifestement anormal, vous n'avez aucun moyen, par le biais du mécanisme de jeton, de bloquer son accès au système, tant qu'il a un jeton valide. Ce problème peut être atténué en implémentant une liste noire de jetons non approuvés, dont la validation est effectuée à chaque demande.

→ Voici le matériel sur les jetons JWT sur liste noire

Problèmes possibles

Les jetons qui tombent entre de mauvaises mains peuvent être utilisés par un attaquant. Il pourra accéder à l'application et se faire passer pour un utilisateur ordinaire - le propriétaire du jeton.

12. Limitez le nombre de tentatives de connexion

Recommandations

Dans les applications basées sur express, pour se protéger contre les attaques par force brute et les attaques par dictionnaire, il vaut la peine d'utiliser le middleware approprié, comme express-brute . De même, vous devez protéger les itinéraires critiques tels que /admin ou /login . La protection doit être basée sur l'analyse des propriétés de la requête, telles que le nom d'utilisateur utilisé dans la requête ou d'autres identificateurs, tels que les paramètres du corps de la requête.

→ Voici le matériel sur la limitation du nombre de tentatives de connexion

Problèmes possibles

Si l'application ne limite pas le nombre de tentatives de connexion, l'attaquant peut envoyer automatiquement un nombre illimité de demandes de connexion à votre système, par exemple, en essayant d'accéder à un compte privilégié.

13. Exécutez Node.js en tant qu'utilisateur non root

Recommandations

Un scénario extrêmement courant est lorsque Node.js est exécuté en tant qu'utilisateur root avec des privilèges illimités. Par exemple, voici comment tout est configuré par défaut dans les conteneurs Docker. Il est recommandé de créer un utilisateur qui ne dispose pas des privilèges root et de l'intégrer dans l'image Docker ou de démarrer le processus au nom de cet utilisateur en appelant le conteneur avec l'indicateur -u username .

→ Voici le matériel sur le lancement de Node.js en tant qu'utilisateur non root

Problèmes possibles

Si Node.js est exécuté sous le compte d'utilisateur root, un attaquant qui a pu exécuter un script sur le serveur obtient des possibilités illimitées sur la machine locale. Disons qu'il peut modifier les paramètres iptable et rediriger le trafic vers son propre ordinateur.

14. Limitez la quantité de données transmises dans les demandes à l'aide d'un serveur proxy inverse ou d'un middleware

Recommandations

Plus la quantité de données dans le corps de la demande est grande, plus il est difficile pour un serveur à thread unique de traiter une telle demande. L'utilisation de requêtes volumineuses donne à un attaquant la possibilité d'inonder le serveur de travaux inutiles sans lui envoyer un grand nombre de requêtes (c'est-à-dire sans effectuer d'attaque DoS / DDoS). Vous pouvez réduire le risque de telles attaques en limitant la taille des corps des demandes entrantes sur un certain système de frontière (sur un pare-feu ou sur un équilibreur de charge), ou en configurant body-parser express pour recevoir uniquement les paquets contenant une petite quantité de données.

→ Voici des informations sur la limitation de la quantité de données transmises dans les requêtes

Problèmes possibles

Si vous ne limitez pas la quantité de données transmises dans les requêtes, un attaquant peut charger l'application en traitant des requêtes volumineuses. Pour le moment, il ne pourra pas résoudre les tâches pour lesquelles il est conçu. Cela entraîne de mauvaises performances et rend l'application vulnérable aux attaques DoS.

15. Évitez d'utiliser la fonction eval en JavaScript

Recommandations

La fonction eval est mauvaise car elle vous permet d'exécuter du code JS arbitraire qui lui est transmis pendant l'exécution du programme. De plus, ce n'est pas seulement que ce code peut ralentir l'application. Cette fonction pose un grave risque pour la sécurité, car du code JS malveillant envoyé au serveur par un attaquant pourrait y pénétrer.

En outre, vous devez éviter le new Function constructeur new Function . Les fonctions setTimeout et setInterval n'ont jamais besoin de transmettre du code JS généré dynamiquement.

→ Voici les informations sur eval

Problèmes possibles

Si quelqu'un trouve un moyen de transférer du code JS malveillant, sous forme de texte, d'une fonction eval ou d'un autre moteur JS similaire, il aura un accès complet à la page, à tout ce qui peut être fait en utilisant JavaScript. Cette vulnérabilité est souvent associée aux attaques XSS.

16. Ne surchargez pas les applications Node.js à thread unique avec des expressions régulières malveillantes

Recommandations

Les expressions régulières, bien que pratiques, constituent une menace pour les applications JavaScript en général, et en particulier pour la plate-forme Node.js. Le traitement avec une expression régulière de ce qui vient de l'utilisateur peut créer une énorme charge sur le processeur. Par exemple, le traitement des expressions régulières peut être si inefficace que la vérification de dix mots peut bloquer le cycle des événements pendant plusieurs secondes et surcharger le processeur. Par conséquent, il est préférable d'utiliser des packages tiers pour vérifier les données de chaîne, telles que validator.js , au lieu d'écrire vos propres expressions régulières. Vous pouvez utiliser le package safe-regex pour détecter les modèles regex vulnérables.

→ Voici le matériel d'expression rationnelle anti-malware

Problèmes possibles

Les expressions régulières mal écrites peuvent être sujettes à un type particulier d'attaques DoS, au cours desquelles la boucle d'événements est complètement bloquée. Par exemple, en novembre 2017, il a été découvert que le package de moment populaire était vulnérable à de telles attaques.

17. Évitez de charger des modules à l'aide de variables

Recommandations

Évitez d'importer des fichiers dont le chemin est spécifié en tant que paramètre, en fonction des considérations selon lesquelles ce paramètre peut être défini en fonction des données de l'utilisateur. Cette règle peut être étendue pour inclure ici et, en général, l'accès aux fichiers (à l'aide de fs.readFile() ) et l'accès à toute autre ressource importante à l'aide des paramètres reçus de l'utilisateur. L'utilisation de eslint-plugin-security permet de détecter très tôt de tels modèles dangereux.

→ Voici des informations sur le chargement sécurisé des modules

Problèmes possibles

Les données envoyées au serveur par un attaquant peuvent se trouver dans les paramètres chargés d'importer certains fichiers, parmi lesquels peut être un fichier malveillant qui a été précédemment téléchargé sur le serveur. Ces données peuvent également être utilisées pour accéder aux fichiers système déjà sur l'ordinateur.

18.

, (, ), «», . , ( cluster.fork() ), npm-, .

→

, , . — , , , .

19.

, , . , , , . child_process.execFile , , , , , .

→ ,

, , , , .

20.

express, , . , , , Error ( ). , , , - , .

→

, , , , , , .

21. npm Yarn

, -, (MFA, multi-factor authentication). npm Yarn , . , , , . , . , , npm, .

, ? eslint, .

22. ,

- . , — , - . , , X-Powered-By , , . , ( , , Node.js express).

→ -

- . , , -, — . .

23.

, . — , Node.js. , OWASP .

• root- .
• ( SSH-).
• , , , . OWASP, .
• , . , .
  
• OAuth, OpenID, . Basic Authentication.
  
• . , ( — ), X , Y .
  
• — , — . , .
  
• , , . ( — GitHub, AWS, Jenkins, ).
  

Résumé

. , Node.js-.

Chers lecteurs! -, ?