1
00:00:01,300 --> 00:00:04,156
‫Quindi, tutto ciò che abbiamo fatto finora in questa

2
00:00:04,156 --> 00:00:06,514
‫sezione è stato quello di proteggere tutte

3
00:00:06,514 --> 00:00:10,320
‫le applicazioni e i dati dei nostri utenti nel miglior modo possibile.

4
00:00:10,320 --> 00:00:12,290
‫E ho parlato di molte cose che

5
00:00:12,290 --> 00:00:14,170
‫possiamo fare per raggiungere questo obiettivo.

6
00:00:14,170 --> 00:00:16,430
‫Ma tutte queste informazioni

7
00:00:16,430 --> 00:00:18,860
‫erano sparpagliate in tutte queste conferenze.

8
00:00:18,860 --> 00:00:21,311
‫Quindi ho deciso di creare questo

9
00:00:21,311 --> 00:00:24,717
‫breve riepilogo con molte best practice che abbiamo già

10
00:00:24,717 --> 00:00:26,960
‫implementato e che implementeremo ancora nel

11
00:00:26,960 --> 00:00:28,860
‫resto di questa sezione.

12
00:00:28,860 --> 00:00:32,100
‫Perché la sicurezza è estremamente importante,

13
00:00:32,100 --> 00:00:36,010
‫ma sfortunatamente molti corsi non la affrontano abbastanza.

14
00:00:36,010 --> 00:00:37,490
‫Ora, non sto

15
00:00:37,490 --> 00:00:40,660
‫nemmeno trasformando questo Node. js in un corso di sicurezza.

16
00:00:40,660 --> 00:00:44,170
‫Ci sono corsi ed esperti migliori per questo.

17
00:00:44,170 --> 00:00:46,490
‫Ma ti mostrerò un paio di

18
00:00:46,490 --> 00:00:51,490
‫cose che puoi fare per proteggere adeguatamente le tue applicazioni e i tuoi dati.

19
00:00:51,650 --> 00:00:54,200
‫E esaminerò un paio di attacchi

20
00:00:54,200 --> 00:00:57,010
‫comuni e darò alcuni suggerimenti per prevenirli.

21
00:00:57,010 --> 00:01:00,780
‫E per prima cosa, abbiamo l'evento di un database compromesso,

22
00:01:00,780 --> 00:01:04,980
‫il che significa che un utente malintenzionato ha ottenuto l'accesso al nostro database.

23
00:01:04,980 --> 00:01:07,970
‫Certo, questo è un problema estremamente grave, ma

24
00:01:07,970 --> 00:01:10,430
‫per prevenire problemi ancora più grandi,

25
00:01:10,430 --> 00:01:14,550
‫dobbiamo sempre crittografare le password e i token di reimpostazione della password

26
00:01:14,550 --> 00:01:17,660
‫proprio come abbiamo fatto nei video in questa sezione.

27
00:01:17,660 --> 00:01:19,800
‫In questo modo, l'attaccante non

28
00:01:19,800 --> 00:01:24,320
‫può almeno rubare le password dei nostri utenti e nemmeno reimpostarle.

29
00:01:24,320 --> 00:01:26,720
‫Ora, per quanto riguarda la prevenzione

30
00:01:26,720 --> 00:01:29,110
‫degli attacchi, parliamo dell'attacco di forza

31
00:01:29,110 --> 00:01:32,290
‫bruta in cui l'attaccante cerca sostanzialmente di indovinare

32
00:01:32,290 --> 00:01:35,660
‫una password provando milioni e milioni di password casuali

33
00:01:35,660 --> 00:01:37,850
‫finché non trovano quella giusta.

34
00:01:37,850 --> 00:01:42,160
‫E quello che possiamo fare è rendere la richiesta di accesso molto lenta.

35
00:01:42,160 --> 00:01:44,586
‫E il pacchetto bcrypt che

