1
00:00:01,300 --> 00:00:04,156
‫Portanto, tudo o que fizemos nesta seção até

2
00:00:04,156 --> 00:00:06,514
‫agora foi para proteger todos os

3
00:00:06,514 --> 00:00:10,320
‫aplicativos e os dados de nossos usuários da melhor forma possível.

4
00:00:10,320 --> 00:00:12,290
‫E falei sobre muitas coisas que

5
00:00:12,290 --> 00:00:14,170
‫podemos fazer para conseguir isso.

6
00:00:14,170 --> 00:00:16,430
‫Mas todas essas informações

7
00:00:16,430 --> 00:00:18,860
‫foram espalhadas por todas essas palestras.

8
00:00:18,860 --> 00:00:21,311
‫Portanto, decidi criar este resumo rápido

9
00:00:21,311 --> 00:00:24,717
‫com muitas das melhores práticas que já implementamos

10
00:00:24,717 --> 00:00:26,960
‫e que ainda implementaremos no

11
00:00:26,960 --> 00:00:28,860
‫restante desta seção.

12
00:00:28,860 --> 00:00:32,100
‫Porque a segurança é extremamente importante,

13
00:00:32,100 --> 00:00:36,010
‫mas, infelizmente, muitos cursos não abordam isso o suficiente.

14
00:00:36,010 --> 00:00:37,490
‫Agora, eu também

15
00:00:37,490 --> 00:00:40,660
‫não estou ativando este Nodo. curso js em um curso de segurança.

16
00:00:40,660 --> 00:00:44,170
‫Existem melhores cursos e especialistas para isso.

17
00:00:44,170 --> 00:00:46,490
‫Mas vou mostrar algumas coisas

18
00:00:46,490 --> 00:00:51,490
‫que você pode fazer para proteger adequadamente seus aplicativos e dados.

19
00:00:51,650 --> 00:00:54,200
‫Vou examinar alguns ataques comuns

20
00:00:54,200 --> 00:00:57,010
‫e dar algumas sugestões para evitá-los.

21
00:00:57,010 --> 00:01:00,780
‫E, em primeiro lugar, temos o caso de um banco de dados

22
00:01:00,780 --> 00:01:04,980
‫comprometido, o que significa que um invasor obteve acesso ao nosso banco de dados.

23
00:01:04,980 --> 00:01:07,970
‫Claro, este é um problema extremamente grave,

24
00:01:07,970 --> 00:01:10,430
‫mas para evitar problemas ainda

25
00:01:10,430 --> 00:01:14,550
‫maiores, devemos sempre criptografar as senhas e tokens de redefinição de

26
00:01:14,550 --> 00:01:17,660
‫senha, assim como fizemos nos vídeos desta seção.

27
00:01:17,660 --> 00:01:19,800
‫Dessa forma, o invasor não pode

28
00:01:19,800 --> 00:01:24,320
‫pelo menos roubar as senhas de nossos usuários e também não pode redefini-las.

29
00:01:24,320 --> 00:01:26,720
‫Agora, sobre como prevenir ataques, vamos

30
00:01:26,720 --> 00:01:29,110
‫falar sobre o ataque de força

31
00:01:29,110 --> 00:01:32,290
‫bruta em que o invasor basicamente tenta adivinhar

32
00:01:32,290 --> 00:01:35,660
‫uma senha tentando milhões e milhões de senhas aleatórias

33
00:01:35,660 --> 00:01:37,850
‫até encontrar a correta.

34
00:01:37,850 --> 00:01:42,160
‫E o que podemos fazer é tornar a solicitação de login muito lenta.

35
00:01:42,160 --> 00:01:44,586
‫E o pacote bcrypt

36
00:01:44,586 --> 00:01:47,020
‫que estamos usando faz exatamente isso.

37
00:01:47,020 --> 00:01:50,180
‫Outra estratégia é implementar a limitação de taxa,

38
00:01:50,180 --> 00:01:52,340
‫que limita o número de

39
00:01:52,340 --> 00:01:54,640
‫solicitações provenientes de um único IP.

40
00:01:54,640 --> 00:01:56,330
‫E este vamos

41
00:01:56,330 --> 00:01:58,460
‫implementar em um dos próximos vídeos.

42
00:01:58,460 --> 00:02:01,690
‫Além disso, uma boa estratégia é realmente implementar

43
00:02:01,690 --> 00:02:05,470
‫um número máximo de tentativas de login para cada usuário.

44
00:02:05,470 --> 00:02:07,660
‫Por exemplo, poderíamos fazer com

