1
00:00:00,000 --> 00:00:06,000
Bueno, pues como te comentaba, voy a proceder a leerte la información.

2
00:00:06,000 --> 00:00:11,000
Buenas tardes, Alberto. Perdón.

3
00:00:11,000 --> 00:00:15,000
Buenas tardes, Antonio.

4
00:00:15,000 --> 00:00:22,000
Hoy, día 18 de enero, estamos convocados a través de jefatura de departamento para la defensa del modo profesional

5
00:00:22,000 --> 00:00:27,000
de proyecto del ciclo formativo de grado superior de administración de sistemas informáticos en red.

6
00:00:27,000 --> 00:00:34,000
Te informo que esta grabación se usará en el entorno cerrado de EDUCA Madrid

7
00:00:34,000 --> 00:00:39,000
con fines exclusivamente educativos y solo está a la disposición de los profesores evaluadores

8
00:00:39,000 --> 00:00:44,000
en el aula virtual para llevar a cabo la evaluación y calificación de la defensa del proyecto.

9
00:00:44,000 --> 00:00:50,000
En el aula virtual de proyectos habéis sido informados de los criterios y la rúbrica de calificación.

10
00:00:50,000 --> 00:00:53,000
El orden de la presentación del proyecto es el siguiente.

11
00:00:53,000 --> 00:01:02,000
15 minutos máximo para defender el proyecto y 5 minutos para preguntas por parte del tribunal si lo estima oportuno.

12
00:01:02,000 --> 00:01:07,000
Dicho esto, el tiempo de la exposición comienza a partir de este mismo momento.

13
00:01:07,000 --> 00:01:10,000
Adelante y venga, suerte.

14
00:01:10,000 --> 00:01:20,000
Buenas tardes y muchas gracias por atender a la presentación que voy a exponer.

15
00:01:20,000 --> 00:01:29,000
Voy a hablar sobre OWASP, análisis sobre las vulnerabilidades más comunes en la web.

16
00:01:37,000 --> 00:01:41,000
La presentación gira en torno a tres preguntas.

17
00:01:41,000 --> 00:01:47,000
¿Qué es OWASP? ¿En qué me conciene a mí como usuario de una web?

18
00:01:48,000 --> 00:01:53,000
¿Y por qué deberíamos respetar más los datos que nos identifican?

19
00:01:53,000 --> 00:01:58,000
Las dos últimas preguntas se contestarán solas a lo largo de la presentación.

20
00:02:02,000 --> 00:02:08,000
OWASP son las siglas en inglés de proyecto abierto de seguridad de aplicaciones web.

21
00:02:09,000 --> 00:02:21,000
Cada cuatro años, más o menos, realizan un documento con los 10 riesgos de seguridad más importantes en los servicios o aplicaciones web.

22
00:02:21,000 --> 00:02:24,000
Es un proyecto abierto y colaborativo.

23
00:02:24,000 --> 00:02:27,000
Todo el mundo puede aportar algo.

24
00:02:28,000 --> 00:02:42,000
De hecho, cada vez se debería aportar más porque las vulnerabilidades cada vez son más importantes y avanzan cada vez a pasos agigantados.

25
00:02:47,000 --> 00:02:51,000
¿Qué motivación y qué objetivos tiene este proyecto?

26
00:02:52,000 --> 00:02:59,000
La motivación esencial es la de divulgar y concienciar sobre la seguridad de la información en la web.

27
00:02:59,000 --> 00:03:06,000
No solo desde el punto de vista del usuario, sino también desde el punto de vista del desarrollador.

28
00:03:06,000 --> 00:03:12,000
Ya que es la primera línea de seguridad cuando tratamos las aplicaciones en la web.

29
00:03:13,000 --> 00:03:18,000
Por otra parte, el objetivo es analizar las vulnerabilidades más comunes.

30
00:03:19,000 --> 00:03:24,000
Saber identificarlas y proponer soluciones para su mitigación y mejorarlas.

31
00:03:29,000 --> 00:03:44,000
La metodología y herramientas a utilizar son, por una parte, tenemos el modelo cliente-servidor,