36
00:01:44,586 --> 00:01:47,020
‫stiamo usando in realtà fa proprio questo.

37
00:01:47,020 --> 00:01:50,180
‫Un'altra strategia consiste nell'implementare la limitazione della velocità,

38
00:01:50,180 --> 00:01:52,340
‫che limita il numero di

39
00:01:52,340 --> 00:01:54,640
‫richieste provenienti da un singolo IP.

40
00:01:54,640 --> 00:01:56,330
‫E questo lo

41
00:01:56,330 --> 00:01:58,460
‫implementeremo in uno dei prossimi video.

42
00:01:58,460 --> 00:02:01,690
‫Inoltre, una buona strategia consiste nell'implementare effettivamente

43
00:02:01,690 --> 00:02:05,470
‫un numero massimo di tentativi di accesso per ciascun utente.

44
00:02:05,470 --> 00:02:07,660
‫Ad esempio, potremmo fare

45
00:02:07,660 --> 00:02:10,540
‫in modo che dopo 10 tentativi falliti,

46
00:02:10,540 --> 00:02:14,020
‫l'utente debba attendere un'ora prima di poter riprovare.

47
00:02:14,020 --> 00:02:16,360
‫Ora, non implementerò questa

48
00:02:16,360 --> 00:02:18,760
‫funzionalità in questa sezione, ma

49
00:02:18,760 --> 00:02:21,340
‫sentiti libero di sperimentarla da solo.

50
00:02:21,340 --> 00:02:24,350
‫Probabilmente è un'esperienza di apprendimento davvero interessante codificare

51
00:02:24,350 --> 00:02:26,120
‫da soli, e in realtà

52
00:02:26,120 --> 00:02:27,890
‫non è così difficile.

53
00:02:27,890 --> 00:02:29,210
‫Va bene.

54
00:02:29,210 --> 00:02:32,580
‫Successivamente, c'è l'attacco di scripting tra siti, in

55
00:02:32,580 --> 00:02:34,020
‫cui l'attaccante cerca

56
00:02:34,020 --> 00:02:38,430
‫di iniettare script nella nostra pagina per eseguire il suo codice dannoso.

57
00:02:38,430 --> 00:02:41,280
‫Dal lato dei client, questo è particolarmente

58
00:02:41,280 --> 00:02:44,810
‫pericoloso perché consente all'attaccante di leggere l'archiviazione locale,

59
00:02:44,810 --> 00:02:46,500
‫motivo per cui

60
00:02:46,500 --> 00:02:50,360
‫non dovremmo mai archiviare il token Web JSON nell'archiviazione locale.

61
00:02:50,360 --> 00:02:54,110
‫Invece, dovrebbe essere memorizzato in un cookie solo HTTP che fa

62
00:02:54,110 --> 00:02:55,950
‫in modo che il browser

63
00:02:55,950 --> 00:02:58,110
‫possa solo ricevere e inviare il

64
00:02:58,110 --> 00:03:01,400
‫cookie ma non possa accedervi o modificarlo in alcun modo.

65
00:03:01,400 --> 00:03:04,360
‫E quindi, ciò rende impossibile per qualsiasi

66
00:03:04,360 --> 00:03:08,460
‫utente malintenzionato rubare il token Web JSON memorizzato nel cookie.

67
00:03:08,460 --> 00:03:11,590
‫Ancora una volta, lo stiamo implementando in un secondo.

68
00:03:11,590 --> 00:03:15,780
‫Ora, dal lato del backend, per prevenire attacchi XSS, dovremmo disinfettare

69
00:03:15,780 --> 00:03:18,170
‫i dati di input dell'utente

70
00:03:18,170 --> 00:03:20,660
‫e impostare alcune intestazioni HTTP speciali

71
00:03:20,660 --> 00:03:24,470
‫che rendono un po' più difficile l'esecuzione di questi attacchi.

