1
00:00:01,300 --> 00:00:04,156
‫Entonces, todo lo que hicimos en esta sección hasta

2
00:00:04,156 --> 00:00:06,514
‫ahora fue proteger todas las aplicaciones

3
00:00:06,514 --> 00:00:10,320
‫y los datos de nuestros usuarios de la mejor manera posible.

4
00:00:10,320 --> 00:00:12,290
‫Y hablé de muchas cosas que

5
00:00:12,290 --> 00:00:14,170
‫podemos hacer para lograrlo.

6
00:00:14,170 --> 00:00:16,430
‫Pero toda esta información

7
00:00:16,430 --> 00:00:18,860
‫se esparció por todas estas conferencias.

8
00:00:18,860 --> 00:00:21,311
‫Así que decidí crear este resumen rápido

9
00:00:21,311 --> 00:00:24,717
‫con muchas de las mejores prácticas que ya implementamos y

10
00:00:24,717 --> 00:00:26,960
‫que aún vamos a implementar en

11
00:00:26,960 --> 00:00:28,860
‫el resto de esta sección.

12
00:00:28,860 --> 00:00:32,100
‫Porque la seguridad es extremadamente importante,

13
00:00:32,100 --> 00:00:36,010
‫pero desafortunadamente, muchos cursos no lo abordan lo suficiente.

14
00:00:36,010 --> 00:00:37,490
‫Ahora, tampoco voy

15
00:00:37,490 --> 00:00:40,660
‫a convertir este Node. js en un curso de seguridad.

16
00:00:40,660 --> 00:00:44,170
‫Hay mejores cursos y expertos para eso.

17
00:00:44,170 --> 00:00:46,490
‫Pero le mostraré un par

18
00:00:46,490 --> 00:00:51,490
‫de cosas que puede hacer para proteger adecuadamente sus aplicaciones y datos.

19
00:00:51,650 --> 00:00:54,200
‫Y voy a ver un par de

20
00:00:54,200 --> 00:00:57,010
‫ataques comunes y dar algunas sugerencias para prevenirlos.

21
00:00:57,010 --> 00:01:00,780
‫Y primero, tenemos el caso de una base de datos comprometida,

22
00:01:00,780 --> 00:01:04,980
‫lo que significa que un atacante obtuvo acceso a nuestra base de datos.

23
00:01:04,980 --> 00:01:07,970
‫Por supuesto, este es un problema extremadamente grave, pero

24
00:01:07,970 --> 00:01:10,430
‫para evitar problemas aún mayores, siempre

25
00:01:10,430 --> 00:01:14,550
‫debemos cifrar las contraseñas y los tokens de restablecimiento de contraseñas tal

26
00:01:14,550 --> 00:01:17,660
‫como lo hicimos en los videos de esta sección.

27
00:01:17,660 --> 00:01:19,800
‫De esta manera, el atacante no

28
00:01:19,800 --> 00:01:24,320
‫puede al menos robar las contraseñas de nuestros usuarios y tampoco puede restablecerlas.

29
00:01:24,320 --> 00:01:26,720
‫Ahora, sobre la prevención real de

30
00:01:26,720 --> 00:01:29,110
‫los ataques, hablemos del ataque de

31
00:01:29,110 --> 00:01:32,290
‫fuerza bruta en el que el atacante básicamente intenta

32
00:01:32,290 --> 00:01:35,660
‫adivinar una contraseña probando millones y millones de contraseñas

33
00:01:35,660 --> 00:01:37,850
‫aleatorias hasta encontrar la correcta.

34
00:01:37,850 --> 00:01:42,160
‫Y lo que podemos hacer es hacer que la solicitud de inicio de sesión sea realmente lenta.

35
00:01:42,160 --> 00:01:44,586
‫Y el paquete bcrypt que

36
00:01:44,586 --> 00:01:47,020
‫estamos usando en realidad hace precisamente eso.

37
00:01:47,020 --> 00:01:50,180
‫Otra estrategia es implementar la limitación de velocidad,

38
00:01:50,180 --> 00:01:52,340
‫que limita la cantidad de

39
00:01:52,340 --> 00:01:54,640
‫solicitudes provenientes de una única IP.

40
00:01:54,640 --> 00:01:56,330
‫Y este lo implementaremos

41
00:01:56,330 --> 00:01:58,460
‫en uno de los próximos videos.

42
00:01:58,460 --> 00:02:01,690
‫Además, una buena estrategia es implementar un número

43
00:02:01,690 --> 00:02:05,470
‫máximo de intentos de inicio de sesión para cada usuario.

