﻿1
00:00:01,300 --> 00:00:04,156
‫Ainsi, tout ce que nous avons fait dans cette

2
00:00:04,156 --> 00:00:06,514
‫section jusqu'à présent était de sécuriser

3
00:00:06,514 --> 00:00:10,320
‫au mieux toutes les applications et les données de nos utilisateurs.

4
00:00:10,320 --> 00:00:12,290
‫Et j'ai parlé de beaucoup de choses que

5
00:00:12,290 --> 00:00:14,170
‫nous pouvons faire pour y parvenir.

6
00:00:14,170 --> 00:00:16,430
‫Mais toutes ces informations étaient en quelque

7
00:00:16,430 --> 00:00:18,860
‫sorte éparpillées tout au long de ces conférences.

8
00:00:18,860 --> 00:00:21,311
‫J'ai donc décidé de créer ce résumé rapide avec

9
00:00:21,311 --> 00:00:24,717
‫de nombreuses bonnes pratiques que nous avons déjà mises en œuvre et

10
00:00:24,717 --> 00:00:26,960
‫que nous allons encore mettre en œuvre dans

11
00:00:26,960 --> 00:00:28,860
‫le reste de cette section.

12
00:00:28,860 --> 00:00:32,100
‫Parce que la sécurité est extrêmement importante,

13
00:00:32,100 --> 00:00:36,010
‫mais malheureusement, de nombreux cours ne l'abordent pas assez.

14
00:00:36,010 --> 00:00:37,490
‫Maintenant, je ne tourne

15
00:00:37,490 --> 00:00:40,660
‫pas non plus ce Node. js dans un cours de sécurité.

16
00:00:40,660 --> 00:00:44,170
‫Il existe de meilleurs cours et des experts pour cela.

17
00:00:44,170 --> 00:00:46,490
‫Mais je vais vous montrer quelques

18
00:00:46,490 --> 00:00:51,490
‫choses que vous pouvez faire pour sécuriser correctement vos applications et vos données.

19
00:00:51,650 --> 00:00:54,200
‫Et je vais examiner quelques attaques

20
00:00:54,200 --> 00:00:57,010
‫courantes et donner quelques suggestions pour les empêcher.

21
00:00:57,010 --> 00:01:00,780
‫Et tout d'abord, nous avons l'événement d'une base de données compromise,

22
00:01:00,780 --> 00:01:04,980
‫ce qui signifie qu'un attaquant a eu accès à notre base de données.

23
00:01:04,980 --> 00:01:07,970
‫Bien sûr, il s'agit d'un problème extrêmement grave, mais pour

24
00:01:07,970 --> 00:01:10,430
‫éviter des problèmes encore plus graves, nous devons

25
00:01:10,430 --> 00:01:14,550
‫toujours crypter les mots de passe et les jetons de réinitialisation de mot de

26
00:01:14,550 --> 00:01:17,660
‫passe, comme nous l'avons fait dans les vidéos de cette section.

27
00:01:17,660 --> 00:01:19,800
‫De cette façon, l'attaquant ne peut pas au

28
00:01:19,800 --> 00:01:24,320
‫moins voler les mots de passe de nos utilisateurs et ne peut pas non plus les réinitialiser.

29
00:01:24,320 --> 00:01:26,720
‫Maintenant, à propos de la prévention des attaques,

30
00:01:26,720 --> 00:01:29,110
‫parlons de l'attaque par force brute où

31
00:01:29,110 --> 00:01:32,290
‫l'attaquant essaie essentiellement de deviner un mot de passe en

32
00:01:32,290 --> 00:01:35,660
‫essayant des millions et des millions de mots de passe aléatoires

33
00:01:35,660 --> 00:01:37,850
‫jusqu'à ce qu'il trouve le bon.

34
00:01:37,850 --> 00:01:42,160
‫Et ce que nous pouvons faire, c'est ralentir la demande de connexion.

35
00:01:42,160 --> 00:01:44,586
‫Et le package bcrypt