45
00:02:07,660 --> 00:02:10,540
‫que, após 10 tentativas falhas, o usuário tivesse

46
00:02:10,540 --> 00:02:14,020
‫que esperar uma hora até que pudesse tentar novamente.

47
00:02:14,020 --> 00:02:16,360
‫Agora, não vou implementar essa

48
00:02:16,360 --> 00:02:18,760
‫funcionalidade nesta seção, mas sinta-se à

49
00:02:18,760 --> 00:02:21,340
‫vontade para experimentá-la por conta própria.

50
00:02:21,340 --> 00:02:24,350
‫Provavelmente é uma experiência de aprendizado muito legal codificar

51
00:02:24,350 --> 00:02:26,120
‫isso sozinho e, na verdade,

52
00:02:26,120 --> 00:02:27,890
‫não é tão difícil.

53
00:02:27,890 --> 00:02:29,210
‫Tudo bem.

54
00:02:29,210 --> 00:02:32,580
‫Em seguida, há o ataque de script entre sites,

55
00:02:32,580 --> 00:02:34,020
‫em que o

56
00:02:34,020 --> 00:02:38,430
‫invasor tenta injetar scripts em nossa página para executar seu código malicioso.

57
00:02:38,430 --> 00:02:41,280
‫Do lado dos clientes, isso é especialmente

58
00:02:41,280 --> 00:02:44,810
‫perigoso porque permite que o invasor leia o armazenamento

59
00:02:44,810 --> 00:02:46,500
‫local, razão pela qual

60
00:02:46,500 --> 00:02:50,360
‫nunca devemos armazenar o token da Web JSON no armazenamento local.

61
00:02:50,360 --> 00:02:54,110
‫Em vez disso, ele deve ser armazenado em um cookie somente HTTP,

62
00:02:54,110 --> 00:02:55,950
‫de forma que o navegador

63
00:02:55,950 --> 00:02:58,110
‫possa apenas receber e enviar o

64
00:02:58,110 --> 00:03:01,400
‫cookie, mas não pode acessá-lo ou modificá-lo de nenhuma forma.

65
00:03:01,400 --> 00:03:04,360
‫E isso torna impossível para qualquer invasor

66
00:03:04,360 --> 00:03:08,460
‫roubar o token da Web JSON que está armazenado no cookie.

67
00:03:08,460 --> 00:03:11,590
‫Novamente, estamos implementando isso em um segundo.

68
00:03:11,590 --> 00:03:15,780
‫Agora, no lado do backend, para evitar ataques XSS, devemos limpar

69
00:03:15,780 --> 00:03:18,170
‫os dados de entrada do

70
00:03:18,170 --> 00:03:20,660
‫usuário e definir alguns cabeçalhos HTTP especiais

71
00:03:20,660 --> 00:03:24,470
‫que tornam esses ataques um pouco mais difíceis de acontecer.

72
00:03:24,470 --> 00:03:27,040
‫E o Express não vem com essas práticas

73
00:03:27,040 --> 00:03:29,560
‫recomendadas fora da caixa, então usaremos middleware para

74
00:03:29,560 --> 00:03:31,713
‫definir todos esses cabeçalhos especiais.

75
00:03:32,710 --> 00:03:35,620
‫Em seguida, temos ataques de negação de serviço.

76
00:03:35,620 --> 00:03:37,510
‫E talvez você já tenha ouvido falar deles.

77
00:03:37,510 --> 00:03:39,330
‫Acontece quando o

78
00:03:39,330 --> 00:03:42,600
‫invasor envia tantas solicitações a um servidor que

79
00:03:42,600 --> 00:03:45,450
‫ele quebra e o aplicativo fica indisponível.

80
00:03:45,450 --> 00:03:47,470
‫Novamente, implementar a limitação de

81
00:03:47,470 --> 00:03:49,530
‫taxa é uma boa solução para isso.

82
00:03:49,530 --> 00:03:51,970
‫Além disso, devemos limitar a quantidade de dados

83
00:03:51,970 --> 00:03:55,810
‫que podem ser enviados em um corpo em uma postagem ou solicitação de patch.

84
00:03:55,810 --> 00:03:57,950
‫E também, devemos evitar o

85
00:03:57,950 --> 00:04:01,110
‫uso das chamadas expressões regulares malignas em nosso código.

86
00:04:01,110 --> 00:04:03,590
‫E essas são apenas expressões regulares

87
00:04:03,590 --> 00:04:07,550
‫que levam um tempo exponencial para serem executadas para entradas não