44
00:02:05,470 --> 00:02:07,660
‫Por ejemplo, podríamos hacer que

45
00:02:07,660 --> 00:02:10,540
‫después de 10 intentos fallidos, el usuario tenga

46
00:02:10,540 --> 00:02:14,020
‫que esperar una hora hasta que pueda volver a intentarlo.

47
00:02:14,020 --> 00:02:16,360
‫Ahora bien, no voy a implementar

48
00:02:16,360 --> 00:02:18,760
‫esta funcionalidad en esta sección, pero siéntase

49
00:02:18,760 --> 00:02:21,340
‫libre de experimentar con ella por su cuenta.

50
00:02:21,340 --> 00:02:24,350
‫Probablemente sea una experiencia de aprendizaje realmente genial codificar

51
00:02:24,350 --> 00:02:26,120
‫esto usted mismo, y en

52
00:02:26,120 --> 00:02:27,890
‫realidad no es tan difícil.

53
00:02:27,890 --> 00:02:29,210
‫Está bien.

54
00:02:29,210 --> 00:02:32,580
‫A continuación, está el ataque de secuencias de comandos entre sitios,

55
00:02:32,580 --> 00:02:34,020
‫en el que el

56
00:02:34,020 --> 00:02:38,430
‫atacante intenta inyectar secuencias de comandos en nuestra página para ejecutar su código malicioso.

57
00:02:38,430 --> 00:02:41,280
‫Por el lado de los clientes, esto es

58
00:02:41,280 --> 00:02:44,810
‫especialmente peligroso porque permite al atacante leer el almacenamiento local,

59
00:02:44,810 --> 00:02:46,500
‫razón por la cual

60
00:02:46,500 --> 00:02:50,360
‫nunca deberíamos almacenar el token web JSON en el almacenamiento local.

61
00:02:50,360 --> 00:02:54,110
‫En su lugar, debe almacenarse en una cookie solo HTTP que lo haga

62
00:02:54,110 --> 00:02:55,950
‫de modo que el navegador

63
00:02:55,950 --> 00:02:58,110
‫solo pueda recibir y enviar la cookie,

64
00:02:58,110 --> 00:03:01,400
‫pero no pueda acceder a ella ni modificarla de ninguna manera.

65
00:03:01,400 --> 00:03:04,360
‫Y entonces, eso hace que sea imposible para

66
00:03:04,360 --> 00:03:08,460
‫cualquier atacante robar el token web JSON que está almacenado en la cookie.

67
00:03:08,460 --> 00:03:11,590
‫Nuevamente, implementaremos esto en un segundo.

68
00:03:11,590 --> 00:03:15,780
‫Ahora, en el lado del backend, para evitar ataques XSS, debemos desinfectar

69
00:03:15,780 --> 00:03:18,170
‫los datos de entrada del usuario

70
00:03:18,170 --> 00:03:20,660
‫y establecer algunos encabezados HTTP especiales que

71
00:03:20,660 --> 00:03:24,470
‫hacen que estos ataques sean un poco más difíciles de suceder.

72
00:03:24,470 --> 00:03:27,040
‫Y Express no viene con estas mejores prácticas

73
00:03:27,040 --> 00:03:29,560
‫listas para usar, por lo que usaremos middleware

74
00:03:29,560 --> 00:03:31,713
‫para configurar todos estos encabezados especiales.

75
00:03:32,710 --> 00:03:35,620
‫A continuación, tenemos los ataques de denegación de servicio.

76
00:03:35,620 --> 00:03:37,510
‫Y tal vez hayas oído hablar de estos.

77
00:03:37,510 --> 00:03:39,330
‫Ocurre cuando el atacante

78
00:03:39,330 --> 00:03:42,600
‫envía tantas solicitudes a un servidor que se daña

79
00:03:42,600 --> 00:03:45,450
‫y la aplicación deja de estar disponible.

80
00:03:45,450 --> 00:03:47,470
‫Nuevamente, implementar la limitación de

81
00:03:47,470 --> 00:03:49,530
‫velocidad es una buena solución para esto.

82
00:03:49,530 --> 00:03:51,970
‫Además, debemos limitar la cantidad de datos que

83
00:03:51,970 --> 00:03:55,810
‫se pueden enviar en un cuerpo en una publicación o una solicitud de parche.

84
00:03:55,810 --> 00:03:57,950
‫Y también, debemos evitar el uso

85
00:03:57,950 --> 00:04:01,110
‫de las llamadas expresiones regulares malvadas para estar en nuestro código.