72
00:03:24,470 --> 00:03:27,040
‫Ed Express non viene fornito con queste best

73
00:03:27,040 --> 00:03:29,560
‫practice pronte all'uso, quindi utilizzeremo il middleware per

74
00:03:29,560 --> 00:03:31,713
‫impostare tutte queste intestazioni speciali.

75
00:03:32,710 --> 00:03:35,620
‫Successivamente, abbiamo attacchi di negazione del servizio.

76
00:03:35,620 --> 00:03:37,510
‫E forse ne hai sentito parlare.

77
00:03:37,510 --> 00:03:39,330
‫Succede quando l'attaccante

78
00:03:39,330 --> 00:03:42,600
‫invia così tante richieste a un server che

79
00:03:42,600 --> 00:03:45,450
‫si guasta e l'applicazione diventa non disponibile.

80
00:03:45,450 --> 00:03:47,470
‫Anche in questo caso, l'implementazione della

81
00:03:47,470 --> 00:03:49,530
‫limitazione della velocità è una buona soluzione.

82
00:03:49,530 --> 00:03:51,970
‫Inoltre, dovremmo limitare la quantità di dati che

83
00:03:51,970 --> 00:03:55,810
‫possono essere inviati in un corpo in un post o in una richiesta di patch.

84
00:03:55,810 --> 00:03:57,950
‫Inoltre, dovremmo evitare di usare le

85
00:03:57,950 --> 00:04:01,110
‫cosiddette espressioni regolari malvagie per essere presenti nel nostro codice.

86
00:04:01,110 --> 00:04:03,590
‫E queste sono solo espressioni

87
00:04:03,590 --> 00:04:07,550
‫regolari che impiegano un tempo esponenziale per essere eseguite per

88
00:04:07,550 --> 00:04:11,680
‫input non corrispondenti e possono essere sfruttate per abbattere l'intera applicazione.

89
00:04:11,680 --> 00:04:15,960
‫Ok, il prossimo passo è l'attacco di iniezione di query NoSQL.

90
00:04:15,960 --> 00:04:18,510
‫E l'iniezione di query si verifica quando

91
00:04:18,510 --> 00:04:22,240
‫un utente malintenzionato, invece di inserire dati validi, inserisce alcune

92
00:04:22,240 --> 00:04:24,330
‫query per creare espressioni di

93
00:04:24,330 --> 00:04:26,600
‫query che si tradurranno in true.

94
00:04:26,600 --> 00:04:28,920
‫Ad esempio, per essere loggato anche

95
00:04:28,920 --> 00:04:32,120
‫senza fornire un nome utente o una password validi.

96
00:04:32,120 --> 00:04:33,380
‫È un po' complesso

97
00:04:33,380 --> 00:04:36,330
‫e dovresti assolutamente cercarlo su Google per saperne di più.

98
00:04:36,330 --> 00:04:38,940
‫Ma quello che devi sapere è che l'uso

99
00:04:38,940 --> 00:04:40,810
‫di Mongoose è in realtà

100
00:04:40,810 --> 00:04:43,300
‫una strategia abbastanza buona per prevenire questo tipo

101
00:04:43,300 --> 00:04:46,110
‫di attacchi perché un buon schema forza ogni valore

102
00:04:46,110 --> 00:04:48,410
‫ad avere una scheda dati ben definita.

103
00:04:48,410 --> 00:04:50,190
‫Il che rende poi

104
00:04:50,190 --> 00:04:53,640
‫effettivamente questo tipo di attacco molto difficile da eseguire.

105
00:04:53,640 --> 00:04:56,000
‫Tuttavia, è sempre una buona idea

106
00:04:56,000 --> 00:04:59,280
‫disinfettare ancora i dati di input, solo per essere sicuri.

107
00:04:59,280 --> 00:05:02,300
‫E di questo ci occuperemo un po' più tardi.

108
00:05:02,300 --> 00:05:04,360
‫Bene, e ora per