32
00:03:44,000 --> 00:03:51,000
que es el diagrama que más vamos a ver en los ataques.

33
00:03:53,000 --> 00:03:57,000
Que se trata de que nos conectamos a una web.

34
00:03:57,000 --> 00:04:04,000
Que la web nos puede proveer un servicio que sea de compra-venta de cualquier artículo.

35
00:04:04,000 --> 00:04:12,000
O simplemente poner un formulario, ya sea en una web como Hacienda o Correos.

36
00:04:13,000 --> 00:04:17,000
Y las herramientas a utilizar son las de Apache.

37
00:04:19,000 --> 00:04:23,000
O sea, las esenciales para crear un servidor web.

38
00:04:23,000 --> 00:04:28,000
Que pueden ser Apache, PHP, Yma y SQL como base de datos.

39
00:04:28,000 --> 00:04:34,000
Y sobre todo voy a utilizar los laboratorios de Postswigger, que son gratuitos.

40
00:04:34,000 --> 00:04:37,000
Que es de las herramientas de Wordfeed.

41
00:04:38,000 --> 00:04:47,000
Y en menor medida Python y un blog de notas para poder ejecutar el programa.

42
00:04:49,000 --> 00:04:53,000
La metodología va a ser la debilidad enumerada.

43
00:04:54,000 --> 00:04:57,000
El escenario vulnerable que se presentará.

44
00:04:58,000 --> 00:05:06,000
Y después de presentar el escenario se hará la explotación y mitigación de dicha vulnerabilidad.

45
00:05:08,000 --> 00:05:20,000
Aquí tenemos los 10 riesgos más vulnerables de la web de 2021.

46
00:05:20,000 --> 00:05:23,000
Porque han cambiado desde el 2017.

47
00:05:24,000 --> 00:05:33,000
Y se pretendía que en este año se saliese otro documento WAF.

48
00:05:33,000 --> 00:05:36,000
Pero todavía no se sabe la fecha.

49
00:05:37,000 --> 00:05:44,000
Y estas 10 vulnerabilidades son control de acceso inadecuado.

50
00:05:45,000 --> 00:05:51,000
Fallos criptográficos, inyección, diseño inseguro, configuración incorrecta de seguridad.

51
00:05:52,000 --> 00:05:55,000
Componentes vulnerables y obsoletas.

52
00:05:55,000 --> 00:05:58,000
Fallos de identificación y autentificación.

53
00:05:58,000 --> 00:06:01,000
Fallos de integridad de datos y software.

54
00:06:01,000 --> 00:06:04,000
Fallos en el registro y monitoreo de seguridad.

55
00:06:04,000 --> 00:06:07,000
Y falsificación de solicitudes del lado del servicio.

56
00:06:08,000 --> 00:06:16,000
Antonio, creo que después nos vas a mostrar una simulación de la 1, la 3, la 5, la 7 y la 10, ¿verdad?

57
00:06:16,000 --> 00:06:19,000
Sí, verdad. Eso iba a comentar.

58
00:06:19,000 --> 00:06:24,000
Como esta presentación se queda corta, digamos, en el tiempo.

59
00:06:24,000 --> 00:06:30,000
Pues voy a presentar la 1, la 3, la 5.

60
00:06:31,000 --> 00:06:35,000
Perdón, la 5, la 7 y la 10.

61
00:06:35,000 --> 00:06:36,000
¿Vale?

62
00:06:38,000 --> 00:06:39,000
Sí.

63
00:06:40,000 --> 00:06:43,000
Bueno, voy a seguir.

64
00:06:44,000 --> 00:06:45,000
Vale.

65
00:06:45,000 --> 00:06:52,000
Por otra parte, hay tres conceptos clave en el diseño y en el despliegue de pruebas que debemos conocer.

66
00:06:52,000 --> 00:07:00,000
Son las tres palabras claves estas de CVE, que es enumeración de debilidades comunes.

67
00:07:01,000 --> 00:07:05,000
Que clasifica los tipos de vulnerabilidades de software.