36
00:01:44,586 --> 00:01:47,020
‫que nous utilisons fait exactement cela.

37
00:01:47,020 --> 00:01:50,180
‫Une autre stratégie consiste à mettre en œuvre une limitation

38
00:01:50,180 --> 00:01:52,340
‫du débit, qui limite le

39
00:01:52,340 --> 00:01:54,640
‫nombre de requêtes provenant d'une seule IP.

40
00:01:54,640 --> 00:01:56,330
‫Et celui-ci, nous allons

41
00:01:56,330 --> 00:01:58,460
‫l'implémenter dans l'une des prochaines vidéos.

42
00:01:58,460 --> 00:02:01,690
‫De plus, une bonne stratégie consiste à implémenter

43
00:02:01,690 --> 00:02:05,470
‫un nombre maximum de tentatives de connexion pour chaque utilisateur.

44
00:02:05,470 --> 00:02:07,660
‫Par exemple, nous pourrions

45
00:02:07,660 --> 00:02:10,540
‫faire en sorte qu'après 10 tentatives infructueuses,

46
00:02:10,540 --> 00:02:14,020
‫l'utilisateur doive attendre une heure avant de pouvoir réessayer.

47
00:02:14,020 --> 00:02:16,360
‫Maintenant, je ne vais pas

48
00:02:16,360 --> 00:02:18,760
‫implémenter cette fonctionnalité dans cette section,

49
00:02:18,760 --> 00:02:21,340
‫mais n'hésitez pas à l'expérimenter par vous-même.

50
00:02:21,340 --> 00:02:24,350
‫C'est probablement une expérience d'apprentissage vraiment cool de coder cela

51
00:02:24,350 --> 00:02:26,120
‫par vous-même, et ce n'est

52
00:02:26,120 --> 00:02:27,890
‫en fait pas si difficile.

53
00:02:27,890 --> 00:02:29,210
‫D'accord.

54
00:02:29,210 --> 00:02:32,580
‫Ensuite, il y a l'attaque de script inter-sites,

55
00:02:32,580 --> 00:02:34,020
‫où l'attaquant essaie

56
00:02:34,020 --> 00:02:38,430
‫d'injecter des scripts dans notre page pour exécuter son code malveillant.

57
00:02:38,430 --> 00:02:41,280
‫Du côté des clients, cela est particulièrement dangereux car

58
00:02:41,280 --> 00:02:44,810
‫cela permet à l'attaquant de lire le stockage local, c'est la

59
00:02:44,810 --> 00:02:46,500
‫raison pour laquelle nous

60
00:02:46,500 --> 00:02:50,360
‫ne devrions jamais stocker le jeton Web JSON dans le stockage local.

61
00:02:50,360 --> 00:02:54,110
‫Au lieu de cela, il doit être stocké dans un cookie HTTP uniquement qui fait

62
00:02:54,110 --> 00:02:55,950
‫en sorte que le navigateur ne

63
00:02:55,950 --> 00:02:58,110
‫peut que recevoir et envoyer le cookie mais ne

64
00:02:58,110 --> 00:03:01,400
‫peut pas y accéder ou le modifier de quelque manière que ce soit.

65
00:03:01,400 --> 00:03:04,360
‫Et donc, cela rend alors impossible pour tout

66
00:03:04,360 --> 00:03:08,460
‫attaquant de voler le jeton Web JSON qui est stocké dans le cookie.

67
00:03:08,460 --> 00:03:11,590
‫Encore une fois, nous mettons cela en œuvre dans une seconde.

68
00:03:11,590 --> 00:03:15,780
‫Maintenant, du côté du backend, afin d'empêcher les attaques XSS, nous devons

69
00:03:15,780 --> 00:03:18,170
‫nettoyer les données d'entrée des

70
00:03:18,170 --> 00:03:20,660
‫utilisateurs et définir des en-têtes HTTP spéciaux

71
00:03:20,660 --> 00:03:24,470
‫qui rendent ces attaques un peu plus difficiles à réaliser.