109
00:05:04,360 --> 00:05:07,822
‫finire, ho solo un paio di best practice

110
00:05:07,822 --> 00:05:10,150
‫e suggerimenti su come migliorare

111
00:05:10,150 --> 00:05:14,009
‫i meccanismi di autenticazione e autorizzazione che abbiamo implementato.

112
00:05:14,009 --> 00:05:16,350
‫Quindi, la prima cosa

113
00:05:16,350 --> 00:05:18,760
‫che devo ripetere più e

114
00:05:18,760 --> 00:05:21,370
‫più volte è che in un'applicazione

115
00:05:21,370 --> 00:05:24,310
‫di produzione, tutte le comunicazioni tra server

116
00:05:24,310 --> 00:05:26,980
‫e client devono avvenire tramite HTTPS.

117
00:05:26,980 --> 00:05:30,010
‫Altrimenti, chiunque può ascoltare la conversazione e rubare

118
00:05:30,010 --> 00:05:32,520
‫il nostro token web JSON.

119
00:05:32,520 --> 00:05:35,540
‫Quindi, crea sempre token di password casuali.

120
00:05:35,540 --> 00:05:38,660
‫Non generato da date o qualcosa del genere.

121
00:05:38,660 --> 00:05:40,920
‫Poiché sono effettivamente password,

122
00:05:40,920 --> 00:05:43,470
‫dovrebbero essere trattate come tali.

123
00:05:43,470 --> 00:05:45,860
‫Inoltre, dai loro sempre le date di

124
00:05:45,860 --> 00:05:47,750
‫scadenza, proprio come l'abbiamo implementato.

125
00:05:47,750 --> 00:05:48,910
‫Va bene?

126
00:05:48,910 --> 00:05:52,340
‫E abbiamo anche implementato che un determinato token Web

127
00:05:52,340 --> 00:05:56,480
‫JSON non è più valido dopo che l'utente ha cambiato la sua password.

128
00:05:56,480 --> 00:05:58,660
‫Quindi, in pratica revochiamo il

129
00:05:58,660 --> 00:06:01,410
‫token non appena l'utente cambia la password.

130
00:06:01,410 --> 00:06:04,070
‫Il che ha molto senso, ma ancora

131
00:06:04,070 --> 00:06:07,650
‫una volta, molti tutorial là fuori semplicemente non lo fanno.

132
00:06:07,650 --> 00:06:10,470
‫Un'altra cosa importante è non eseguire mai il commit

133
00:06:10,470 --> 00:06:14,060
‫di un file di configurazione, come per le variabili di ambiente, su

134
00:06:14,060 --> 00:06:16,460
‫un controllo di versione come Git.

135
00:06:16,460 --> 00:06:19,020
‫In effetti, non caricarlo da nessuna

136
00:06:19,020 --> 00:06:20,500
‫parte perché questo

137
00:06:20,500 --> 00:06:23,780
‫file contiene i dati più sensibili dell'intera applicazione.

138
00:06:23,780 --> 00:06:26,340
‫Ad esempio, se qualcuno ottiene l'accesso

139
00:06:26,340 --> 00:06:28,260
‫al tuo segreto

140
00:06:28,260 --> 00:06:32,083
‫token web JSON, l'intero processo di autenticazione viene compromesso.

141
00:06:32,083 --> 00:06:35,950
‫Ok, e ora solo un piccolo dettaglio è che ogni volta

142
00:06:35,950 --> 00:06:37,560
‫che si verifica

143
00:06:37,560 --> 00:06:40,560
‫un errore, non inviare l'intero errore al client.

144
00:06:40,560 --> 00:06:44,010
‫Quindi, cose come la traccia dello stack potrebbero fornire

145
00:06:44,010 --> 00:06:46,920
‫all'attaccante alcune preziose informazioni sul tuo sistema

146
00:06:46,920 --> 00:06:49,650
‫e quindi, ovviamente, non lo vogliamo.