86
00:04:01,110 --> 00:04:03,590
‫Y estas son solo expresiones regulares

87
00:04:03,590 --> 00:04:07,550
‫que toman un tiempo exponencial para ejecutarse para entradas que

88
00:04:07,550 --> 00:04:11,680
‫no coinciden y pueden explotarse para hacer caer toda nuestra aplicación.

89
00:04:11,680 --> 00:04:15,960
‫Bien, a continuación, tenemos el ataque de inyección de consultas NoSQL.

90
00:04:15,960 --> 00:04:18,510
‫Y la inyección de consultas ocurre cuando

91
00:04:18,510 --> 00:04:22,240
‫un atacante, en lugar de ingresar datos válidos, inyecta alguna

92
00:04:22,240 --> 00:04:24,330
‫consulta para crear expresiones de

93
00:04:24,330 --> 00:04:26,600
‫consulta que se traducirán en verdaderas.

94
00:04:26,600 --> 00:04:28,920
‫Por ejemplo, iniciar sesión incluso

95
00:04:28,920 --> 00:04:32,120
‫sin proporcionar un nombre de usuario o contraseña válidos.

96
00:04:32,120 --> 00:04:33,380
‫Es un poco complejo

97
00:04:33,380 --> 00:04:36,330
‫y definitivamente deberías buscarlo en Google para obtener más información.

98
00:04:36,330 --> 00:04:38,940
‫Pero lo que necesita saber es que usar Mongoose

99
00:04:38,940 --> 00:04:40,810
‫es en realidad una estrategia

100
00:04:40,810 --> 00:04:43,300
‫bastante buena para prevenir este tipo de ataques

101
00:04:43,300 --> 00:04:46,110
‫porque un buen esquema obliga a cada valor a

102
00:04:46,110 --> 00:04:48,410
‫tener una pestaña de datos bien definida.

103
00:04:48,410 --> 00:04:50,190
‫Lo que hace que

104
00:04:50,190 --> 00:04:53,640
‫este tipo de ataque sea muy difícil de ejecutar.

105
00:04:53,640 --> 00:04:56,000
‫Sin embargo, siempre es una buena

106
00:04:56,000 --> 00:04:59,280
‫idea desinfectar los datos de entrada, solo para estar seguro.

107
00:04:59,280 --> 00:05:02,300
‫Y nos ocuparemos de eso un poco más tarde.

108
00:05:02,300 --> 00:05:04,360
‫Muy bien, y ahora

109
00:05:04,360 --> 00:05:07,822
‫para terminar, solo tengo un par de mejores

110
00:05:07,822 --> 00:05:10,150
‫prácticas y sugerencias sobre cómo

111
00:05:10,150 --> 00:05:14,009
‫mejorar los mecanismos de autenticación y autorización que implementamos.

112
00:05:14,009 --> 00:05:16,350
‫Entonces, lo primero que

113
00:05:16,350 --> 00:05:18,760
‫necesito repetir una y otra vez

114
00:05:18,760 --> 00:05:21,370
‫es que en una aplicación de producción,

115
00:05:21,370 --> 00:05:24,310
‫toda la comunicación entre el servidor y el

116
00:05:24,310 --> 00:05:26,980
‫cliente debe realizarse a través de HTTPS.

117
00:05:26,980 --> 00:05:30,010
‫De lo contrario, cualquiera puede escuchar la conversación

118
00:05:30,010 --> 00:05:32,520
‫y robar nuestro token web JSON.

119
00:05:32,520 --> 00:05:35,540
‫A continuación, cree siempre tokens de contraseña aleatorios.

120
00:05:35,540 --> 00:05:38,660
‫No generado a partir de fechas o algo así.

121
00:05:38,660 --> 00:05:40,920
‫Debido a que son efectivamente contraseñas

122
00:05:40,920 --> 00:05:43,470
‫y, por lo tanto, deben tratarse como tales.

123
00:05:43,470 --> 00:05:45,860
‫Además, siempre déles fechas de vencimiento,

124
00:05:45,860 --> 00:05:47,750
‫tal como lo implementamos.

125
00:05:47,750 --> 00:05:48,910
‫¿Está bien?

126
00:05:48,910 --> 00:05:52,340
‫Y también implementamos que un determinado token web JSON

127
00:05:52,340 --> 00:05:56,480
‫ya no es válido después de que el usuario haya cambiado su contraseña.

128
00:05:56,480 --> 00:05:58,660
‫Entonces, básicamente revocamos el token

129
00:05:58,660 --> 00:06:01,410
‫tan pronto como el usuario cambia la contraseña.