88
00:04:07,550 --> 00:04:11,680
‫correspondentes e podem ser exploradas para desativar todo o nosso aplicativo.

89
00:04:11,680 --> 00:04:15,960
‫Ok, em seguida, temos o ataque de injeção de consulta NoSQL.

90
00:04:15,960 --> 00:04:18,510
‫E a injeção de consulta acontece quando

91
00:04:18,510 --> 00:04:22,240
‫um invasor, em vez de inserir dados válidos, injeta alguma

92
00:04:22,240 --> 00:04:24,330
‫consulta para criar expressões de

93
00:04:24,330 --> 00:04:26,600
‫consulta que serão convertidas em verdadeiras.

94
00:04:26,600 --> 00:04:28,920
‫Por exemplo, para estar logado mesmo

95
00:04:28,920 --> 00:04:32,120
‫sem fornecer um nome de usuário ou senha válidos.

96
00:04:32,120 --> 00:04:33,380
‫É um pouco complexo

97
00:04:33,380 --> 00:04:36,330
‫e você definitivamente deveria pesquisar no Google para aprender mais.

98
00:04:36,330 --> 00:04:38,940
‫Mas o que você precisa saber é que usar

99
00:04:38,940 --> 00:04:40,810
‫o Mongoose é na verdade

100
00:04:40,810 --> 00:04:43,300
‫uma estratégia muito boa para prevenir esse tipo

101
00:04:43,300 --> 00:04:46,110
‫de ataques porque um bom esquema força cada valor a

102
00:04:46,110 --> 00:04:48,410
‫ter uma guia de dados bem definida.

103
00:04:48,410 --> 00:04:50,190
‫O que torna

104
00:04:50,190 --> 00:04:53,640
‫esse tipo de ataque muito difícil de executar.

105
00:04:53,640 --> 00:04:56,000
‫No entanto, é sempre uma boa ideia

106
00:04:56,000 --> 00:04:59,280
‫ainda higienizar os dados de entrada, apenas para ter certeza.

107
00:04:59,280 --> 00:05:02,300
‫E cuidaremos disso um pouco mais tarde.

108
00:05:02,300 --> 00:05:04,360
‫Certo, e agora

109
00:05:04,360 --> 00:05:07,822
‫para terminar, só tenho algumas práticas recomendadas

110
00:05:07,822 --> 00:05:10,150
‫e sugestões sobre como melhorar

111
00:05:10,150 --> 00:05:14,009
‫os mecanismos de autenticação e autorização que implementamos.

112
00:05:14,009 --> 00:05:16,350
‫Portanto, a primeira coisa

113
00:05:16,350 --> 00:05:18,760
‫que preciso repetir continuamente é que,

114
00:05:18,760 --> 00:05:21,370
‫em um aplicativo de produção, toda

115
00:05:21,370 --> 00:05:24,310
‫a comunicação entre o servidor e o

116
00:05:24,310 --> 00:05:26,980
‫cliente precisa acontecer por meio de HTTPS.

117
00:05:26,980 --> 00:05:30,010
‫Caso contrário, qualquer pessoa pode ouvir a conversa e

118
00:05:30,010 --> 00:05:32,520
‫roubar nosso token JSON da web.

119
00:05:32,520 --> 00:05:35,540
‫Em seguida, sempre crie tokens de senha aleatórios.

120
00:05:35,540 --> 00:05:38,660
‫Não gerado a partir de datas ou algo parecido.

121
00:05:38,660 --> 00:05:40,920
‫Por serem efetivamente senhas e,

122
00:05:40,920 --> 00:05:43,470
‫portanto, devem ser tratados como tal.

123
00:05:43,470 --> 00:05:45,860
‫Além disso, sempre forneça datas de

124
00:05:45,860 --> 00:05:47,750
‫validade, assim como implementamos.

125
00:05:47,750 --> 00:05:48,910
‫Tudo bem?

126
00:05:48,910 --> 00:05:52,340
‫E também implementamos que um determinado token da web

127
00:05:52,340 --> 00:05:56,480
‫JSON não é mais válido depois que o usuário altera sua senha.

128
00:05:56,480 --> 00:05:58,660
‫Portanto, basicamente revogamos o token

129
00:05:58,660 --> 00:06:01,410
‫assim que o usuário altera a senha.

130
00:06:01,410 --> 00:06:04,070
‫O que faz muito sentido, mas,

131
00:06:04,070 --> 00:06:07,650
‫novamente, muitos tutoriais por aí simplesmente não fazem isso.