147
00:06:49,650 --> 00:06:52,480
‫Successivamente, possiamo utilizzare il pacchetto csurf per

148
00:06:52,480 --> 00:06:57,200
‫combattere un tipo di attacco chiamato Cross-Site Request Forgery, che è

149
00:06:57,200 --> 00:06:59,750
‫un attacco che costringe un utente

150
00:06:59,750 --> 00:07:03,530
‫a eseguire azioni indesiderate su un'applicazione Web in cui

151
00:07:03,530 --> 00:07:05,330
‫è attualmente connesso.

152
00:07:05,330 --> 00:07:07,600
‫Tuttavia, non lo faremo in questa sezione.

153
00:07:07,600 --> 00:07:10,140
‫Ma volevo ancora menzionarlo qui.

154
00:07:10,140 --> 00:07:12,280
‫Successivamente, potremmo richiedere all'utente

155
00:07:12,280 --> 00:07:16,180
‫di riautenticarsi prima di eseguire un'azione di alto valore.

156
00:07:16,180 --> 00:07:19,730
‫Ad esempio, effettuare un pagamento o eliminare qualcosa.

157
00:07:19,730 --> 00:07:22,070
‫Ancora una volta, questo è solo un suggerimento

158
00:07:22,070 --> 00:07:23,810
‫che puoi provare tu stesso.

159
00:07:23,810 --> 00:07:26,630
‫Un'altra caratteristica interessante che puoi implementare

160
00:07:26,630 --> 00:07:29,460
‫è una lista nera di token non attendibili.

161
00:07:29,460 --> 00:07:31,660
‫Quindi, sappiamo già che

162
00:07:31,660 --> 00:07:34,910
‫non esiste davvero un modo per disconnettere gli

163
00:07:34,910 --> 00:07:37,220
‫utenti dall'applicazione se mostrano attività dannose.

164
00:07:37,220 --> 00:07:41,260
‫Ma quello che possiamo fare è creare un elenco di token non

165
00:07:41,260 --> 00:07:44,370
‫attendibili che vengono poi convalidati ad ogni richiesta.

166
00:07:44,370 --> 00:07:47,920
‫E poi, una funzione che avremmo potuto implementare è quella

167
00:07:47,920 --> 00:07:51,810
‫di confermare l'indirizzo e-mail dopo la prima creazione di un account.

168
00:07:51,810 --> 00:07:54,665
‫Quindi, in pratica, inviando un collegamento all'e-mail dell'utente,

169
00:07:54,665 --> 00:07:57,520
‫come fanno in realtà molte app reali.

170
00:07:57,520 --> 00:08:00,190
‫Ma volevo solo mantenere le cose semplici qui,

171
00:08:00,190 --> 00:08:02,600
‫motivo per cui non l'ho fatto qui.

172
00:08:02,600 --> 00:08:05,400
‫Ma sentiti libero di implementarlo da solo

173
00:08:05,400 --> 00:08:07,360
‫se ne hai voglia.

174
00:08:07,360 --> 00:08:09,900
‫Ora, una grande caratteristica di molte

175
00:08:09,900 --> 00:08:12,580
‫app è il concetto di token di aggiornamento.

176
00:08:12,580 --> 00:08:15,050
‫Che sono fondamentalmente per ricordare gli utenti.

177
00:08:15,050 --> 00:08:17,150
‫Quindi, per tenerli connessi per

178
00:08:17,150 --> 00:08:19,720
‫sempre o finché non decidono di disconnettersi.

179
00:08:19,720 --> 00:08:22,170
‫La nostra attuale implementazione fa in

180
00:08:22,170 --> 00:08:25,020
‫modo che l'utente debba sostanzialmente accedere di nuovo

181
00:08:25,020 --> 00:08:27,480
‫dopo la scadenza del token Web JSON.