72
00:03:24,470 --> 00:03:27,040
‫Et Express ne vient pas avec ces meilleures pratiques

73
00:03:27,040 --> 00:03:29,560
‫prêtes à l'emploi, nous allons donc utiliser un middleware

74
00:03:29,560 --> 00:03:31,713
‫pour définir tous ces en-têtes spéciaux.

75
00:03:32,710 --> 00:03:35,620
‫Ensuite, nous avons des attaques par déni de service.

76
00:03:35,620 --> 00:03:37,510
‫Et peut-être en avez-vous entendu parler.

77
00:03:37,510 --> 00:03:39,330
‫Cela se produit lorsque

78
00:03:39,330 --> 00:03:42,600
‫l'attaquant envoie tellement de requêtes à un serveur qu'il

79
00:03:42,600 --> 00:03:45,450
‫tombe en panne et que l'application devient indisponible.

80
00:03:45,450 --> 00:03:47,470
‫Encore une fois, la mise en œuvre de

81
00:03:47,470 --> 00:03:49,530
‫la limitation du débit est une bonne solution pour cela.

82
00:03:49,530 --> 00:03:51,970
‫De plus, nous devrions limiter la quantité de

83
00:03:51,970 --> 00:03:55,810
‫données pouvant être envoyées dans un corps dans un message ou une demande de correctif.

84
00:03:55,810 --> 00:03:57,950
‫Et aussi, nous devrions éviter d'utiliser

85
00:03:57,950 --> 00:04:01,110
‫des expressions régulières soi-disant mauvaises pour être dans notre code.

86
00:04:01,110 --> 00:04:03,590
‫Et ce ne sont que des

87
00:04:03,590 --> 00:04:07,550
‫expressions régulières qui prennent un temps exponentiel à s'exécuter pour des entrées

88
00:04:07,550 --> 00:04:11,680
‫non correspondantes et elles peuvent être exploitées pour faire tomber toute notre application.

89
00:04:11,680 --> 00:04:15,960
‫Bon, maintenant, nous avons l'attaque par injection de requête NoSQL.

90
00:04:15,960 --> 00:04:18,510
‫Et l'injection de requête se produit lorsqu'un attaquant,

91
00:04:18,510 --> 00:04:22,240
‫au lieu de saisir des données valides, injecte une requête afin

92
00:04:22,240 --> 00:04:24,330
‫de créer des expressions de

93
00:04:24,330 --> 00:04:26,600
‫requête qui vont se traduire en vrai.

94
00:04:26,600 --> 00:04:28,920
‫Par exemple, pour être connecté même sans

95
00:04:28,920 --> 00:04:32,120
‫fournir un nom d'utilisateur ou un mot de passe valide.

96
00:04:32,120 --> 00:04:33,380
‫C'est un peu complexe

97
00:04:33,380 --> 00:04:36,330
‫et vous devriez certainement le rechercher sur Google pour en savoir plus.

98
00:04:36,330 --> 00:04:38,940
‫Mais ce que vous devez savoir, c'est que l'utilisation

99
00:04:38,940 --> 00:04:40,810
‫de Mongoose est en fait

100
00:04:40,810 --> 00:04:43,300
‫une très bonne stratégie pour empêcher ce type

101
00:04:43,300 --> 00:04:46,110
‫d'attaques, car un bon schéma oblige chaque valeur à

102
00:04:46,110 --> 00:04:48,410
‫avoir un onglet de données bien défini.

103
00:04:48,410 --> 00:04:50,190
‫Ce qui rend alors

104
00:04:50,190 --> 00:04:53,640
‫effectivement ce type d'attaque très difficile à exécuter.

105
00:04:53,640 --> 00:04:56,000
‫Cependant, c'est toujours une bonne idée

106
00:04:56,000 --> 00:04:59,280
‫de toujours désinfecter les données d'entrée, juste pour être sûr.

107
00:04:59,280 --> 00:05:02,300
‫Et nous nous en occuperons un peu plus tard.

108
00:05:02,300 --> 00:05:04,360
‫Très bien, et maintenant