132
00:06:07,650 --> 00:06:10,470
‫Outra grande coisa é nunca comprometer um arquivo

133
00:06:10,470 --> 00:06:14,060
‫de configuração, como para variáveis de ambiente, para um controle

134
00:06:14,060 --> 00:06:16,460
‫de versão como o Git.

135
00:06:16,460 --> 00:06:19,020
‫Na verdade, não o carregue em nenhum

136
00:06:19,020 --> 00:06:20,500
‫lugar porque esse arquivo

137
00:06:20,500 --> 00:06:23,780
‫contém os dados mais confidenciais de todo o aplicativo.

138
00:06:23,780 --> 00:06:26,340
‫Por exemplo, se alguém obtiver acesso ao

139
00:06:26,340 --> 00:06:28,260
‫segredo do token da

140
00:06:28,260 --> 00:06:32,083
‫Web JSON, todo o seu processo de autenticação será comprometido.

141
00:06:32,083 --> 00:06:35,950
‫Ok, e agora só um pequeno detalhe é para sempre que

142
00:06:35,950 --> 00:06:37,560
‫houver um erro,

143
00:06:37,560 --> 00:06:40,560
‫não envie todo o erro para o cliente.

144
00:06:40,560 --> 00:06:44,010
‫Portanto, coisas como o rastreamento de pilha podem fornecer ao

145
00:06:44,010 --> 00:06:46,920
‫invasor alguns insights valiosos sobre o seu sistema

146
00:06:46,920 --> 00:06:49,650
‫e, portanto, é claro, não queremos isso.

147
00:06:49,650 --> 00:06:52,480
‫A seguir, podemos usar o pacote csurf para

148
00:06:52,480 --> 00:06:57,200
‫combater um tipo de ataque chamado Cross-Site Request Forgery, que é um ataque

149
00:06:57,200 --> 00:06:59,750
‫que força um usuário a executar

150
00:06:59,750 --> 00:07:03,530
‫ações indesejadas em um aplicativo da web no qual ele

151
00:07:03,530 --> 00:07:05,330
‫está conectado no momento.

152
00:07:05,330 --> 00:07:07,600
‫Não vamos fazer isso nesta seção, no entanto.

153
00:07:07,600 --> 00:07:10,140
‫Mas eu ainda queria mencioná-lo aqui.

154
00:07:10,140 --> 00:07:12,280
‫Em seguida, podemos exigir que o

155
00:07:12,280 --> 00:07:16,180
‫usuário se reautentique antes de realizar uma ação de alto valor.

156
00:07:16,180 --> 00:07:19,730
‫Por exemplo, fazer um pagamento ou excluir algo.

157
00:07:19,730 --> 00:07:22,070
‫Novamente, esta é apenas uma sugestão

158
00:07:22,070 --> 00:07:23,810
‫que você pode experimentar.

159
00:07:23,810 --> 00:07:26,630
‫Outro recurso interessante que você pode implementar

160
00:07:26,630 --> 00:07:29,460
‫é uma lista negra de tokens não confiáveis.

161
00:07:29,460 --> 00:07:31,660
‫Portanto, já sabemos que não

162
00:07:31,660 --> 00:07:34,910
‫há realmente uma maneira de desconectar os usuários do

163
00:07:34,910 --> 00:07:37,220
‫aplicativo se eles mostrarem alguma atividade maliciosa.

164
00:07:37,220 --> 00:07:41,260
‫Mas o que podemos fazer é criar uma lista de tokens

165
00:07:41,260 --> 00:07:44,370
‫não confiáveis que são validados em cada solicitação.

166
00:07:44,370 --> 00:07:47,920
‫E a seguir, um recurso que poderíamos ter implementado é confirmar

167
00:07:47,920 --> 00:07:51,810
‫o endereço de e-mail depois que uma conta for criada pela primeira vez.

168
00:07:51,810 --> 00:07:54,665
‫Então, basicamente enviando um link para o e-mail

169
00:07:54,665 --> 00:07:57,520
‫do usuário, como muitos aplicativos reais realmente fazem.

170
00:07:57,520 --> 00:08:00,190
‫Mas eu queria apenas manter as coisas simples aqui, e

171
00:08:00,190 --> 00:08:02,600
‫é por isso que não fiz isso aqui.

172
00:08:02,600 --> 00:08:05,400
‫Mas sinta-se à vontade para implementar

173
00:08:05,400 --> 00:08:07,360
‫isso sozinho, se desejar.