182
00:08:27,480 --> 00:08:30,720
‫Ma, con i token di aggiornamento, non è più necessario.

183
00:08:30,720 --> 00:08:33,490
‫Ed è un po' complesso da implementare e quindi

184
00:08:33,490 --> 00:08:35,343
‫è una funzionalità per un'altra volta.

185
00:08:36,270 --> 00:08:37,950
‫E infine, l'ultimo

186
00:08:37,950 --> 00:08:41,530
‫che avremmo potuto implementare è l'autenticazione a due fattori,

187
00:08:41,530 --> 00:08:43,770
‫che sono sicuro ti sia familiare.

188
00:08:43,770 --> 00:08:46,079
‫Fondamentalmente, con l'autenticazione a due fattori,

189
00:08:46,079 --> 00:08:48,750
‫dopo aver effettuato l'accesso all'applicazione, l'utente

190
00:08:48,750 --> 00:08:50,050
‫deve eseguire

191
00:08:50,050 --> 00:08:53,110
‫una seconda azione per essere realmente autenticato.

192
00:08:53,110 --> 00:08:55,750
‫E in genere, è quello di inserire un

193
00:08:55,750 --> 00:08:58,980
‫codice inviato tramite messaggio di testo a un telefono cellulare.

194
00:08:58,980 --> 00:09:01,420
‫Quindi, queste sono molte funzionalità che

195
00:09:01,420 --> 00:09:03,580
‫la nostra autenticazione potrebbe avere.

196
00:09:03,580 --> 00:09:05,730
‫E se vuoi che ne implementi qualcuno,

197
00:09:05,730 --> 00:09:08,160
‫per favore fammelo sapere nella sezione Domande e risposte.

198
00:09:08,160 --> 00:09:10,640
‫E, se c'è molta richiesta per uno di

199
00:09:10,640 --> 00:09:12,740
‫loro, allora ti mostrerò come funziona.

200
00:09:12,740 --> 00:09:15,210
‫Ok, ma ancora una volta, non volevo trasformare

201
00:09:15,210 --> 00:09:17,270
‫questo Node. js in

202
00:09:17,270 --> 00:09:20,760
‫un intero corso di sicurezza e autenticazione.

203
00:09:20,760 --> 00:09:24,230
‫E solo per finire, qualcosa che implementeremo nel

204
00:09:24,230 --> 00:09:26,200
‫resto della sezione

205
00:09:26,200 --> 00:09:28,320
‫è prevenire l'inquinamento dei parametri.

206
00:09:28,320 --> 00:09:32,450
‫Ad esempio, prova a inserire solo due parametri di campo nella

207
00:09:32,450 --> 00:09:36,030
‫stringa di query che cerca tutti i tour.

208
00:09:36,030 --> 00:09:38,290
‫E se lo fai, scoprirai che ci

209
00:09:38,290 --> 00:09:39,770
‫sarà un errore perché

210
00:09:39,770 --> 00:09:42,150
‫la nostra applicazione non è preparata per questo.

211
00:09:42,150 --> 00:09:45,790
‫E così, gli aggressori cercano di usare questo tipo di punti deboli per

212
00:09:45,790 --> 00:09:49,330
‫mandare in crash le applicazioni, il che, ovviamente, non va bene.

213
00:09:49,330 --> 00:09:51,530
‫E quindi, dobbiamo risolverlo.

214
00:09:51,530 --> 00:09:56,286
‫Ok, quindi questo si è rivelato molto più lungo di quanto mi aspettassi.

215
00:09:56,286 --> 00:09:59,231
‫E ci sono interi corsi sulla sicurezza se

216
00:09:59,231 --> 00:10:01,560
‫sei veramente interessato alla sicurezza.

217
00:10:01,560 --> 00:10:04,074
‫Va bene, ma lascio le cose

218
00:10:04,074 --> 00:10:07,283
‫a questo, quindi ora passiamo a quello successivo.