130
00:06:01,410 --> 00:06:04,070
‫Lo que tiene mucho sentido,

131
00:06:04,070 --> 00:06:07,650
‫pero de nuevo, muchos tutoriales simplemente no hacen eso.

132
00:06:07,650 --> 00:06:10,470
‫Otra gran cosa es nunca enviar un archivo

133
00:06:10,470 --> 00:06:14,060
‫de configuración, como para las variables de entorno, a un

134
00:06:14,060 --> 00:06:16,460
‫control de versión como Git.

135
00:06:16,460 --> 00:06:19,020
‫De hecho, no lo subas a ningún

136
00:06:19,020 --> 00:06:20,500
‫lado porque este archivo

137
00:06:20,500 --> 00:06:23,780
‫contiene los datos más sensibles de toda la aplicación.

138
00:06:23,780 --> 00:06:26,340
‫Por ejemplo, si alguien obtiene acceso a

139
00:06:26,340 --> 00:06:28,260
‫su secreto de token

140
00:06:28,260 --> 00:06:32,083
‫web JSON, todo su proceso de autenticación se verá comprometido.

141
00:06:32,083 --> 00:06:35,950
‫De acuerdo, y ahora solo un pequeño detalle es que

142
00:06:35,950 --> 00:06:37,560
‫cuando haya un

143
00:06:37,560 --> 00:06:40,560
‫error, no envíe el error completo al cliente.

144
00:06:40,560 --> 00:06:44,010
‫Por lo tanto, cosas como el seguimiento de la pila

145
00:06:44,010 --> 00:06:46,920
‫podrían brindarle al atacante información valiosa sobre su

146
00:06:46,920 --> 00:06:49,650
‫sistema y, por supuesto, no queremos eso.

147
00:06:49,650 --> 00:06:52,480
‫A continuación, podemos usar el paquete csurf para

148
00:06:52,480 --> 00:06:57,200
‫combatir un tipo de ataque llamado Cross-Site Request Forgery, que es un ataque

149
00:06:57,200 --> 00:06:59,750
‫que obliga a un usuario a

150
00:06:59,750 --> 00:07:03,530
‫ejecutar acciones no deseadas en una aplicación web en la

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

152
00:07:05,330 --> 00:07:07,600
‫Sin embargo, no haremos eso en esta sección.

153
00:07:07,600 --> 00:07:10,140
‫Pero todavía quería mencionarlo aquí.

154
00:07:10,140 --> 00:07:12,280
‫A continuación, podríamos requerir que el

155
00:07:12,280 --> 00:07:16,180
‫usuario se vuelva a autenticar antes de realizar una acción de alto valor.

156
00:07:16,180 --> 00:07:19,730
‫Por ejemplo, realizar un pago o eliminar algo.

157
00:07:19,730 --> 00:07:22,070
‫Nuevamente, esta es solo una sugerencia que

158
00:07:22,070 --> 00:07:23,810
‫puede probar usted mismo.

159
00:07:23,810 --> 00:07:26,630
‫Otra característica interesante que puede implementar es una

160
00:07:26,630 --> 00:07:29,460
‫lista negra de tokens que no son de confianza.

161
00:07:29,460 --> 00:07:31,660
‫Entonces, ya sabemos que realmente no

162
00:07:31,660 --> 00:07:34,910
‫existe una manera de cerrar la sesión de los usuarios de

163
00:07:34,910 --> 00:07:37,220
‫la aplicación si muestran alguna actividad maliciosa.

164
00:07:37,220 --> 00:07:41,260
‫Pero lo que podemos hacer es crear una lista de tokens no

165
00:07:41,260 --> 00:07:44,370
‫confiables que luego se validan en cada solicitud.

166
00:07:44,370 --> 00:07:47,920
‫Y a continuación, una función que podríamos haber implementado es confirmar la

167
00:07:47,920 --> 00:07:51,810
‫dirección de correo electrónico después de que se crea una cuenta por primera vez.

168
00:07:51,810 --> 00:07:54,665
‫Entonces, básicamente enviando un enlace al correo electrónico

169
00:07:54,665 --> 00:07:57,520
‫del usuario, como lo hacen muchas aplicaciones reales.

170
00:07:57,520 --> 00:08:00,190
‫Pero quería mantener las cosas simples aquí,

171
00:08:00,190 --> 00:08:02,600
‫por eso no hice esto aquí.

172
00:08:02,600 --> 00:08:05,400
‫Pero siéntase libre de implementarlo usted

173
00:08:05,400 --> 00:08:07,360
‫mismo si lo desea.