68
00:07:06,000 --> 00:07:12,000
O sea, trata la causa, por así decirlo, es una debilidad.

69
00:07:13,000 --> 00:07:17,000
CVE, que son las vulnerabilidades y exposiciones comunes.

70
00:07:17,000 --> 00:07:25,000
Que es un sistema que proporciona un método de referencia para la vulnerabilidad y exposición en seguridad conocida.

71
00:07:26,000 --> 00:07:32,000
Es decir, trata los síntomas y es una manifestación de CVE.

72
00:07:33,000 --> 00:07:39,000
Y, por último, es CVSS, que es un sistema común de puntuación de vulnerabilidades.

73
00:07:40,000 --> 00:07:44,000
Y clasifica la criticidad de dicha vulnerabilidad.

74
00:07:45,000 --> 00:08:00,000
Por poner un ejemplo, todo el mundo habrá visto que se ve, cuando se dice una vulnerabilidad, se ve CVE 2013 y un cuadro número.

75
00:08:01,000 --> 00:08:11,000
Pues eso es una manifestación de la debilidad que es el CVE con una puntuación que es el CVSS.

76
00:08:11,000 --> 00:08:25,000
Por cada categoría del documento WASP, voy a realizar la explotación de una debilidad CVE, venérica, siguiendo la metodología que antes mencioné.

77
00:08:26,000 --> 00:08:30,000
Que es el escenario de la vulnerabilidad, la explotación y la mitigación.

78
00:08:30,000 --> 00:08:39,000
Vale. La primera, que sería el control de acceso y, concretamente, sería la ruta transversal.

79
00:08:40,000 --> 00:08:43,000
El escenario que se presenta sería el siguiente.

80
00:08:44,000 --> 00:08:54,000
Tenemos una web que puede ser, como he dicho antes, un servicio que sea de compra-venta de un artículo.

81
00:08:54,000 --> 00:09:04,000
Actualmente, Comisiones Obreras fue atacada con esta vulnerabilidad y es conocida desde 2005.

82
00:09:05,000 --> 00:09:13,000
Y nos da una perspectiva de lo que debería avanzar la ciberseguridad en este aspecto.

83
00:09:13,000 --> 00:09:27,000
Y trata de… Perdón. Ataca fundamentalmente al vector de ataque de la entrada del usuario en la petición URL.

84
00:09:28,000 --> 00:09:43,000
Perdón. Ataca fundamentalmente al vector de ataque de la entrada del usuario en la petición URL.

85
00:09:43,000 --> 00:10:06,000
Un recurso PHP que tenemos, que tiene una función que coge un archivo, podemos apuntarla a un archivo del sistema.

86
00:10:07,000 --> 00:10:10,000
Aquí lo vemos más en profundidad.

87
00:10:11,000 --> 00:10:28,000
Si nos metemos en una web de compra-venta y añadimos… Bueno, añadimos no. Vemos la ruta, una imagen del producto.

88
00:10:28,000 --> 00:10:39,000
Vemos que la ruta es imagen interrogante file igual a 20.jpg. Ese archivo reside en el sistema.

89
00:10:40,000 --> 00:10:52,000
Y lo que podríamos hacer es, para que apunta a un archivo que esté dentro del sistema, sería retroceder en el directorio

90
00:10:52,000 --> 00:11:03,000
para ver si podemos apuntar a las raíces de las raíces. Poder apuntar a, por ejemplo, ETC, WD, que es donde residen las contraseñas del sistema.

91
00:11:04,000 --> 00:11:14,000
Y vemos que en este caso, como no está sanitizado, como vamos a ver en la miticación, podemos encontrar el archivo.

92
00:11:15,000 --> 00:11:28,000
Aquí proponemos una serie de mitigación que sería la de validar el input, que esta siempre la vamos a ver presente en los demás ataques.

93
00:11:29,000 --> 00:11:35,000
Y normalmente en las APIs tienen una función para hacer una ruta canónica.

