‫Ainsi, tout ce que nous avons fait dans cette
‫section jusqu'à présent était de sécuriser
‫au mieux toutes les applications et les données de nos utilisateurs.
‫Et j'ai parlé de beaucoup de choses que
‫nous pouvons faire pour y parvenir.
‫Mais toutes ces informations étaient en quelque
‫sorte éparpillées tout au long de ces conférences.
‫J'ai donc décidé de créer ce résumé rapide avec
‫de nombreuses bonnes pratiques que nous avons déjà mises en œuvre et
‫que nous allons encore mettre en œuvre dans
‫le reste de cette section.
‫Parce que la sécurité est extrêmement importante,
‫mais malheureusement, de nombreux cours ne l'abordent pas assez.
‫Maintenant, je ne tourne
‫pas non plus ce Node. js dans un cours de sécurité.
‫Il existe de meilleurs cours et des experts pour cela.
‫Mais je vais vous montrer quelques
‫choses que vous pouvez faire pour sécuriser correctement vos applications et vos données.
‫Et je vais examiner quelques attaques
‫courantes et donner quelques suggestions pour les empêcher.
‫Et tout d'abord, nous avons l'événement d'une base de données compromise,
‫ce qui signifie qu'un attaquant a eu accès à notre base de données.
‫Bien sûr, il s'agit d'un problème extrêmement grave, mais pour
‫éviter des problèmes encore plus graves, nous devons
‫toujours crypter les mots de passe et les jetons de réinitialisation de mot de
‫passe, comme nous l'avons fait dans les vidéos de cette section.
‫De cette façon, l'attaquant ne peut pas au
‫moins voler les mots de passe de nos utilisateurs et ne peut pas non plus les réinitialiser.
‫Maintenant, à propos de la prévention des attaques,
‫parlons de l'attaque par force brute où
‫l'attaquant essaie essentiellement de deviner un mot de passe en
‫essayant des millions et des millions de mots de passe aléatoires
‫jusqu'à ce qu'il trouve le bon.
‫Et ce que nous pouvons faire, c'est ralentir la demande de connexion.
‫Et le package bcrypt
‫que nous utilisons fait exactement cela.
‫Une autre stratégie consiste à mettre en œuvre une limitation
‫du débit, qui limite le
‫nombre de requêtes provenant d'une seule IP.
‫Et celui-ci, nous allons
‫l'implémenter dans l'une des prochaines vidéos.
‫De plus, une bonne stratégie consiste à implémenter
‫un nombre maximum de tentatives de connexion pour chaque utilisateur.
‫Par exemple, nous pourrions
‫faire en sorte qu'après 10 tentatives infructueuses,
‫l'utilisateur doive attendre une heure avant de pouvoir réessayer.
‫Maintenant, je ne vais pas
‫implémenter cette fonctionnalité dans cette section,
‫mais n'hésitez pas à l'expérimenter par vous-même.
‫C'est probablement une expérience d'apprentissage vraiment cool de coder cela
‫par vous-même, et ce n'est
‫en fait pas si difficile.
‫D'accord.
‫Ensuite, il y a l'attaque de script inter-sites,
‫où l'attaquant essaie
‫d'injecter des scripts dans notre page pour exécuter son code malveillant.
‫Du côté des clients, cela est particulièrement dangereux car
‫cela permet à l'attaquant de lire le stockage local, c'est la
‫raison pour laquelle nous
‫ne devrions jamais stocker le jeton Web JSON dans le stockage local.
‫Au lieu de cela, il doit être stocké dans un cookie HTTP uniquement qui fait
‫en sorte que le navigateur ne
‫peut que recevoir et envoyer le cookie mais ne
‫peut pas y accéder ou le modifier de quelque manière que ce soit.
‫Et donc, cela rend alors impossible pour tout
‫attaquant de voler le jeton Web JSON qui est stocké dans le cookie.
‫Encore une fois, nous mettons cela en œuvre dans une seconde.
‫Maintenant, du côté du backend, afin d'empêcher les attaques XSS, nous devons
‫nettoyer les données d'entrée des
‫utilisateurs et définir des en-têtes HTTP spéciaux
‫qui rendent ces attaques un peu plus difficiles à réaliser.
‫Et Express ne vient pas avec ces meilleures pratiques
‫prêtes à l'emploi, nous allons donc utiliser un middleware
‫pour définir tous ces en-têtes spéciaux.
‫Ensuite, nous avons des attaques par déni de service.
‫Et peut-être en avez-vous entendu parler.
‫Cela se produit lorsque
‫l'attaquant envoie tellement de requêtes à un serveur qu'il
‫tombe en panne et que l'application devient indisponible.
‫Encore une fois, la mise en œuvre de
‫la limitation du débit est une bonne solution pour cela.
‫De plus, nous devrions limiter la quantité de
‫données pouvant être envoyées dans un corps dans un message ou une demande de correctif.
‫Et aussi, nous devrions éviter d'utiliser
‫des expressions régulières soi-disant mauvaises pour être dans notre code.
‫Et ce ne sont que des
‫expressions régulières qui prennent un temps exponentiel à s'exécuter pour des entrées
‫non correspondantes et elles peuvent être exploitées pour faire tomber toute notre application.
‫Bon, maintenant, nous avons l'attaque par injection de requête NoSQL.
‫Et l'injection de requête se produit lorsqu'un attaquant,
‫au lieu de saisir des données valides, injecte une requête afin
‫de créer des expressions de
‫requête qui vont se traduire en vrai.
‫Par exemple, pour être connecté même sans
‫fournir un nom d'utilisateur ou un mot de passe valide.
‫C'est un peu complexe
‫et vous devriez certainement le rechercher sur Google pour en savoir plus.
‫Mais ce que vous devez savoir, c'est que l'utilisation
‫de Mongoose est en fait
‫une très bonne stratégie pour empêcher ce type
‫d'attaques, car un bon schéma oblige chaque valeur à
‫avoir un onglet de données bien défini.
‫Ce qui rend alors
‫effectivement ce type d'attaque très difficile à exécuter.
‫Cependant, c'est toujours une bonne idée
‫de toujours désinfecter les données d'entrée, juste pour être sûr.
‫Et nous nous en occuperons un peu plus tard.
‫Très bien, et maintenant
‫pour terminer, j'ai juste quelques bonnes pratiques et
‫suggestions sur la façon d'améliorer les
‫mécanismes d'authentification et d'autorisation que nous avons mis en place.
‫Ainsi, la première chose
‫que je dois répéter encore et
‫encore est que dans une application de
‫production, toutes les communications entre le serveur et
‫le client doivent se faire via HTTPS.
‫Sinon, n'importe qui peut écouter la conversation et
‫voler notre jeton Web JSON.
‫Ensuite, créez toujours des jetons de mot de passe aléatoires.
‫Non généré à partir de dates ou quelque chose comme ça.
‫Parce qu'il s'agit effectivement de mots de
‫passe, ils doivent donc être traités comme tels.
‫De plus, donnez-leur toujours des dates d'expiration, tout
‫comme nous l'avons mis en œuvre.
‫D'accord?
‫Et nous avons également implémenté qu'un certain jeton Web JSON
‫n'est plus valide une fois que l'utilisateur a modifié son mot de passe.
‫Ainsi, nous révoquons essentiellement le jeton
‫dès que l'utilisateur modifie le mot de passe.
‫Ce qui a beaucoup de sens, mais encore
‫une fois, de nombreux tutoriels ne le font tout simplement pas.
‫Une autre chose importante est de ne jamais
‫valider un fichier de configuration, comme pour les variables d'environnement, dans
‫un contrôle de version comme Git.
‫En fait, ne le téléchargez nulle part
‫car ce fichier
‫contient les données les plus sensibles de toute l'application.
‫Par exemple, si quelqu'un a accès
‫à votre secret de
‫jeton Web JSON, l'ensemble de votre processus d'authentification est compromis.
‫D'accord, et maintenant juste un petit détail est de ne pas
‫envoyer l'erreur entière au
‫client chaque fois qu'il y a une erreur.
‫Ainsi, des éléments tels que la trace de la pile pourraient donner
‫à l'attaquant des informations précieuses sur votre système, et
‫donc, bien sûr, nous ne le voulons pas.
‫Ensuite, nous pouvons utiliser le package csurf
‫pour lutter contre un type d'attaque appelé Cross-Site Request Forgery, qui est une
‫attaque qui oblige un utilisateur à
‫exécuter des actions indésirables sur une application Web dans laquelle
‫il est actuellement connecté.
‫Nous n'allons pas le faire dans cette section, cependant.
‫Mais je voulais quand même le mentionner ici.
‫Ensuite, nous pourrions exiger que
‫l'utilisateur se ré-authentifie avant d'effectuer une action de grande valeur.
‫Par exemple, effectuer un paiement ou supprimer quelque chose.
‫Encore une fois, ce n'est qu'une suggestion que
‫vous pouvez essayer par vous-même.
‫Une autre fonctionnalité intéressante que vous pouvez
‫implémenter est une liste noire de jetons non fiables.
‫Ainsi, nous savons déjà qu'il
‫n'y a pas vraiment de moyen de déconnecter les utilisateurs
‫de l'application s'ils montrent une activité malveillante.
‫Mais ce que nous pouvons faire, c'est créer une liste de jetons
‫non fiables qui sont ensuite validés à chaque demande.
‫Et ensuite, une fonctionnalité que nous aurions pu implémenter
‫consiste à confirmer l'adresse e-mail après la création d'un compte.
‫Donc, essentiellement en envoyant un lien vers l'e-mail de
‫l'utilisateur, comme le font de nombreuses applications réelles.
‫Mais je voulais juste garder les choses simples ici,
‫c'est pourquoi je ne l'ai pas fait ici.
‫Mais n'hésitez pas à l'implémenter vous-même si
‫vous en avez envie.
‫Maintenant, une grande fonctionnalité dont disposent de
‫nombreuses applications est le concept de jetons d'actualisation.
‫Qui sont essentiellement à retenir des utilisateurs.
‫Donc, pour les garder connectés pour
‫toujours ou jusqu'à ce qu'ils choisissent de se déconnecter.
‫Notre implémentation actuelle fait
‫en sorte que l'utilisateur doit se reconnecter
‫après l'expiration du jeton Web JSON.
‫Mais, avec les jetons d'actualisation, ce n'est plus nécessaire.
‫Et c'est un peu complexe à mettre en œuvre et donc,
‫c'est une fonctionnalité pour une autre fois.
‫Et enfin, le
‫dernier que nous aurions pu implémenter est l'authentification à
‫deux facteurs, que vous connaissez certainement.
‫Fondamentalement, avec l'authentification à deux facteurs,
‫après s'être connecté à l'application, l'utilisateur
‫doit effectuer
‫une deuxième action pour être vraiment authentifié.
‫Et généralement, il s'agit d'insérer un
‫code envoyé par SMS sur un téléphone portable.
‫Donc, ce sont beaucoup de fonctionnalités
‫que notre authentification pourrait avoir.
‫Et si vous voulez que je les
‫implémente, faites-le moi savoir dans la section Q&R.
‫Et, s'il y a beaucoup de demande pour l'un d'entre eux,
‫alors je vais vous montrer comment cela fonctionne.
‫D'accord, mais encore une fois, je ne voulais pas
‫activer ce Node. js en
‫un cours complet sur la sécurité et l'authentification.
‫Et juste pour finir, quelque chose que nous allons mettre en œuvre
‫dans le reste de la
‫section est d'éviter la pollution des paramètres.
‫Par exemple, essayez simplement d'insérer deux paramètres de champ dans la
‫chaîne de requête qui recherche toutes les visites.
‫Et si vous faites cela, vous constaterez qu'il
‫y aura une erreur
‫car notre application n'est pas préparée pour cela.
‫Et donc, les attaquants essaient d'utiliser ce genre de faiblesses pour faire
‫planter des applications, ce qui, bien sûr, n'est pas bon.
‫Et donc, nous devons corriger cela.
‫D'accord, cela s'est avéré beaucoup plus long que ce à quoi je m'attendais.
‫Et il y a des cours entiers sur la sécurité
‫si vous êtes vraiment dans la sécurité.
‫Très bien, mais je m'arrête
‫là, et donc, passons maintenant directement au suivant.