109
00:05:04,360 --> 00:05:07,822
‫pour terminer, j'ai juste quelques bonnes pratiques et

110
00:05:07,822 --> 00:05:10,150
‫suggestions sur la façon d'améliorer les

111
00:05:10,150 --> 00:05:14,009
‫mécanismes d'authentification et d'autorisation que nous avons mis en place.

112
00:05:14,009 --> 00:05:16,350
‫Ainsi, la première chose

113
00:05:16,350 --> 00:05:18,760
‫que je dois répéter encore et

114
00:05:18,760 --> 00:05:21,370
‫encore est que dans une application de

115
00:05:21,370 --> 00:05:24,310
‫production, toutes les communications entre le serveur et

116
00:05:24,310 --> 00:05:26,980
‫le client doivent se faire via HTTPS.

117
00:05:26,980 --> 00:05:30,010
‫Sinon, n'importe qui peut écouter la conversation et

118
00:05:30,010 --> 00:05:32,520
‫voler notre jeton Web JSON.

119
00:05:32,520 --> 00:05:35,540
‫Ensuite, créez toujours des jetons de mot de passe aléatoires.

120
00:05:35,540 --> 00:05:38,660
‫Non généré à partir de dates ou quelque chose comme ça.

121
00:05:38,660 --> 00:05:40,920
‫Parce qu'il s'agit effectivement de mots de

122
00:05:40,920 --> 00:05:43,470
‫passe, ils doivent donc être traités comme tels.

123
00:05:43,470 --> 00:05:45,860
‫De plus, donnez-leur toujours des dates d'expiration, tout

124
00:05:45,860 --> 00:05:47,750
‫comme nous l'avons mis en œuvre.

125
00:05:47,750 --> 00:05:48,910
‫D'accord?

126
00:05:48,910 --> 00:05:52,340
‫Et nous avons également implémenté qu'un certain jeton Web JSON

127
00:05:52,340 --> 00:05:56,480
‫n'est plus valide une fois que l'utilisateur a modifié son mot de passe.

128
00:05:56,480 --> 00:05:58,660
‫Ainsi, nous révoquons essentiellement le jeton

129
00:05:58,660 --> 00:06:01,410
‫dès que l'utilisateur modifie le mot de passe.

130
00:06:01,410 --> 00:06:04,070
‫Ce qui a beaucoup de sens, mais encore

131
00:06:04,070 --> 00:06:07,650
‫une fois, de nombreux tutoriels ne le font tout simplement pas.

132
00:06:07,650 --> 00:06:10,470
‫Une autre chose importante est de ne jamais

133
00:06:10,470 --> 00:06:14,060
‫valider un fichier de configuration, comme pour les variables d'environnement, dans

134
00:06:14,060 --> 00:06:16,460
‫un contrôle de version comme Git.

135
00:06:16,460 --> 00:06:19,020
‫En fait, ne le téléchargez nulle part

136
00:06:19,020 --> 00:06:20,500
‫car ce fichier

137
00:06:20,500 --> 00:06:23,780
‫contient les données les plus sensibles de toute l'application.

138
00:06:23,780 --> 00:06:26,340
‫Par exemple, si quelqu'un a accès

139
00:06:26,340 --> 00:06:28,260
‫à votre secret de

140
00:06:28,260 --> 00:06:32,083
‫jeton Web JSON, l'ensemble de votre processus d'authentification est compromis.

141
00:06:32,083 --> 00:06:35,950
‫D'accord, et maintenant juste un petit détail est de ne pas

142
00:06:35,950 --> 00:06:37,560
‫envoyer l'erreur entière au

143
00:06:37,560 --> 00:06:40,560
‫client chaque fois qu'il y a une erreur.

144
00:06:40,560 --> 00:06:44,010
‫Ainsi, des éléments tels que la trace de la pile pourraient donner

145
00:06:44,010 --> 00:06:46,920
‫à l'attaquant des informations précieuses sur votre système, et

146
00:06:46,920 --> 00:06:49,650
‫donc, bien sûr, nous ne le voulons pas.