94
00:11:36,000 --> 00:11:49,000
Y esta ruta canónica la podemos comparar con la ruta que nos da el usuario o hacerla canónica directamente con la API.

95
00:11:50,000 --> 00:11:56,000
Y así nos curamos en salud y no nos pueden atacar por este método.

96
00:11:57,000 --> 00:12:09,000
La siguiente inyección sería inyección XSS, que sería el XSS de cross-site scripting.

97
00:12:10,000 --> 00:12:37,000
Secuencia en sitios cruzados. Y trata de meter lenguaje de scripting, en este caso JavaScript, como hemos visto antes también en el ataque anterior, en la URL.

98
00:12:38,000 --> 00:12:42,000
Y esto es porque tampoco está sanitizado.

99
00:12:43,000 --> 00:12:55,000
La flotación de la vulnerabilidad en esta ocasión no he utilizado un laboratorio de Postgre como en el ataque anterior.

100
00:12:56,000 --> 00:13:12,000
Y he montado un servidor web con el HTML genérico que vemos en la izquierda y con el recurso PHP para que apuntase a un archivo.

101
00:13:13,000 --> 00:13:29,000
Vale. El archivo HTML es un formulario para que nos podemos encontrar en cualquier web.

102
00:13:30,000 --> 00:13:45,000
Y al no estar sanitizado y poder inyectar código JavaScript, podemos, bueno, en este ataque que he hecho, simplemente se ve una alerta y sale un pop-up con un 3.

103
00:13:46,000 --> 00:14:10,000
Pero el ataque cobra valor, digamos, porque si yo como atacante y otra persona como usuario, si yo meto el lenguaje de scripting y le sale a esa persona como usuario el pop-up,

104
00:14:11,000 --> 00:14:15,000
yo puedo tener la contraseña del otro usuario.

105
00:14:15,000 --> 00:14:39,000
La mitigación de XSH. Igual que antes, validar el input del usuario y que contenga caracteres esperados solamente y limitar la entrada a los caracteres de formulario.

106
00:14:40,000 --> 00:14:44,000
Por ejemplo, un campo de teléfono que sean números de X extensión.

107
00:14:45,000 --> 00:14:50,000
E intentar limpiar la entrada no válida para hacerla válida es más propenso a errores.

108
00:14:51,000 --> 00:15:03,000
Vale. Lo siguiente ataque sería configuración de seguridad incorrecta. Bueno, está mal puesto, perdón.

109
00:15:04,000 --> 00:15:28,000
Es XXG. Entidades de XML. Se trata de inyectar una entidad XML al documento para que apunte a una dirección dentro del sistema.

110
00:15:28,000 --> 00:15:35,000
Que en este caso sería el filename de tcpassword. Vale.

111
00:15:36,000 --> 00:15:49,000
En la petición, como estamos viendo aquí, que es un laboratorio de PostSuite, la web sería, como antes hemos visto también, una compra-venta de cualquier artículo.

112
00:15:50,000 --> 00:16:07,000
Una web de compra-venta. Y en la derecha vemos la intersección con PostSuite de la respuesta que nos da la web con la estructura XML.

113
00:16:08,000 --> 00:16:23,000
Como vemos aquí, lo he mandado al repite en PostSuite y lo que he hecho es crear una entidad XML para que apuntase a tcpassword.

114
00:16:24,000 --> 00:16:31,000
Y dentro de la estructura he apuntado a la dirección de X, que es la entidad que he definido.

115
00:16:32,000 --> 00:16:44,000
Y en la respuesta nos devuelve invalidProductId, porque no es el id correcto, pero nos vuelca todo el archivo de tcpassword.

116
00:16:45,000 --> 00:17:03,000
Y la mitigación de esta vulnerabilidad es deshabilitar la resolución de entidades externas XML que normalmente los desarrolladores por productividad de la empresa dejan y se convierte en un vector de ataque.

117
00:17:04,000 --> 00:17:11,000
Y la siguiente sería fallos de autenticación y fijación de sesión.

118
00:17:12,000 --> 00:17:17,000
El escenario este es simple también. También es un laboratorio de PostSuite.