174
00:08:07,360 --> 00:08:09,900
‫Ahora, una gran característica que tienen muchas

175
00:08:09,900 --> 00:08:12,580
‫aplicaciones es el concepto de tokens de actualización.

176
00:08:12,580 --> 00:08:15,050
‫Que son básicamente para recordar a los usuarios.

177
00:08:15,050 --> 00:08:17,150
‫Por lo tanto, para mantenerlos conectados

178
00:08:17,150 --> 00:08:19,720
‫para siempre o hasta que decidan cerrar la sesión.

179
00:08:19,720 --> 00:08:22,170
‫Nuestra implementación actual hace que

180
00:08:22,170 --> 00:08:25,020
‫el usuario tenga que iniciar sesión nuevamente después

181
00:08:25,020 --> 00:08:27,480
‫de que expire el token web JSON.

182
00:08:27,480 --> 00:08:30,720
‫Pero, con los tokens de actualización, eso ya no es necesario.

183
00:08:30,720 --> 00:08:33,490
‫Y es un poco complejo de implementar, por lo que

184
00:08:33,490 --> 00:08:35,343
‫es una característica para otro momento.

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

186
00:08:37,950 --> 00:08:41,530
‫pudimos haber implementado es la autenticación de dos factores, con la

187
00:08:41,530 --> 00:08:43,770
‫que estoy seguro de que está familiarizado.

188
00:08:43,770 --> 00:08:46,079
‫Básicamente, con la autenticación de dos

189
00:08:46,079 --> 00:08:48,750
‫factores, después de iniciar sesión en la

190
00:08:48,750 --> 00:08:50,050
‫aplicación, el usuario

191
00:08:50,050 --> 00:08:53,110
‫debe realizar una segunda acción para autenticarse realmente.

192
00:08:53,110 --> 00:08:55,750
‫Y, por lo general, se trata de insertar

193
00:08:55,750 --> 00:08:58,980
‫un código enviado por mensaje de texto a un teléfono móvil.

194
00:08:58,980 --> 00:09:01,420
‫Entonces, estas son muchas funcionalidades que

195
00:09:01,420 --> 00:09:03,580
‫nuestra autenticación podría tener.

196
00:09:03,580 --> 00:09:05,730
‫Y si desea que implemente alguno de

197
00:09:05,730 --> 00:09:08,160
‫ellos, hágamelo saber en la sección de preguntas y respuestas.

198
00:09:08,160 --> 00:09:10,640
‫Y, si hay mucha demanda de uno de

199
00:09:10,640 --> 00:09:12,740
‫ellos, le mostraré cómo funciona.

200
00:09:12,740 --> 00:09:15,210
‫De acuerdo, pero de nuevo, no quería convertir

201
00:09:15,210 --> 00:09:17,270
‫este Node. js en

202
00:09:17,270 --> 00:09:20,760
‫un curso completo de seguridad y autenticación.

203
00:09:20,760 --> 00:09:24,230
‫Y para terminar, algo que implementaremos en el resto

204
00:09:24,230 --> 00:09:26,200
‫del apartado es evitar

205
00:09:26,200 --> 00:09:28,320
‫la contaminación de los parámetros.

206
00:09:28,320 --> 00:09:32,450
‫Por ejemplo, intente simplemente insertar dos parámetros de campo en la

207
00:09:32,450 --> 00:09:36,030
‫cadena de consulta que busca todos los recorridos.

208
00:09:36,030 --> 00:09:38,290
‫Y si lo hace, encontrará que habrá

209
00:09:38,290 --> 00:09:39,770
‫un error porque

210
00:09:39,770 --> 00:09:42,150
‫nuestra aplicación no está preparada para eso.

211
00:09:42,150 --> 00:09:45,790
‫Y así, los atacantes intentan utilizar este tipo de debilidades para

212
00:09:45,790 --> 00:09:49,330
‫bloquear aplicaciones, lo que, por supuesto, no es bueno.

213
00:09:49,330 --> 00:09:51,530
‫Y entonces, tenemos que arreglar eso.

214
00:09:51,530 --> 00:09:56,286
‫Bien, esto resultó ser mucho más largo de lo que esperaba.

215
00:09:56,286 --> 00:09:59,231
‫Y hay cursos completos sobre seguridad si

216
00:09:59,231 --> 00:10:01,560
‫realmente te gusta la seguridad.

217
00:10:01,560 --> 00:10:04,074
‫Está bien, pero lo dejo

218
00:10:04,074 --> 00:10:07,283
‫así, así que pasemos a la siguiente.