147
00:06:49,650 --> 00:06:52,480
‫Ensuite, nous pouvons utiliser le package csurf

148
00:06:52,480 --> 00:06:57,200
‫pour lutter contre un type d'attaque appelé Cross-Site Request Forgery, qui est une

149
00:06:57,200 --> 00:06:59,750
‫attaque qui oblige un utilisateur à

150
00:06:59,750 --> 00:07:03,530
‫exécuter des actions indésirables sur une application Web dans laquelle

151
00:07:03,530 --> 00:07:05,330
‫il est actuellement connecté.

152
00:07:05,330 --> 00:07:07,600
‫Nous n'allons pas le faire dans cette section, cependant.

153
00:07:07,600 --> 00:07:10,140
‫Mais je voulais quand même le mentionner ici.

154
00:07:10,140 --> 00:07:12,280
‫Ensuite, nous pourrions exiger que

155
00:07:12,280 --> 00:07:16,180
‫l'utilisateur se ré-authentifie avant d'effectuer une action de grande valeur.

156
00:07:16,180 --> 00:07:19,730
‫Par exemple, effectuer un paiement ou supprimer quelque chose.

157
00:07:19,730 --> 00:07:22,070
‫Encore une fois, ce n'est qu'une suggestion que

158
00:07:22,070 --> 00:07:23,810
‫vous pouvez essayer par vous-même.

159
00:07:23,810 --> 00:07:26,630
‫Une autre fonctionnalité intéressante que vous pouvez

160
00:07:26,630 --> 00:07:29,460
‫implémenter est une liste noire de jetons non fiables.

161
00:07:29,460 --> 00:07:31,660
‫Ainsi, nous savons déjà qu'il

162
00:07:31,660 --> 00:07:34,910
‫n'y a pas vraiment de moyen de déconnecter les utilisateurs

163
00:07:34,910 --> 00:07:37,220
‫de l'application s'ils montrent une activité malveillante.

164
00:07:37,220 --> 00:07:41,260
‫Mais ce que nous pouvons faire, c'est créer une liste de jetons

165
00:07:41,260 --> 00:07:44,370
‫non fiables qui sont ensuite validés à chaque demande.

166
00:07:44,370 --> 00:07:47,920
‫Et ensuite, une fonctionnalité que nous aurions pu implémenter

167
00:07:47,920 --> 00:07:51,810
‫consiste à confirmer l'adresse e-mail après la création d'un compte.

168
00:07:51,810 --> 00:07:54,665
‫Donc, essentiellement en envoyant un lien vers l'e-mail de

169
00:07:54,665 --> 00:07:57,520
‫l'utilisateur, comme le font de nombreuses applications réelles.

170
00:07:57,520 --> 00:08:00,190
‫Mais je voulais juste garder les choses simples ici,

171
00:08:00,190 --> 00:08:02,600
‫c'est pourquoi je ne l'ai pas fait ici.

172
00:08:02,600 --> 00:08:05,400
‫Mais n'hésitez pas à l'implémenter vous-même si

173
00:08:05,400 --> 00:08:07,360
‫vous en avez envie.

174
00:08:07,360 --> 00:08:09,900
‫Maintenant, une grande fonctionnalité dont disposent de

175
00:08:09,900 --> 00:08:12,580
‫nombreuses applications est le concept de jetons d'actualisation.

176
00:08:12,580 --> 00:08:15,050
‫Qui sont essentiellement à retenir des utilisateurs.

177
00:08:15,050 --> 00:08:17,150
‫Donc, pour les garder connectés pour

178
00:08:17,150 --> 00:08:19,720
‫toujours ou jusqu'à ce qu'ils choisissent de se déconnecter.

179
00:08:19,720 --> 00:08:22,170
‫Notre implémentation actuelle fait

180
00:08:22,170 --> 00:08:25,020
‫en sorte que l'utilisateur doit se reconnecter

181
00:08:25,020 --> 00:08:27,480
‫après l'expiration du jeton Web JSON.