119
00:17:19,000 --> 00:17:32,000
Antonio, una pregunta. ¿Has elegido cada laboratorio de pruebas en función de la regla OWASP, por las características que tiene o por qué otro criterio has elegido en cada caso un laboratorio u otro?

120
00:17:33,000 --> 00:17:41,000
Sí, es el laboratorio más genérico de cada, digamos, debilidad.

121
00:17:42,000 --> 00:17:59,000
Porque las debilidades, una cosa que no he dicho es que las categorías OWASP se hacen, digamos, que las empresas mandan a OWASP las debilidades que ellos enumeran en un producto

122
00:17:59,000 --> 00:18:06,000
y OWASP lo que hace es organizarlas según la afinidad que tienen las debilidades.

123
00:18:07,000 --> 00:18:17,000
Y en base a eso hace la categoría y cada categoría, como estamos viendo, tiene distintos vectores de ataque que son las vulnerabilidades.

124
00:18:18,000 --> 00:18:29,000
Y dentro de esa, por ejemplo, la fijación de sesión o la ruta transversal que hemos visto es una entre muchas que tiene esa categoría.

125
00:18:30,000 --> 00:18:42,000
Y la que he elegido es genérica, digamos, porque la de ruta transversal que hemos visto al principio de OWASP la tenían mucho.

126
00:18:42,000 --> 00:18:50,000
Ahora la tienen cada vez menos, menos comisiones obreras como hemos visto que sí la tuvo.

127
00:18:52,000 --> 00:19:01,000
Vale, la de fallo de autenticación de fijación de sesión tiene que ver con el doble factor de autenticación.

128
00:19:02,000 --> 00:19:16,000
Y es que muchos escenarios empresariales tienen doble factor, pero incluso en los dobles factor de autenticación tienen dos formas de autenticarse.

129
00:19:17,000 --> 00:19:33,000
Y normalmente cuando nosotros iniciamos sesión, como estamos viendo aquí en la diapositiva, nos mandan un código al correo que es el doble factor.

130
00:19:34,000 --> 00:19:47,000
Pero si tenemos las credenciales, porque se han filtrado en internet de un usuario o lo que sea, si esa web tiene un doble factor de autenticación,

131
00:19:47,000 --> 00:20:03,000
pero nosotros, como estamos viendo aquí en el laboratorio, tenemos el recurso que actualiza cuando nosotros metemos el primer factor, que en este caso es My Account.

132
00:20:04,000 --> 00:20:24,000
Si nosotros metemos las credenciales de la víctima, nos va a pedir el segundo factor de autenticación, pero podemos bypassearlo, saltárnoslo, poniéndolo directamente en la URL, el recurso My Account,

133
00:20:25,000 --> 00:20:31,000
y vemos que podemos acceder porque han fijado la sesión a la cookie del usuario.

134
00:20:34,000 --> 00:20:52,000
La parte de mitigación de esta vulnerabilidad sería implementar la autenticación multifactor, o sea, de varios factores para evitar ataques de fuerza bruta y ataques de contraseña que estén expuestas en internet.

135
00:20:53,000 --> 00:21:05,000
Ya sea por hackeo o por descuido del usuario porque lo haya puesto en Pastebin o GitHub o alguna plataforma.

136
00:21:06,000 --> 00:21:14,000
Implementar un sistema de contraseñas robusto y limitar los intentos de inicio de sesión para esto mismo, para que no hagan ataques de fuerza bruta.

137
00:21:14,000 --> 00:21:30,000
El último ataque sería falsificación de solicitudes del lado del servidor SSRF, en inglés, y esta categoría es nueva en este 2021, bueno, en el último documento,

138
00:21:31,000 --> 00:21:48,000
porque las empresas han enumerado muchas debilidades de esta parte y trata de que dentro de la infraestructura de la empresa, si nosotros tenemos en la DMZ de la web,

139
00:21:49,000 --> 00:22:04,000
pero dentro de esa web, dentro de esa infraestructura o dentro de esa máquina que sirve la web, hay otra tarjeta de red con un IP de la red interna.