174
00:08:07,360 --> 00:08:09,900
‫Agora, um grande recurso que muitos aplicativos

175
00:08:09,900 --> 00:08:12,580
‫têm é o conceito de tokens de atualização.

176
00:08:12,580 --> 00:08:15,050
‫Que são basicamente para lembrar os usuários.

177
00:08:15,050 --> 00:08:17,150
‫Portanto, para mantê-los logados para

178
00:08:17,150 --> 00:08:19,720
‫sempre ou até que decidam se desconectar.

179
00:08:19,720 --> 00:08:22,170
‫Nossa implementação atual faz com que

180
00:08:22,170 --> 00:08:25,020
‫o usuário tenha basicamente que fazer login novamente depois

181
00:08:25,020 --> 00:08:27,480
‫que o token da Web JSON expirar.

182
00:08:27,480 --> 00:08:30,720
‫Mas, com tokens de atualização, isso não é mais necessário.

183
00:08:30,720 --> 00:08:33,490
‫E é um pouco complexo de implementar e, portanto,

184
00:08:33,490 --> 00:08:35,343
‫é um recurso para outra hora.

185
00:08:36,270 --> 00:08:37,950
‫E, finalmente, o último que

186
00:08:37,950 --> 00:08:41,530
‫poderíamos ter implementado é a autenticação de dois fatores, com a

187
00:08:41,530 --> 00:08:43,770
‫qual tenho certeza que você está familiarizado.

188
00:08:43,770 --> 00:08:46,079
‫Basicamente, com a autenticação de dois

189
00:08:46,079 --> 00:08:48,750
‫fatores, após efetuar login no aplicativo, o

190
00:08:48,750 --> 00:08:50,050
‫usuário precisa

191
00:08:50,050 --> 00:08:53,110
‫realizar uma segunda ação para realmente se autenticar.

192
00:08:53,110 --> 00:08:55,750
‫E, normalmente, é para inserir um código

193
00:08:55,750 --> 00:08:58,980
‫enviado por mensagem de texto para um telefone celular.

194
00:08:58,980 --> 00:09:01,420
‫Então, essas são muitas funcionalidades que

195
00:09:01,420 --> 00:09:03,580
‫nossa autenticação poderia ter.

196
00:09:03,580 --> 00:09:05,730
‫E se você quiser que eu implemente algum

197
00:09:05,730 --> 00:09:08,160
‫deles, por favor, me avise na seção de perguntas e respostas.

198
00:09:08,160 --> 00:09:10,640
‫E, se houver muita demanda para um

199
00:09:10,640 --> 00:09:12,740
‫deles, vou mostrar como funciona.

200
00:09:12,740 --> 00:09:15,210
‫Ok, mas novamente, eu não queria virar

201
00:09:15,210 --> 00:09:17,270
‫este Nodo. curso js

202
00:09:17,270 --> 00:09:20,760
‫em um curso completo de segurança e autenticação.

203
00:09:20,760 --> 00:09:24,230
‫E só para terminar, algo que vamos implementar no

204
00:09:24,230 --> 00:09:26,200
‫resto da seção é

205
00:09:26,200 --> 00:09:28,320
‫evitar a poluição dos parâmetros.

206
00:09:28,320 --> 00:09:32,450
‫Por exemplo, tente inserir apenas dois parâmetros de campo na

207
00:09:32,450 --> 00:09:36,030
‫string de consulta que pesquisa todos os passeios.

208
00:09:36,030 --> 00:09:38,290
‫E se você fizer isso, verá que

209
00:09:38,290 --> 00:09:39,770
‫haverá um erro porque

210
00:09:39,770 --> 00:09:42,150
‫nosso aplicativo não está preparado para isso.

211
00:09:42,150 --> 00:09:45,790
‫E assim, os invasores tentam usar esses tipos de fraquezas para

212
00:09:45,790 --> 00:09:49,330
‫travar os aplicativos, o que, obviamente, não é bom.

213
00:09:49,330 --> 00:09:51,530
‫E então, precisamos consertar isso.

214
00:09:51,530 --> 00:09:56,286
‫Ok, isso acabou por demorar muito mais do que eu esperava.

215
00:09:56,286 --> 00:09:59,231
‫E existem cursos inteiros sobre segurança, se

216
00:09:59,231 --> 00:10:01,560
‫você realmente gosta de segurança.

217
00:10:01,560 --> 00:10:04,074
‫Tudo bem, mas estou deixando por

218
00:10:04,074 --> 00:10:07,283
‫isso mesmo, então, vamos passar direto para o próximo.