182
00:08:27,480 --> 00:08:30,720
‫Mais, avec les jetons d'actualisation, ce n'est plus nécessaire.

183
00:08:30,720 --> 00:08:33,490
‫Et c'est un peu complexe à mettre en œuvre et donc,

184
00:08:33,490 --> 00:08:35,343
‫c'est une fonctionnalité pour une autre fois.

185
00:08:36,270 --> 00:08:37,950
‫Et enfin, le

186
00:08:37,950 --> 00:08:41,530
‫dernier que nous aurions pu implémenter est l'authentification à

187
00:08:41,530 --> 00:08:43,770
‫deux facteurs, que vous connaissez certainement.

188
00:08:43,770 --> 00:08:46,079
‫Fondamentalement, avec l'authentification à deux facteurs,

189
00:08:46,079 --> 00:08:48,750
‫après s'être connecté à l'application, l'utilisateur

190
00:08:48,750 --> 00:08:50,050
‫doit effectuer

191
00:08:50,050 --> 00:08:53,110
‫une deuxième action pour être vraiment authentifié.

192
00:08:53,110 --> 00:08:55,750
‫Et généralement, il s'agit d'insérer un

193
00:08:55,750 --> 00:08:58,980
‫code envoyé par SMS sur un téléphone portable.

194
00:08:58,980 --> 00:09:01,420
‫Donc, ce sont beaucoup de fonctionnalités

195
00:09:01,420 --> 00:09:03,580
‫que notre authentification pourrait avoir.

196
00:09:03,580 --> 00:09:05,730
‫Et si vous voulez que je les

197
00:09:05,730 --> 00:09:08,160
‫implémente, faites-le moi savoir dans la section Q&R.

198
00:09:08,160 --> 00:09:10,640
‫Et, s'il y a beaucoup de demande pour l'un d'entre eux,

199
00:09:10,640 --> 00:09:12,740
‫alors je vais vous montrer comment cela fonctionne.

200
00:09:12,740 --> 00:09:15,210
‫D'accord, mais encore une fois, je ne voulais pas

201
00:09:15,210 --> 00:09:17,270
‫activer ce Node. js en

202
00:09:17,270 --> 00:09:20,760
‫un cours complet sur la sécurité et l'authentification.

203
00:09:20,760 --> 00:09:24,230
‫Et juste pour finir, quelque chose que nous allons mettre en œuvre

204
00:09:24,230 --> 00:09:26,200
‫dans le reste de la

205
00:09:26,200 --> 00:09:28,320
‫section est d'éviter la pollution des paramètres.

206
00:09:28,320 --> 00:09:32,450
‫Par exemple, essayez simplement d'insérer deux paramètres de champ dans la

207
00:09:32,450 --> 00:09:36,030
‫chaîne de requête qui recherche toutes les visites.

208
00:09:36,030 --> 00:09:38,290
‫Et si vous faites cela, vous constaterez qu'il

209
00:09:38,290 --> 00:09:39,770
‫y aura une erreur

210
00:09:39,770 --> 00:09:42,150
‫car notre application n'est pas préparée pour cela.

211
00:09:42,150 --> 00:09:45,790
‫Et donc, les attaquants essaient d'utiliser ce genre de faiblesses pour faire

212
00:09:45,790 --> 00:09:49,330
‫planter des applications, ce qui, bien sûr, n'est pas bon.

213
00:09:49,330 --> 00:09:51,530
‫Et donc, nous devons corriger cela.

214
00:09:51,530 --> 00:09:56,286
‫D'accord, cela s'est avéré beaucoup plus long que ce à quoi je m'attendais.

215
00:09:56,286 --> 00:09:59,231
‫Et il y a des cours entiers sur la sécurité

216
00:09:59,231 --> 00:10:01,560
‫si vous êtes vraiment dans la sécurité.

217
00:10:01,560 --> 00:10:04,074
‫Très bien, mais je m'arrête

218
00:10:04,074 --> 00:10:07,283
‫là, et donc, passons maintenant directement au suivant.