140
00:22:05,000 --> 00:22:30,000
Nosotros, como atacantes, si accedemos al servidor web, pero aunque esté en la DMZ, si está dentro de la red interna, podemos apuntar a cualquier máquina de esa red que esté el servidor web.

141
00:22:30,000 --> 00:22:58,000
Vale, aquí vemos, esto es un laboratorio de Paul Swigert, que no he puesto, digamos, la portada, pero sería también, parecía, perdón, sería parecía a la de compra-venta y de producto.

142
00:23:01,000 --> 00:23:25,000
Y vemos aquí la respuesta que nos ofrece, porque lo hemos intercetado con WoodSuite y sería de stock API igual a HTTP tal, tal, tal y un chorraco, que sería, que estaría codificado en UTF-8, creo, sí, la barra y eso.

143
00:23:26,000 --> 00:23:44,000
Antonio, además de mostrarnos la presentación con las cinco reglas de Wasp que has elegido, ¿nos vas a mostrar algo más o sería, lo digo porque llevamos ya 25 minutos casi de exposición y por el tema del tiempo querías saber si vas a mostrar algo más?

144
00:23:45,000 --> 00:23:52,000
Bueno, sí, sería eso vía futura y conclusiones. Me queda en esta, ya.

145
00:23:53,000 --> 00:23:55,000
Vale, y ya, y con eso terminas.

146
00:23:55,000 --> 00:23:56,000
Sí, sí.

147
00:23:56,000 --> 00:23:57,000
Vale.

148
00:23:58,000 --> 00:24:06,000
Eh, vale, sería aquí, eh, vale, he dicho que está en UTF-8, vale.

149
00:24:07,000 --> 00:24:24,000
Eh, interceptando esto podemos aplicar un decodificado a esto, a el stock API igual a HTTP tal y poner HTTP localhost barra admin.

150
00:24:25,000 --> 00:24:31,000
Para que nos devolviese el HTML del panel de control del admin.

151
00:24:32,000 --> 00:24:56,000
Y así ver los recursos para, por ejemplo, borrar un usuario y con este recurso podemos ponerlo en la URL y a la derecha lo que vemos es que poniendo ese recurso en la, en la, perdón, en la URL, no, en la petición directamente,

152
00:24:56,000 --> 00:25:10,000
eh, nos responde con que un 302 found, o sea que ha borrado el usuario y con eso podemos explotar la vulnerabilidad.

153
00:25:11,000 --> 00:25:31,000
La mitigación de, de esta parte sería, sería como vemos aquí a nivel de cementar los recursos, eh, aplicar las políticas de firewall de negación por defecto y a nivel de aplicación sanitizar y validar todos los datos de entrada como hemos visto antes.

154
00:25:31,000 --> 00:25:38,000
Eso es, eh, es igual en casi todas, por no decir todas.

155
00:25:38,000 --> 00:25:59,000
Eh, la vía futura de, de esta es decir poco. O sea, yo me he imaginado un futuro en que la, la IA esté integrada en la herramienta de control y, y sean estas herramientas de aprendizaje automático y análisis automático de patrones de ataque.

156
00:26:00,000 --> 00:26:13,000
Eh, automatización de respuestas ante amenazas y predicción de posibles vulnerabilidades mediante sistema de análisis predictivo o proactivo. Y las conclusiones del, del proyecto serían.

157
00:26:13,000 --> 00:26:27,000
Sí, estamos, estamos fiando en todos los ámbitos, eh, mucho en las posibilidades de la, de la inteligencia artificial en el futuro. Es un arma de doble filo también porque según como se utilice, pues ya sabemos, ¿no?

158
00:26:28,000 --> 00:26:47,000
Claro, eh, a ver, actualmente han, hicieron, eh, como un chat GPT, pero enfocaba a ciberseguridad, a hacking, pero no le llega a la suela de los zapatos a un auditor porque todavía le queda mucho recorrido.

159
00:26:48,000 --> 00:27:09,000
Lo que sí es verdad es que, por ejemplo, con chat GPT, lo que, si tú dominas la rama, le puedes ir enfocando las preguntas y te responden más concisamente. Por ejemplo, los desarrolladores sí que lo utilizan mucho y actualmente las empresas sí que lo están utilizando para desarrollar.

160
00:27:09,000 --> 00:27:34,000
Pero eso sí, enfocándolo, como estoy diciendo, las preguntas muy concretas y conclusiones que la conclusión sería que hoy en día la seguridad en aplicaciones web es muy importante y las vulnerabilidades web pueden tener consecuencias graves para la confidencialidad, integridad y disponibilidad de los datos.

161
00:27:35,000 --> 00:27:56,000
O sea, la triada, eh, no se debe confiar directamente en la entrada del usuario, como hemos visto, porque siempre el usuario la caga, por así decirlo, porque mete cosas que no están previstas o siempre va a intentar saltarse algo.

162
00:27:57,000 --> 00:28:16,000
Y volviendo a las dos preguntas del principio, porque la primera era Wasp y ya se ha definido en qué me conciene a mí como usuario de una web y cómo los datos son propios, o sea, perdón, la pregunta sería en qué me conciene a mí como usuario de una web.

163
00:28:16,000 --> 00:28:34,000
Como los datos son propios, deben ser confidenciales y la integridad de ellos en el momento en que le accedemos estos datos a un tercero debe respetarse y deberían ser disponibles para restringir el uso de ellos si así lo deseamos.

164
00:28:34,000 --> 00:28:54,000
¿Y por qué deberíamos respetar más los datos que no identifican? Pues no sabemos qué persona o entidad va a hacer uso de ellos y con qué finalidad. Y, por último, dar las gracias por la atención recibida.

165
00:28:55,000 --> 00:29:16,000
Vale, Antonio. En cuanto a la mitigación de las vulnerabilidades, entiendo que hay medidas reactivas y medidas proactivas. Entonces, lo que interesa siempre es incrementar el número de proactivas, curarnos en salud, para no tener que aplicar las reactivas.

166
00:29:16,000 --> 00:29:35,000
Eso, ¿cómo está planteado dentro de las directivas de OWASP? Quiero decir, ¿qué porcentaje crees tú, a día de hoy, de las reglas OWASP que son reactivas y otras que son proactivas, que es el objetivo?

167
00:29:36,000 --> 00:29:55,000
Vale. Pues, actualmente yo creo que son más reactivas que proactivas. Proactivas serían una vez ya la amenaza, o sea, ya en sí lo atacaron, ¿no?

168
00:29:55,000 --> 00:30:10,000
No, al contrario. Proactivas se entiende como preventivas y reactivas como respuesta ya al ataque. El concepto es el contrario.

169
00:30:10,000 --> 00:30:28,000
Pues, preventivas serían, pues eso, como hemos visto, por ejemplo, en SSRF, sería segmentar los recursos de la infraestructura para acotar, digamos, la posible amenaza o vulnerabilidad.

170
00:30:29,000 --> 00:30:52,000
Y también sanitizar el código, aplicar a los desarrolladores concienciación de código seguro, que actualmente, por ejemplo, existe la figura de DevOps y hay ahora otra rama que sería la de DevSecOps, que sería DevOps, pero enfocada a seguridad.

171
00:30:53,000 --> 00:31:11,000
Que eso profundizaría en sanitización de código, que no hubiese buffer overflow, que no se pusiese variables donde no debería haberlas.

172
00:31:12,000 --> 00:31:21,000
O como hemos visto, lo de las entidades XML, que no se creasen entidades externas.

173
00:31:23,000 --> 00:31:29,000
Vale. Pues, dado que llevamos ya 31 minutos, nos hemos pasado el doble de lo que…

174
00:31:30,000 --> 00:31:31,000
Lo siento.

175
00:31:32,000 --> 00:31:39,000
No, no te preocupes. Lo único que tengo ahora otra a continuación, con otro alumno. O sea, quedamos por terminada la presentación, si te parece.

176
00:31:39,000 --> 00:31:40,000
Vale.