TFG Apolo

Universidad de Castilla-La Mancha
Escuela Superior de Ingeniería Informática
Trabajo Fin de Grado

Grado en Ingeniería Informática
Tecnología Específica de
Computadores
Entorno para el testeo de seguridad de

desarrollo web siguiendo buenas prácticas
Autor: Ramón Fuentes Montoya
Julio, 2022
Trabajo Fin de Grado
Grado en Ingeniería Informática
Tecnología Específica de
Computadores
Autor: Ramón Fuentes Montoya

Tutor: Enrique Arias Antúnez
Co-Tutor: José Antonio Mateo Cortés
Julio, 2022
Dedicado a mi familia y a todos
aquellos que me apoyaron
iii
Declaración de Autoría
Yo, Ramón Fuentes Montoya con DNI 49216169, declaro que soy el único autor del
trabajo fin de grado titulado “Entorno para el testeo de seguridad de desarrollo web
siguiendo buenas prácticas” y que el citado trabajo no infringe las leyes en vigor sobre
propiedad intelectual y que todo el material no original contenido en dicho trabajo está
apropiadamente atribuido a sus legítimos autores.
Albacete, a.....
Fdo: ......
v
Resumen
Este trabajo de fin de grado titulado "Entorno para el testeo de seguridad de desarrollo
web siguiendo buenas prácticas" se ha hecho con el propósito de diseñar un entorno fácil
de utilizar, que sea capaz de analizar una página web siguiendo buenas prácticas como
es la metodología “OWASP TOP 10” donde se contemplan los diez mayores riesgos de
seguridad de las páginas web a día de hoy. Para realizar este entorno se han revisado
otras herramientas con funcionalidades parecidas. Entre ellas están “Nessus”, “OWASP
ZAP” y “Burp Suite”, aunque la primera referencia será Nessus por su sencillez. El entorno
se ha desarrollado en Python 3 donde se ha usado “tkinter” para hacer la interfaz junto
con otras librerías orientadas al funcionamiento de cada uno de los escáneres y la
creación de reportes. El entorno analiza (divididos en escáneres) concretamente 5 riesgos
de la metodología del OWASP TOP 10. Además, cuenta con otro escáner dedicado a la
recopilación de información. Para concluir esta memoria se han realizado una serie de
pruebas donde se ha ejecutado cada escáner y se han comentado los resultados vertidos
en sus correspondientes reportes.
vii
Agradecimientos
Este proyecto va dedicado a todas aquellas personas que me han ayudado durante estos
5 años. A mis padres por apoyarme financiera y emocionalmente en todas aquellas
ocasiones en las que estuve a punto de tirar todo por la borda. A mi abuela por estar
siempre ahí velando por mí y por tratarme con el mismo cariño con el que lo haría una
segunda madre. A mis amigos por apoyarme y ayudarme como si fueran mis hermanos.
También debo darle las gracias a José Luis (profesor de ciberseguridad), por haberme
introducido en este mundo mediante su asignatura, porque sus clases fueron realmente
entretenidas. Por último, quiero dar las gracias a mis tutores de este proyecto por su
trabajo, tanto a Enrique Arias Antúnez como a José Antonio Mateo Cortés.
Gracias.
ix
Índice general
Capítulo 1 Introducción ______________________________________________ 1
1.1 Introducción________________________________________________________ 1
1.1.1 Conceptos Básicos _________________________________________________________ 3
1.2 Objetivo ___________________________________________________________ 5
1.3 Estructura del proyecto _______________________________________________ 5
Capítulo 2 Estado del Arte ____________________________________________ 7
2.1 Introducción________________________________________________________ 7
2.2 Metodologías _______________________________________________________ 8

2.2.1 OWASP __________________________________________________________________ 8
2.2.2 OWASP TOP 10 __________________________________________________________ 12
2.2.3 ISO 27001 _______________________________________________________________ 18
2.3 Herramientas del mercado ___________________________________________ 21

2.3.1 Nessus _________________________________________________________________ 21
2.3.2 OWASP _________________________________________________________________ 27
2.3.3 Burp Suite _______________________________________________________________ 34
2.4 Escáneres para nuestro proyecto ______________________________________ 38
Capítulo 3 Metodología y Desarrollo ___________________________________ 41
3.1 Introducción_______________________________________________________ 41
3.2 Metodología de desarrollo ___________________________________________ 41
3.3 Desarrollo del entorno_______________________________________________ 43

3.3.1 Parte analítica ___________________________________________________________ 43
3.3.2 Parte técnica ____________________________________________________________ 47
xi
Capítulo 4 Experimentos y Resultados _________________________________ 53
4.1 Introducción _______________________________________________________ 53
4.2 Pruebas realizadas __________________________________________________ 53
Capítulo 5 Conclusiones y Trabajo Futuro _______________________________ 71
5.1 Conclusiones ______________________________________________________ 71
5.2 Trabajo futuro _____________________________________________________ 75
Bibliografía __________________________________________________________ 76
Anexo I. Título del anexo ______________________ ¡Error! Marcador no definido.
I.1 Sección _________________________________________ ¡Error! Marcador no definido.
I.2 Sección _________________________________________ ¡Error! Marcador no definido.
xii
Índice de ilustraciones
Ilustración 1: Ransomware WannaCry [2]. .................................................................................................. 2

Ilustración 2: Noticia de la BCC sobre el hackeo en Twitter en 2020 [3]. .................................................... 2
Ilustración 3: Noticia sobre el impacto del cibercrimen [4] ......................................................................... 3
Ilustración 4. Acciones de un pentester [8]................................................................................................ 10
Ilustración 5. Pantalla Principal .................................................................................................................. 21
Ilustración 6. Escáneres de Nessus ............................................................................................................ 22
Ilustración 7. Flujo de trabajo de Nessus ................................................................................................... 22
Ilustración 8. Parámetros básicos (General) .............................................................................................. 23
Ilustración 9. Parámetros básicos (Schedule) ............................................................................................ 24
Ilustración 10. Parámetros básicos (Notifications) .................................................................................... 24
Ilustración 11. Discovery ............................................................................................................................ 25
Ilustración 12. Assessment ........................................................................................................................ 25
Ilustración 13. Report ................................................................................................................................ 26
Ilustración 14. Advanced............................................................................................................................ 26
Ilustración 15. Resultado del escáner (Hosts) ............................................................................................ 27
Ilustración 16. Resultado del escáner (Vulnerabilidades) .......................................................................... 27
Ilustración 17. Ventana inicial de OWASP ZAP .......................................................................................... 28
Ilustración 18. Escaneo automático (azul) y Manual (Verde). ................................................................... 28
Ilustración 19. Escaneo automático ........................................................................................................... 29
Ilustración 20. Ejemplo de un escaneo automático. .................................................................................. 29
Ilustración 21. Configuración del proxy en OWASP ZAP ............................................................................ 30
Ilustración 22. Generación del SSL ............................................................................................................. 30
Ilustración 23. Adición del certificado al navegador .................................................................................. 31
Ilustración 24. Configuración del proxy en el navegador (1) ..................................................................... 31
Ilustración 25. Configuración del proxy en el navegador (2) ..................................................................... 31
Ilustración 26. Escaneo manual ................................................................................................................. 32
Ilustración 27. Escaneo manual (navegador) ............................................................................................. 32
Ilustración 28. Añadir un diccionario ......................................................................................................... 32
xiii
Ilustración 29. Ejemplo de Ataque de fuerza bruta a directorios. ............................................................. 33
Ilustración 30. Solicitudes detenidas ......................................................................................................... 33
Ilustración 31. Selección de la contraseña. ................................................................................................ 33
Ilustración 32. Addición de la wordlist ....................................................................................................... 34
Ilustración 33. Dashboard de Burp Suite.................................................................................................... 35
Ilustración 34. Ventana de Proxy ............................................................................................................... 36
Ilustración 35. Ventana del Intruder .......................................................................................................... 36
Ilustración 36. Ventana del Repeater ......................................................................................................... 36
Ilustración 37. Ventana del Sequencer ....................................................................................................... 37
Ilustración 38. Ventana del Decoder .......................................................................................................... 37
Ilustración 39. Ventana del Comparer ....................................................................................................... 38
Ilustración 40. Pantalla principal ................................................................................................................ 48
Ilustración 41. Ventana de los escáneres ................................................................................................... 48
Ilustración 43. Ventana del Output (salida) ............................................................................................... 49
Ilustración 43. Ventana del historial .......................................................................................................... 49
Ilustración 44. Ejemplo de ventana de parámetros ................................................................................... 50
Ilustración 45. Creación de un nuevo hilo .................................................................................................. 50
Ilustración 46. Ejecución de los comandos ................................................................................................ 51
Ilustración 47. Parámetros del CSRF requeridos por el entorno ................................................................ 54
Ilustración 48. Resultado obtenido de CSRF .............................................................................................. 54
Ilustración 49. Parámetros del Path Trasversal requeridos por el entorno ............................................... 55
Ilustración 50. Resultado obtenido de Path Trasversal ............................................................................. 56
Ilustración 51. Parámetros de Testssl requeridos por el entorno .............................................................. 56
Ilustración 52. Resultado de Testssl ........................................................................................................... 57
Ilustración 53. Parámetros de Shcheck requeridos por el entorno ........................................................... 58
Ilustración 54. Resultado obtenido de shcheck ......................................................................................... 58
Ilustración 55. Parámetros de Hydra requeridos por el entorno ............................................................... 60
Ilustración 56. Parámetros de Hydra (listas) requeridos por el entorno ................................................... 61
Ilustración 57. Resultado obtenido de Hydra............................................................................................. 61
Ilustración 58. Parámetros de Lighthouse requeridos por el entorno ....................................................... 62
Ilustración 59. Resultado obtenido de Lighthouse..................................................................................... 63
Ilustración 60. Resultado obtenido de Lighthouse (Passed audits) ........................................................... 64
Ilustración 61. Resultado obtenido de Lighthouse (Trust and safety) ....................................................... 64
Ilustración 62. Parámetros de Dependency-check requeridos por el entorno .......................................... 65
Ilustración 63. Resultado obtenido de Dependency-check........................................................................ 65
Ilustración 64. Parámetros de Nmap requeridos por el entorno ............................................................... 67
Ilustración 65. Resultado obtenido de Nmap ............................................................................................ 67
Ilustración 66. Parámetros de Whatweb requerido por el entorno .......................................................... 67
xiv
Ilustración 67. Resultado obtenido de Whatweb ...................................................................................... 68
Ilustración 68. Parametros de theHarvester requeridos por el entorno ................................................... 69
Ilustración 69. Resultado obtenido de theHarvester ................................................................................. 69
Índice de tablas
Tabla 1. Herramientas para nuestro proyecto ........................................................................................... 38
xvii
Capítulo 1
Introducción
1.1 Introducción
A medida que pasa el tiempo, las páginas web van quedándose obsoletas no solo en
cuanto a su funcionalidad o estética, también en materia de seguridad, por lo que
necesitan estar continuamente actualizándose para evitar posibles brechas de seguridad.
Este punto es realmente importante, ya que las consecuencias de un posible ataque
pueden llegar a comprometer a la empresa y perjudicarla de diversas maneras, como,
por ejemplo, dejándola sin sus servicios durante un periodo de tiempo prolongado, con
todas las pérdidas económicas que esto supone; o filtrando información interna de la
infraestructura de la empresa, de sus directivos o incluso de toda la plantilla, siendo
susceptible de esta manera de cualquier tipo de chantaje por parte del atacante.
Aunque pueda dar la sensación de que estos problemas pertenecen más a una película
de Hollywood que a la realidad, hay casos de este tipo todos los días a lo largo del mundo,
y es que, en ocasiones, la ficción se materializa e incluso se supera.
Sin ir muy atrás en el tiempo, concretamente en 2017, se distribuyó el famoso
ransomware “WannaCry” que consiguió infectar a compañías de la talla de Telefónica o
Iberdrola e incluso al “Servicio Sanitario Nacional” de Reino Unido. Este ransomware
alcanzó un ritmo de 10000 ordenadores infectados por hora durante 4 días y supuso unas
pérdidas estimadas en 4000 millones de dólares estadounidenses [1].
1
2 Capítulo 1 Introducción
Ilustración 1: Ransomware WannaCry [2].

Sin ir tan lejos, también tenemos el reciente hackeo a 130 cuentas verificadas por Twitter
donde se acumularon más de 177 mil dólares estadounidenses en Bitcoin [3]. Entre las
cuentas robadas se encontraban las de Barack Obama, Bill Gates o incluso Elon Musk.
Ilustración 2: Noticia de la BCC sobre el hackeo en Twitter en 2020 [3].

Las pérdidas ocasionadas por el cibercrimen son auténticamente devastadoras. El
cibercrimen costó en 2019 más de 800000 millones de euros, lo que supone alrededor
del 1% del PIB mundial según la BBC [4]. Además, indica que el 92% de las compañías
confesaron sentir efectos negativos más allá de las pérdidas económicas.
Paradójicamente, a pesar del riesgo que supone el cibercrimen, el 56% de las empresas
cuestionadas confesaron no tener ningún tipo de plan preventivo.
1.1 Introducción 3
Ilustración 3: Noticia sobre el impacto del cibercrimen [4]

Cualquier persona, página web, empresa o gobierno, puede ser susceptible de un ataque
cibernético y es por eso por lo que es necesario tomar medidas para evitar este tipo de
catástrofes informáticas. Es necesario construir un software seguro y más tarde probar
dicha seguridad a través de expertos en el campo y es aquí donde entran los hackers
éticos o también denominados de sombrero blanco, que son especialistas en
ciberseguridad velan por mantener la seguridad de la información en la red.
1.1.1 Conceptos Básicos

Entrados ahora en materia, es necesario revisar algunos términos básicos referentes a la
seguridad informática para facilitar la comprensión del trabajo.
¿Qué es la ciberseguridad? ¿ Y la seguridad de la información?

La ciberseguridad consiste en “la protección de los activos de información frente a las
amenazas de la información procesada, almacenada y transportada por los sistemas de
información interconectados”.
La seguridad de la información se trata de “un conjunto de medidas preventivas y
reactivas” llevadas a cabo para proteger la información tanto física como digital de las
organizaciones.
Por lo tanto, la seguridad de la información se refiere tanto a la seguridad de la
información física como digital por lo que la ciberseguridad, que se refiere únicamente a
la protección de la información digital, que se encuentra encapsulada en la seguridad de

la información.
¿Qué es un pentest o prueba de penetración?

Su traducción es “prueba de penetración o de intrusión”, que consiste en la simulación
de un ataque cibernético por parte de un hacker ético y que se compone de una serie de
pruebas necesarias para poder violar la seguridad del objetivo que se somete a la prueba
de penetración. Las pruebas, generalmente, se dividen en las siguientes fases [5]:
– Recopilación de información. Consiste en obtener toda la información pública
accesible
– Enumeración o escaneo. Es el descubrimiento de aplicaciones o servicios del sistema
– Explotación. Se tratan de explotar las posibles vulnerabilidades encontradas.
– Escalado de privilegios. Esto consiste en tratar de obtener privilegios de otro usuario
(escalación horizontal) o intentar incrementar de alguna manera incrementar los
privilegios que se tienen en el sistema.
– Post-explotación. Una vez que se explotó el sistema, puede intentarse pivotar o
acceder a otro sistema, cubrir las huellas del ataque y hacer un reporte sobre la
prueba de penetración.
El objetivo de la prueba de penetración puede ir desde una página web, que es el tratado
en este trabajo, hasta la infraestructura de una empresa al completo y tiene como fin
simular un ataque, para conocer las debilidades del objetivo y poder protegerse a
posteriori de un posible ataque de un cibercriminal.
Existen 3 tipos de pruebas de penetración que varían en función a la información
proporcionada sobre el objetivo [6]:
– Caja blanca. Se dispone de toda la información sobre la infraestructura, sistemas y
aplicaciones por lo que se realiza un ataque que simula uno realizado por parte
alguien que conozca la empresa.
– Caja negra. En este caso no se dispone de información sobre la organización, por lo
que se simula un ataque producido por un ciberdelincuente externo a la empresa.
– Caja gris. Este tipo de una mezcla de los dos anteriores, ya que se dispone únicamente
de parte de la información.
1.2 Objetivo 5
1.2 Objetivo
El mundo de la ciberseguridad está dotado de una complejidad muy alta y requiere una
que el propio pentester se fusione con ese ambiente dado que la tecnología avanza y se
distribuye a la par que su vulnerabilidad y se expone cada vez más a posibles ataques de
crackers. Por esta razón, es necesario que todos conozcan la exposición a la que se
someten tanto en su vida privada, como en su vida laboral y es necesario que las personas
dispongan de un mínimo de conocimiento acerca de la fragilidad de su información y, por
ende, de su bienestar.
A pesar de lo importante que es disponer de cierta cultura de la ciberseguridad, es
entendible que no todo el mundo disponga del tiempo necesario y de la dedicación para
comprender este mundillo tan vertiginoso, además de estar continuamente actualizado
respecto a las diferentes vulnerabilidades que surgen cada día.
Estas razones son las que hacen que queramos crear una herramienta que democratice,
en cierto sentido, la capacidad para comprender la exposición a la que nuestras páginas
web están expuestas.
La misión en este Trabajo de Fin de Grado es comprender cómo analizar la seguridad de
una página web y, por lo tanto, visualizar sus posibles brechas de seguridad; comprender
cómo trabajan el resto de las herramientas del mismo tipo y a partir de este punto, crear
una herramienta adecuada para las personas que no disponen de los medios o
conocimientos para poder testear sus páginas web. Por ello, el objetivo es crear un
entorno amigable para cualquier persona que dispone de una página web, intentando
reducir de esta manera la complejidad del mundo de las pruebas de penetración web.
1.3 Estructura del proyecto
Este proyecto se encuentra dividido principalmente en 4 partes que son:

– Introducción.
– Estado del arte.
– Metodología y desarrollo.
– Casos prácticos.
– Conclusiones y trabajo futuro.
En el caso de la introducción, como se ha podido ver, se comienza con algunos datos

acerca de la importancia de la seguridad junto con algunos términos básicos necesarios
para comprender mejor este documento.
Durante el estado del arte se hablará sobre las metodologías de seguridad y buenas
prácticas empleadas para el desarrollo del entorno de este proyecto junto con
herramientas líderes en el mercado y otras herramientas capaces de satisfacer los análisis
que necesita el entorno.
Durante la metodología y desarrollo se hablará sobre la metodología de trabajo utilizada
y sobre las vulnerabilidades analizadas además de analizar técnicamente el entorno.
A lo largo de los casos prácticos se ejecutarán los escáneres del entorno y se hablará
sobre los resultados vertidos
En las conclusiones y trabajo futuro se añadirán algunos comentarios finales sobre el
proyecto además de algunas posibles mejoras del entorno a futuro
Capítulo 2 Estado
del Arte
2.1 Introducción
Aclarados ciertos conceptos en la introducción, se prosigue con el estado del arte, donde
será necesario hablar sobre las metodologías y buenas prácticas más comunes e
importantes en el campo de las pruebas de penetración web y que se tendrán en cuenta
de cara al desarrollo de una herramienta que automatice todos los procedimientos
incluidos en dichas metodologías.
Dado que ya existen herramientas que automatizan estos análisis y comprobaciones de
seguridad, será necesario indagar sobre las mismas de cara a desarrollar un modelo
propio basado en los puntos más interesantes de las metodologías contempladas en este
apartado. Se tendrán en cuenta las más relevantes y las que concuerden con las
metodologías aquí descritas. Siguiendo esta línea, deberán tenerse en cuenta, a su vez,
herramientas para realizar las pruebas necesarias para comprobar la seguridad de una
aplicación de acuerdo con las metodologías y buenas prácticas descritas.
7
8 Capítulo 2 Estado del Arte
2.2 Metodologías
Para poder llevar a cabo este entorno primero es necesario conocer ciertas buenas
prácticas a la hora de realizar una prueba de penetración a la página web en cuestión.
Existen una amplia gama de metodologías y buenas prácticas de seguridad, de entre
todas, serán tomadas las que son de código abierto y gratuitas por las ventajas que ello
conlleva.
2.2.1 OWASP
Se trata de una organización sin ánimo de lucro que proporciona información referente
a la seguridad informática de forma gratuita. OWASP aparte de aportar formación en este
ámbito, también ofrece guías y metodologías para hacer más robusto y seguro el
software:
– OWASP Top 10
– Guía de desarrollo de OWASP
– Guía de pruebas de OWASP (WSTG)
– Estándar de verificación de seguridad de aplicaciones OWASP ASVS
– OWASP Guía de pruebas de seguridad móvil (MSTG)
– Y un largo etcétera de documentación.
Como se puede ver, aporta incluso guías de cara a la seguridad de las aplicaciones móviles
(OWASP MSTG) que tanto desarrolladores, pentesters e incluso, usuarios finales, pueden
llegar a utilizar.
De entre toda esta documentación, interesa principalmente para este proyecto tanto la
“Guía de pruebas de OWASP” como el “OWASP Top 10”.
La “Guía de pruebas de OWASP” [7] contiene información básica sobre lo que es una
prueba de penetración y otros términos más generales, además de un apartado dedicado
al SDLC o el ciclo de vida del desarrollo de software (se indica qué medidas hay que tomar
durante el SDLC para construir un software seguro) y de un apartado sobre el testeo de
seguridad a aplicaciones web, que es en el que más relevante para este proyecto, ya que
indica cómo funciona la metodología OWASP:
2.2 Metodologías 9
Esta metodología trata de reunir todas las técnicas de testeo posibles y está enfocada
específicamente a pruebas de caja negra donde el tester no tienen ningún conocimiento
de la aplicación que va a testear.
El modelo de prueba se compone del tester que es el que lleva a cabo el testeo, de las
herramientas y metodología utilizadas para realizar el testeo y de la “caja negra” que va
a ser testeada.
Según esta metodología, el tester debe seguir un conjunto de acciones para realizar
correctamente las pruebas de una prueba de penetración web. Todas estas están
resumidas en un esquema proporcionado por OWASP y que es el que podemos ver a
continuación:
Ilustración 4. Acciones de un pentester [8].

2.2 Metodologías 11
La función del tester pasa primero por una recopilación de información sobre la empresa
(su infraestructura y web). Tras esto, se pasa por cada una de las pruebas que componen
la guía de OWASP (estas serán descritas a continuación brevemente). En caso de
encontrar una vulnerabilidad, se explota, de tal manera que se elabora una evaluación
sobre los riesgos que supone la existencia de esta en caso de que se consiga explotar esta
posible vulnerabilidad. El conjunto de pruebas de la guía de OWASP se repite hasta agotar
la posibilidad de encontrar riesgos y, por último, se crea un informe con los resultados
(vulnerabilidades encontradas y evaluación de las consecuencias e impacto en el servicio
web).
Se pueden dividir las pruebas realizadas en dos tipos de testing:

– Testing pasivo. Se intenta comprender la lógica y los puntos de acceso de la
aplicación. Estos se producen principalmente durante las pruebas de recopilación de
información.
– Testing Activo. Incluye las siguientes categorías de pruebas:
– Recopilación de Información. Esta fase se centra en obtener la mayor cantidad de
información posible del objetivo. Pueden utilizarse herramientas de acceso
público, escáneres y peticiones HTTP para forzar al objetivo y obtener información
a partir de mensajes de error u obtener versiones o la tecnología que usa.
– Pruebas de gestión de configuración de la infraestructura. Se realizan análisis
sobre la infraestructura de la Web para obtener datos importantes como el código
fuente, funcionalidades administrativas, métodos de autenticación, métodos
HTTP permitidos y configuraciones de la infraestructura.
– Comprobación del sistema de autenticación. La autenticación consiste en verificar
la identidad del remitente en una comunicación. Con estas pruebas se trata de
comprobar el sistema de autenticación, entender cómo funciona y
posteriormente intentar saltarse ese sistema de autenticación.
– Pruebas de gestión de sesiones. Son todas aquellas pruebas que tienen que ver
con cómo gestiona el sistema la interacción del usuario con la web. Esto lo hace
mediante el uso de un “identificador de sesión” (Session ID) o cookie al cual se
asocian las peticiones de un usuario determinado.
– Pruebas de autorización. La autorización consiste en permitir el acceso a los

recursos exclusivamente a los que tienen permiso para ello. Las pruebas de
autorización consisten en entender este sistema de autorización para intentar
saltárselo posteriormente, encontrar una vulnerabilidad de traspaso de rutas o
formas de escalar privilegios.
– Comprobación de la lógica de negocio. Pongamos que una aplicación lleva a
cabo el paso 1, 2 y 3. Un fallo de este tipo, sería que la aplicación no gestiona
que pueda saltarse uno de esos 3 pasos (por ejemplo, ir del 1 al 3 sin pasar
por el 2). Este tipo de fallos producidos en la lógica de negocio o el flujo de
trabajo son difíciles de detectar por parte de un escáner, ya que necesitan de
la creatividad del tester para descubrir fallos en la lógica, por lo que son
difíciles de automatizar.
– Pruebas de validación de datos. La falta de validación en las entradas
procedentes del cliente es una de las más comunes en las aplicaciones. En
este tipo de pruebas, se incluyen inyecciones SQL, inyecciones de código, XSS
y buffer overflow.
– Pruebas de denegación de servicio. Los ataques de denegación de servicio
consisten en la inundación de tráfico a una máquina objetivo, de manera que
esta es incapaz de sostener el volumen de peticiones por lo que se coarta a
usuarios de la máquina del acceso a sus servicios.
2.2.2 OWASP TOP 10
Las páginas web pueden tener una cantidad enorme de riesgos es por eso, que es
interesante contemplar aquellos que suponen un mayor problema por lo que es
necesario consultar el “OWASP Top 10” . Este es un documento que reúne los 10 riesgos
que suponen una mayor amenaza para las páginas web a día de hoy (la lista fue
actualizada a finales de 2021 por última vez)[9]. De estos 10 riesgos, OWASP decide los 8
que considera más importantes y los 2 restantes, son escogidos por parte de la
comunidad. A continuación, hablaré sobre cada uno de estos riesgos:
1. Broken Access Control [10]. Este tipo de riesgo está principalmente relacionado
con las siguientes vulnerabilidades: “CWE-352: Cross-Site Request Forgery
(CSRF)”, “CWE-200: Exposure of Sensitive Information to an Unauthorized Actor”,
“CWE-201: Insertion of Sensitive Information Into Sent Data”. El Access Control se
refiere a la política aplicada a cada usuario para determinar el acceso y permisos
que posee dentro de una página web, de manera que el Broken Access Control se
refiere a la posibilidad de un usuario de ir más allá de esta política, tal que puede
llevar a cabo acciones que no debería. Por ejemplo:
o Acceder a las capacidades de otros roles o usuarios.
o Elevación de privilegios. Actuar como un usuario sin haber iniciado sesión
o actuar como un administrador siendo un usuario corriente.
o Acceder a la API y poder realizar POST, PUT y DELETE.
o Forzar el buscador para acceder a paginas privilegiadas como un usuario
estándar.
Para evitar caer en este riesgo, es necesario, entre otras medidas:
o Denegar el acceso a los recursos no públicos.
o Implementar mecanismos de control de acceso y extenderlos a toda la
aplicación y minimizar el uso compartido de recursos.
o Registrar fallos de acceso en un log y advertir a los administradores en
caso de fallos repetidos o situaciones similares.
o Limitar el acceso a la API de manera que minimizamos los daños causados
por un ataque automatizado.
2. Cryptographic Failures [11]. Este tipo de riesgo está principalmente relacionado

con las siguientes vulnerabilidades: “CWE-261: Weak Encoding for Password”,
“CWE-327: Use of a Broken or Risky Cryptographic Algorithm”, “CWE-331:
Insufficient Entropy” . Tiene que ver con el uso de una criptografía pobre o incluso
inexistente a la hora de proteger ciertos datos importantes de una página web.
Por ejemplo, contraseñas, información personal, números de tarjeta de crédito,
etc. Para evitar caer en este riesgo, es necesario, entre otras medidas:
o Determinar qué información es sensible de acuerdo con las leyes de

privacidad pertinentes.
o Evitar la transmisión de datos en texto claro mediante protocolos como
HTTP, SMTP o FTP.
o Evitar el uso de algoritmos criptográficos débiles o antiguos
o Evitar el uso de claves predeterminadas
o Evitar almacenar innecesariamente información sensible.
o Encriptar todos los datos sensibles que se encuentren en reposo
3. Injection [12]. Este tipo de riesgo está principalmente relacionado con las
siguientes vulnerabilidades: “CWE-79: Cross-site Scripting”, “CWE-89: SQL
Injection”, y “CWE-73: External Control of File Name or Path”. Tiene que ver con
la inyección o introducción de código en el objetivo para, por ejemplo, acceder a
datos restringidos.
o Utilizar una API segura que evite usar completamente el intérprete.
o Utilizar validación del lado del servidor
o Utilizar LIMIT y otros controles SQL para limitar el número de datos
mostrados en caso de una inyección SQL
4. Insecure Design [13]. Este tipo de riesgo está principalmente relacionado con las
siguientes vulnerabilidades: “CWE-209: Generation of Error Message Containing
Sensitive Information”, “CWE-256: Unprotected Storage of Credentials”, “CWE-
501: Trust Boundary Violation”, “CWE-522: Insufficiently Protected Credentials”.
Tiene que ver con el diseño inseguro de la aplicación y aunque, en principio pueda
parecerlo, esta no es la causa del resto de riesgos, ya que vienen dados por una
implementación insegura, que no es lo mismo. El diseño es una parte
importantísima, porque un diseño seguro puede tener una implementación
insegura, que puede ser reparada, pero una implementación perfecta de un
diseño inseguro es mucho más difícil de reparar porque es un problema de raíz.

o Utilizar un ciclo de vida de desarrollo del software seguro.
o Limitar el consumo de recursos de los usuarios o servicios
o Utilizar una librería de patrones de diseño seguros
o Establecer pruebas unitarias y de integración.
5. Security Misconfiguration [14]. Este tipo de riesgo está principalmente

relacionado con las siguientes vulnerabilidades: “CWE-16 Configuration“ y “CWE-
611 Improper Restriction of XML External Entity Reference”. Tiene que ver
principalmente con una configuración insegura, por ejemplo:
o La presencia de funciones innecesarias (servicios, puertos, privilegios,
páginas etc.)
o La presencia de cuentas y contraseñas por defecto que no han sido
cambiadas
o El software no está actualizado y por lo tanto puede ser vulnerable
o El control de errores revela más información de la que debería.
Algunas maneras de afrontar este riesgo son:
o Reducir al mínimo características y componentes innecesarios
o Establecer un proceso automatizado para probar la eficacia de las
configuraciones y ajustes de los entornos
6. Vulnerable and Outdated Components [15]. Este tipo de riesgo está

principalmente relacionado con la siguiente vulnerabilidad: “CWE-1104: Use of
Unmaintained Third-Party Components”. Este riesgo puede estar presente si:
o Si se desconoce la versión de todos los componentes que se utilizan
o Si el software no está actualizado y si no se actualiza regularmente
o Si el framework y las dependencias utilizadas no están actualizadas
o Si los desarrolladores del software no comprueban la compatibilidad de
las librerías que han sido actualizadas

o Eliminar dependencias no utilizadas y funciones, componentes o archivos
o documentación no necesaria.
o Comprobar que los componentes y librerías están actualizadas y que
reciben actualizaciones regularmente
o Solo obtener componentes de fuentes oficiales y seguras
o Hacer inventario de las versiones de los componentes y sus dependencias
tanto del lado del cliente como del servidor.
7. Identification and Authentication Failures [16]. Este tipo de riesgo está

principalmente relacionado con las siguientes vulnerabilidades: “CWE-297:
Improper Validation of Certificate with Host Mismatch”, “CWE-287: Improper
Authentication” y “CWE-384: Session Fixation”. Tiene que ver con la identificación
del usuario, la administración de la sesión y la autenticación. Se es vulnerable a
este tipo de riesgo si:
o Se permite ataques como el relleno de credenciales sirviéndose de una
lista de nombres de usuario y contraseñas.
o Se permite ataques de fuerza bruta
o Se permite introducir contraseñas con una complejidad escasa
o Se posee una autenticación multifactorial pobre.
o La recuperación de credenciales es débil.
o Se muestra el identificador de sesión en la URL.
o Se reutiliza el identificador de sesión tras un inicio de sesión.
o Los tokens de autenticación no son invalidados tras un cierre de sesión.
Algunas maneras de afrontar este riesgo son:
o Implementar la autenticación multifactorial para evitar el relleno de
credenciales automático, los ataques de fuerza bruta y los ataques
basados en reutilizar credenciales robadas.
o Añadir comprobaciones de contraseñas débiles.
o Limitar el número de intentos de inicio de sesión.
8. Software and Data Integrity Failures [17]. Este tipo de riesgo está principalmente
relacionado con las siguientes vulnerabilidades: "CWE-829: Inclusion of
Functionality from Untrusted Control Sphere", "CWE-494: Download of Code
Without Integrity Check" y "CWE-502: Deserialization of Untrusted Data". Se
produce debido a que el código e infraestructura no son capaces de proteger al
software y datos frente a violaciones de la integridad. Para entenderlo, es
necesario aclarar en qué consiste la integridad. Esta es la condición por la cual la
información se mantiene precisa y consistente durante el almacenamiento,
transmisión o uso, a no ser que la modificación sea autorizada. Un fallo a destacar
tiene que ver con el empleo de actualizaciones automáticas donde no se verifica
dicha actualización, ya que un posible atacante puede cargar sus propias
actualizaciones.
Algunas medidas para prevenir este riesgo son:
o Utilizar mecanismos para verificar que el software o datos provienen de
una fuente fiable y no fueron adulterados.
o Establecer un proceso de revisión de cambios en el código y configuración.
o Comprobar que las librerías y dependencias utilizan repositorios de
confianza.
9. Security Logging and Monitoring Failures [18]. Este tipo de riesgo está
principalmente relacionado con las siguientes vulnerabilidades: “CWE-117
Improper Output Neutralization for Logs”, “CWE-223 Omission of Security-
relevant Information”, and “CWE-532 Insertion of Sensitive Information into Log
File”. Tiene que ver con la incapacidad de detectar brechas de seguridad debido
a la escasez o ausencia de detección, monitorización y registro de eventos (inicios
de sesión, errores etc.). También tiene que ver con el almacenamiento de
información sensible en los logs, ya que la información podría quedar expuesta
en un ataque.
Algunas medidas para prevenir este riesgo son:
o Asegurarse de que los inicios de sesión, el control de acceso y la validación

del lado del servidor se registran correctamente
o Asegurarse que los datos de los logs están codificados correctamente para
evitar posibles inyecciones
o Establecer un plan de respuesta y recuperación frente a incidentes.
10. Server-Side Request Forgery [19]. Este tipo de riesgo está principalmente
relacionado con las siguientes vulnerabilidades: "CWE-918: Server-Side Request
Forgery (SSRF)". Esta vulnerabilidad consiste en, como dice su nombre, falsificar
solicitudes del lado del servidor. Se produce debido a que la web en cuestión
obtiene un recurso sin validar la URL dada por el usuario, tal que el atacante
puede enviar solicitudes a un dominio elegido por él mismo. Esto permite, entre
otras cosas, obtener información de la red interna de la organización en cuestión,
pudiendo baipasear fácilmente los firewalls existentes.
Algunas medidas para afrontar este riesgo son:
o Segmentar el acceso remoto a los recursos en redes separadas para
reducir las consecuencias del SSRF
o Tratar de denegar por defecto las políticas del firewall, excepto para el
tráfico esencial de la intranet
o Validar y sanitizar los datos proporcionados por los usuarios
o Desactivar las redirecciones HTTP
2.2.3 ISO 27001
Es una norma internacional que provee de los requisitos para el establecimiento,

implementación, mantenimiento y mejora de un SGSI o Sistema de Gestión de la
Seguridad de la Información [20].
Según la ISO 27000, un Sistema de Gestión de la Seguridad de la Información es “el
conjunto de políticas, procedimientos y directrices junto a los recursos y actividades
asociados que son administrados colectivamente por una organización, en la búsqueda
de proteger sus activos de información esenciales”. Este sistema trata de preservar la

confidencialidad, integridad y disponibilidad de la información de la organización. El
establecimiento de este sistema debe adaptarse a las necesidades, objetivos, requisitos
de seguridad, procesos, tamaño y estructura de la organización.
Según esta norma, la organización en cuestión debe de tener en cuenta los siguientes
puntos [20, 21]:
Contexto de la organización. La organización debe determinar:
– Las cuestiones externas e internas pertinentes y el alcance del SGSI,
– Las partes interesadas existentes para el SGSI y sus requisitos para la seguridad de la
información.
Liderazgo. La alta dirección debe implicarse y mostrar liderazgo y compromiso con el
SGSI, asegurando que se establecen las políticas y objetivos de seguridad de la
información, asegurando que los recursos para el SGSI están disponibles, asegurando que
el SGSI logra los resultados esperados, promoviendo la mejora continua del SGSI etc.
También debe establecer una política de la seguridad de la información adecuada al
propósito de la organización además debe asegurar que se asignen unas
responsabilidades y autoridades para los roles de la seguridad de la información.
Planificación. En la planificación del SGSI debe tenerse en cuenta el contexto de la
organización y deben determinarse los riesgos a tratar mediante un proceso de
apreciación de riesgos de seguridad de la información, además de establecerse las
acciones para tratarlos mediante su correspondiente proceso de tratamiento de riesgos
de la seguridad de la información y evaluar estas acciones. La organización debe
establecer también unos objetivos de seguridad de la información y planificación para su
consecución. Para establecer los objetivos hay que saber:
– Qué se va a hacer.
– Los recursos requeridos.
– El responsable.
– Su duración.
– Cómo se van a evaluar los resultados obtenidos.
Estos objetivos deben:
– Ser medibles.
– Coherentes con la política de seguridad de la información.
– Tener en consideración los riegos apreciados, su tratamiento y los requisitos de

seguridad de la información aplicables.
– Ser comunicados.
– Ser actualizados.
Soporte. La organización debe:
– Proporcionar los recursos necesarios para el SGSI.
– Determinar la competencia de las personas que tienen un trabajo que afecta a la
seguridad de la información y asegurarse de que sean competentes.
– Asegurarse de que los trabajadores son conscientes de las políticas de la seguridad
de la información, de su contribución a la eficacia del SGSI y de las consecuencias de
no cumplir sus requisitos.
– Determinar la necesidad de unas comunicaciones internas y externas
correspondientes con el SGSI que dicten quién debe comunicar, cuándo comunicar,
a quién comunicar y los procesos por los que debe pasar la comunicación.
– Incluir, en el SGSI, información documentada requerida por la ISO e información que
la organización cree necesaria para gestionar la seguridad de la información.
Operación. La organización debe planificar, implementar, y controlar todos los procesos
que sean necesarios para cumplir los requisitos de la seguridad de la información al igual
que debe implementar planes para alcanzar los objetivos de la seguridad de la
información. Entre los procesos mencionados, se encuentra la apreciación de los riesgos
de seguridad de la información y su tratamiento.
Evaluación del desempeño. Es necesario que la organización realice una evaluación del
desempeño de la seguridad de la información y de la eficacia del SGSI. Para ello, la
organización debe llevar a cabo auditorías internas en intervalos planificados para
determinar si el SGSI cumple los requisitos de la organización y de esta norma, además
debe revisar el propio SGSI periódicamente para asegurar su conveniencia, adecuación y
eficacia continuas.
Mejora. La organización debe tratar de reaccionar ante las no conformidades (dónde no
se está cumpliendo la norma) tratando de controlarlas, corregirlas y afrontando a las
posibles consecuencias. Es importante también que se busque una mejora continua de
la idoneidad, adecuación y eficacia del SGSI
2.3 Herramientas del mercado 21
2.3 Herramientas del mercado
En este apartado se hablará sobre las herramientas que se tomarán de referencia para
hacer la de este proyecto. Estas herramientas suelen ser de pago dado la sencillez de uso
y el valor que aportan en una prueba de penetración.
2.3.1 Nessus
Nessus es un software de escaneo de vulnerabilidades desarrollado por Tenable, Inc. Este

software tiene 3 versiones disponibles: Nessus Essentials, Nessus Profesional y Tenable.
Nessus Essentials es la versión gratuita y la que trataremos aquí.
Cuando accedemos a Nessus, nos encontramos el siguiente panel (Ilustración 5):
Ilustración 5. Pantalla Principal

En este panel, podemos ver a la izquierda un acceso a nuestros escáneres, a una papelera
de reciclaje, una sección de políticas, para definir conjuntos de escáneres de forma
personalizada; una sección para establecer la gravedad de los plugin (programas que
realizan las pruebas que utiliza Nessus para evaluar las vulnerabilidades) utilizados y
“Terrascan” que es un escáner para infraestructuras como código.
El panel más interesante es el de los escáneres (“My scans”). Aquí se puede ver los
escáneres que, creados, importar uno o incluso crear uno nuevo.
Si se va a crear uno nuevo, están disponibles los siguientes escáneres (Ilustración 6):
Ilustración 6. Escáneres de Nessus

Como se puede observar, hay algunos escáneres que no están disponibles, ya que esta
es la versión gratuita, sin embargo, de cara a hacer una prueba de penetración web, no
se va a necesitar todos y entre los que no se necesitan se incluyen los de la versión de
pago. De todos los escáneres que Nessus tiene disponibles, el más interesante es el de
“Web Applications tests”. Para realizar este escáner, debe procederse de la siguiente
manera (Ilustración 7):
Ilustración 7. Flujo de trabajo de Nessus

Nessus sigue el mismo flujo de trabajo para poder realizar un escaneo de cualquiera de
los que tiene disponibles, es decir, primero se realiza una definición de parámetros del
escáner, luego se crea el propio escáner, luego ser ejecuta el escáner y, por último, se
analizan los resultados obtenidos del lanzamiento del escáner. A continuación, veremos
estos pasos en profundidad:
1. Definición de parámetros. Este paso, de divide en varios tipos de parámetros. Los

básicos (Basic), los de descubrimiento (Discovery), los de evaluación (Assessment),
los del reporte (Report) y otros parámetros más avanzados (Advanced).
a. Basic. Este a su vez se subdivide en:
i. General. Que contiene el nombre del escáner, una descripción del
mismo, el directorio donde va a guardarse, y la dirección del
objetivo (IP, URL, etc.) (Ilustración 8).
ii. Schedule. Nos permite establecer la frecuencia con la que
queremos que se realice el análisis (Ilustración 9).
iii. Notifications. Nos brinda la posibilidad de enviar el resultado de
los escáneres a unos correos determinados (Ilustración 10).
Ilustración 8. Parámetros básicos (General)

Ilustración 9. Parámetros básicos (Schedule)
Ilustración 10. Parámetros básicos (Notifications)

b. Discovery. En este apartado podemos escoger si queremos que se
escaneen los puertos más comunes, todos los puertos o podemos escoger
los que queramos con la opción custom.
Ilustración 11. Discovery

c. Assessment. Aquí podemos escoger el nivel de exhaustividad del escaneo,
es decir, si queremos que el escáner se haga a vulnerabilidades conocidas
o a todas las vulnerabilidades en una versión más rápida o compleja.
Además, también volvemos a tener una opción donde podemos
customizar algunas opciones para el escaneo.
Ilustración 12. Assessment

d. Report. En este apartado nos proporcionan algunas opciones referentes al
reporte.
Ilustración 13. Report
e. Advanced. Aquí tenemos opciones de cara a personalizar el rendimiento

con el que queremos que se realice el análisis.
Ilustración 14. Advanced
Una vez que se rellenan los parámetros, solo resta crear el escáner y, posteriormente,
ejecutar el análisis.
Como último paso queda revisar los resultados que ha obtenido el escáner. En las dos
siguientes imágenes podemos ver los hosts a los que se aplicó en escáner (Ilustración 15)
y las vulnerabilidades encontradas ordenadas por su criticidad (Ilustración 16).
Ilustración 15. Resultado del escáner (Hosts)
Ilustración 16. Resultado del escáner (Vulnerabilidades)
2.3.2 OWASP
Esta es una herramienta desarrollada en Java y lanzada en 2010 por la organización de

OWASP. Se basa en la metodología de OWASP, ya que esta desarrollada por esta misma
organización y, por consiguiente, contempla el OWASP Top 10. Es algo diferente a Nessus,
además de cumplir la función de escáner de vulnerabilidades (escáner pasivo y
automático), también posee otras características adicionales:
- Servidor proxy. Puede actuar como un servidor proxy, de manera que permite
identificar las peticiones y respuestas generadas por el navegador para así poder
manipularlas.
- Fuzzing. Se trata de la inyección de datos malformados de forma automatizada

con el objetivo de encontrar errores. También suele utilizarse para realizar
ataques de fuerza bruta a logins o para el descubrimiento de directorios.
OWASP ZAP a diferencia de NESSUS y de otras herramientas, no es de pago, por lo que

esto supone una gran ventaja. Así se presenta OWASP ZAP al abrir la aplicación:
Ilustración 17. Ventana inicial de OWASP ZAP

En esta ventana tenemos a la izquierda un panel con el mapa del sitio que nuestros
escaneos han extraído de las páginas web analizadas, en el panel de abajo, los GET y POST
generados además de las alertas (vulnerabilidades) encontradas durante el análisis y en
el centro, tenemos un acceso directo a un escaneo automático o manual (Ilustración 18).
Ilustración 18. Escaneo automático (azul) y Manual (Verde).
Escaneo automático
Si clicamos en el icono azul, se nos presenta la siguiente ventana (Ilustración 19):
Ilustración 19. Escaneo automático

Aquí podemos introducir la página web a escanear, con quien usaremos las spider
scanners que consiste en un escaneo pasivo con el que se enumeran los links y directorios
de la página web objetivo. Por último, para iniciar el ataque, basta con presionar el botón
“Attack”.
Ilustración 20. Ejemplo de un escaneo automático.

Como podemos ver (Ilustración 20), en el panel de arriba a la izquierda tenemos el mapa
del sitio obtenido, abajo los alerts y GET y POST producidos por las arañas y el escaneo
activo y en el medio tenemos las cabeceras y el cuerpo de la página que escojamos en el
panel de la izquierda.
Escaneo manual
Para este escaneo, primero necesitamos configurar el proxy. Vamos a Tools>Local Proxies
y ponemos como address 127.0.0.1 (Ilustración 21).
Ilustración 21. Configuración del proxy en OWASP ZAP

Luego hay que añadir el certificado SSL al navegador. Primero tenemos que generar el
Certificado en el apartado “Dynamic SSL” que se encuentra también en Tools>Options
(Ilustración 22).
Ilustración 22. Generación del SSL

Luego, añadimos el certificado al navegador (Ilustración 23).
Ilustración 23. Adición del certificado al navegador

Por último, configuramos el proxy en el navegador (Ilustración 24 y 25).
Ilustración 24. Configuración del proxy en el navegador (1)
Ilustración 25. Configuración del proxy en el navegador (2)
Existe otra opción para ahorrar la configuración manual del proxy. En este caso tenemos
que clicar en el icono verde (Ilustración 18). Como consecuencia obtenemos la siguiente
pantalla (Ilustración 26):
Ilustración 26. Escaneo manual

Posteriormente obtenemos la misma ventana que con la primera forma, pero con el
navegador seleccionado (Ilustración 27):
Ilustración 27. Escaneo manual (navegador)

Desde esta ventana OWASP ZAP nos proporciona acceso a los diferentes escáneres que
posee y que vimos en el escáner automático.
Fuerza bruta a directorios
Este consiste en un ataque de fuerza bruta para obtener los directorios de una página
web mediante el uso de un diccionario con lo que se consigue el acceso a páginas que no
se encuentran indexadas y que no pudieron descubrirse mediante un escaneo pasivo.
Para hacer este ataque, podemos escoger el diccionario que deseemos. Para ello, vamos
a Tools>Options>Forced Browse y ahí podemos añadirlo (Ilustración 28).
Ilustración 28. Añadir un diccionario

También podemos escoger el número de hilos que queremos utilizar.

Para hacer el ataque basta con hacer clic derecho en la página del mapa de sitio que
queramos, y vamos a Attack>Force Browse Directory. En la siguiente imagen tenemos un
ejemplo (Ilustración 29):
Ilustración 29. Ejemplo de Ataque de fuerza bruta a directorios.
Fuerza bruta a logins

Para hacer una fuerza bruta a un login, primero debemos tener activado el proxy y
detener las solicitudes como se muestra en la siguiente imagen (Ilustración 30):
Ilustración 30. Solicitudes detenidas
Posteriormente hacemos un inicio de sesión con un usuario y contraseña, localizamos el

POST realizado en OWASP ZAP y seleccionamos la contraseña (Ilustración 31):
Ilustración 31. Selección de la contraseña.

Y, por último, añadimos la wordlist (pulsando en Cargas>Ingresar) e iniciamos el ataque
(Ilustración 32).
Ilustración 32. Addición de la wordlist
OWASP ZAP es una herramienta muy útil además de gratuita, lo que supone una ventaja
muy grande respecto a otras herramientas que tienen una funcionalidad muy parecida
pero que se encuentran limitadas por una versión premium.
2.3.3 Burp Suite
Esta herramienta esta desarrollada por la empresa PortSwigger y está escrita en Java [22].
Es una herramienta ampliamente usada por hackers profesionales, ya que proporciona
un amplio abanico de funciones . Burp Suite posee distintas versiones, la más básica es
Burp Suite Community que es la versiona gratuita y, por lo tanto, limitada y también
dispone de la versión Professional y la Enterprise.
Burpsuite profesional se compone de:
– Un escáner automático de vulnerabilidades
– Un fuzzer que cuya velocidad no se encuentra limitada
– Generación de reportes
– Acceso sin restricciones a nuevas extensiones
– Acceso a Burp Suite Collaborator
Burp Suite Enterprise está destinada para la realización de escaneos recurrentes. Posee
un escáner automatizado que se puede configurar para que se produzca periódicamente
de una manera muy parecida a Nessus tal y como vimos previamente.
Al abrir Burp, nos encontramos con el siguiente dashboard (Ilustración 33):
Ilustración 33. Dashboard de Burp Suite

El panel de las tareas (Tasks) (recuadro en rojo de la imagen anterior), está destinado a
la definición de tareas que Burp Suite puede ejecutar en segundo plano. En la versión
gratuita solo tiene disponible el “Live passive crawl” que registra las páginas que visitamos
mediante el proxy. En la versión de pago permite establecer escáneres.
En el panel de la derecha (recuadro en fucsia de la imagen anterior) tenemos un registro
de las vulnerabilidades encontradas por los escáneres automáticos (solo disponible en la
versión de pago).
En el panel de abajo a la izquierda (recuadro en verde de la imagen anterior) nos dice que
está haciendo Burp Suite actualmente. En la imagen puede apreciarse que nos indica que
Burp Suite ha iniciado el proxy.
En el panel de abajo a la derecha (recuadro en azul de la imagen anterior) Burp Suite
indica información sobre las vulnerabilidades encontradas en el panel de arriba.
En la parte de arriba, junto a la pestaña del dashboard tenemos acceso a las principales
características que son las siguientes:
– Proxy. Permite interceptar y modificar peticiones y respuestas de aplicaciones web (
Ilustración 34).
Ilustración 34. Ventana de Proxy

– Intruder. Permite realizar ataques de fuerza bruta, sin embargo, se encuentra
bastante limitado en la versión gratuita de Burp (Ilustración 35).
Ilustración 35. Ventana del Intruder

– Repeater. Permite capturar, modificar y reenviar varias veces la misma petición
(Ilustración 36).
Ilustración 36. Ventana del Repeater

– Sequencer. Se utiliza para evaluar la aleatoriedad de tokens como las session cookies
u otro tipo de dato generado aleatoriamente (Ilustración 37).
Ilustración 37. Ventana del Sequencer

– Decoder. Permite decodificar o codificar en URL, HTML, Base64, ASCII hex, Hex, Octal,
Binary y GZIP (Ilustración 38).
Ilustración 38. Ventana del Decoder

– Comparer. Permite comparar dos datos tanto a nivel de palabra como de byte
(Ilustración 39).
Ilustración 39. Ventana del Comparer
2.4 Escáneres para nuestro proyecto
A continuación, se presentarán algunas herramientas que se añadirán a la nuestra como

escáneres de riesgos del OWASP TOP 10 además de otras que pueden resultar
interesantes en una prueba de penetración. Es importante mencionar que no todos los
riesgos pueden contemplarse, ya que no es posible automatizarlos dado que algunos
requieren una atención manual especifica. Además, es hay que tener en cuenta que no
todos estos escáneres funcionan de forma cien por cien automática (son
semiautomáticos) por lo que algunos requieren que el propio usuario introduzca unos
datos concretos requeridos por el escáner en cuestión.
Tabla 1. Herramientas para nuestro proyecto

Sistema
Herramienta ¿Que evalúa? Vulnerabilidad ¿Pago?
Operativo
Bolt [23] Broken Access CSRF Linux No
control
2.4 Escáneres para nuestro proyecto 39
DotDOtPwn [24] Broken Access Path transversal / Linux No

control Forced browsing
TestSSL [25] Cryptographic CWE-523 Linux No
failures
Shcheck [26] Cryptographic Headers Linux No
failures
Lighthouse [27] Security CWE-16 Linux / No
misconfiguration Windows
Dependency Vulnerable and CWE-1035 y CWE-1104 Linux No
Check [28] outdated
components
Nmap [29] Recopilación de - Linux No
información
Whatweb [30] Recopilación de - Linux No
información
TheHarvester [31] Recopilación de - Linux No
información
Debido a que casi todas las herramientas únicamente están disponibles en Linux, el
entorno se desarrollará para Linux. Además del análisis de los riesgos Broken Access
control, Cryptographic failures, Security Misconfiguration y Vulnerable and outdated
components se ha introducido un escáner para la recopilación de información que puede
resultar interesante al igual que los escáneres más básicos que proporcionaba Nessus. En
el apartado siguiente dedicado a la implementación se hablará sobre las vulnerabilidades
escogidas para analizar y que se encuentran presentes en la tabla (Tabla 1).
Capítulo 3
Metodología y Desarrollo
3.1 Introducción
Para este trabajo, se han tenido en cuenta aquellas metodologías necesarias para
comprender cómo funciona un test de penetración y cuáles son los principales riesgos
que afectan a las páginas web hoy en día. Además, se revisaron algunos de los principales
escáneres del mercado y se eligieron ciertas herramientas que automatizan el análisis de
algunos de los riesgos ya mencionados anteriormente. En este capítulo, se describirá la
metodología de desarrollo seguida para realizar el entorno junto con el desarrollo de la
herramienta que se ha separado en una parte analítica, donde se explicarán las
vulnerabilidades que se analizarán con la herramienta; y en una parte técnica donde se
describirán los recursos utilizados para desarrollar la herramienta.
3.2 Metodología de desarrollo
Para optimizar el flujo de trabajo es necesario establecer una metodología que sea capaz
de mejorar la productividad. Por esta razón ha sido escogida una metodología ágil,
específicamente SCRUM.
Podría pensarse que las metodologías ágiles tratan de establecer unas pautas sobre lo
que hay que hacer durante el desarrollo del software, en cambio, se centran en
establecer una forma de colaboración y de organización de los flujos de trabajo. Con esta
41
42 Capítulo 3 Metodología y Desarrollo
metodología se busca una mejora continua basada en la flexibilidad, ya que permite que
el desarrollo se adapte perfectamente a los cambios que se requieren del software.
Las metodologías ágiles nacieron en 2001 con el objetivo de buscar una forma nueva de
operar que se desprendiera de la linealidad de las metodologías en cascada [32]. Para
formalizar esta metodología, se creó el “Manifiesto para el desarrollo ágil de software”
que describe una serie de características primordiales y que son las siguientes:
– “Las personas y las interacciones antes que los procesos y las herramientas”.
– “El software en funcionamiento antes que la documentación exhaustiva”.
– “La colaboración con el cliente antes que la negociación contractual”.
– “La respuesta ante el cambio antes que el apego a un plan”.
Dentro de la metodología de SCRUM hay varios roles o papeles. Por una parte, está el rol
del Product Owner, que es el que representa el papel del cliente dentro del equipo y que
expresa el conjunto de necesidades o requisitos del cliente (Product Backlog); por otro
lado, está el rol del SCRUM Master, que es el que se encarga de que el equipo se ajuste a
la metodología de SCRUM; y por último está el rol del Equipo de desarrollo, que son
aquellas personas que llevan a cabo los requisitos escogidos (Sprint Backlog) para realizar
en un Sprint, que consiste en un periodo de tiempo que puede durar como máximo 30
días. En SCRUM también se realizan reuniones diarias llamadas Daily SCRUM, donde cada
miembro indica lo que hizo desde la anterior reunión, qué planea para la próxima reunión
y si tiene algún tipo de impedimento para cumplir el plan. También se realizan reuniones
al principio del Sprint (reuniones de planificación del Sprint), donde el Product Owner
presenta el Product Backlog y el equipo selecciona el mayor número posible de requisitos
que puede realizar en el Sprint; y al final del Sprint donde se hacen dos reuniones, una
reunión para revisar el proceso de desarrollo realizado y mejorarlo de cara al siguiente
Sprint (retrospectiva del Sprint) y otra reunión donde el equipo enseña al Product Owner
el desarrollo realizado y se determina el siguiente objetivo (revisión del Sprint) [33].
En el caso de este proyecto, al tratarse de un equipo muy pequeño y no disponer de
mucho tiempo, se ha optado por hacer unas cuantas modificaciones a la metodología
SCRUM. Dentro del equipo se han repartido los roles de la siguiente manera:
– Desarrollador: Ramón Fuentes Montoya.
– Product Owner: Enrique Arias Antúnez.
– SCRUM Master: José Antonio Mateo Cortés.
3.3 Desarrollo del entorno 43
Se ha sustituido el Daily Scrum por reuniones semanales donde se señalaba lo realizado

desde la anterior reunión, se hablaba sobre lo que se realizaría de cara a la siguiente
reunión y se hablaba de los impedimentos presentados. En cuanto al resto de reuniones,
se ha realizado una reunión al principio del Sprint para presentar el Product Backlog y
otra reunión al final del Sprint para presentar el trabajo realizado y plantear nuevos
objetivos. Las reuniones han sido planificadas mediante el uso de Outlook y realizadas
mediante el uso de Microsoft Teams
3.3 Desarrollo del entorno
El desarrollo del entorno se ha dividido en dos partes. La primera es la parte analítica

donde se hablará sobre los riesgos analizados y sobre sus vulnerabilidades. También se
justificará la ausencia de los riesgos que no han sido introducidos en el entorno.
Posteriormente, se hablará sobre la parte técnica donde se describen los recursos
utilizados para desarrollar el entorno.
3.3.1 Parte analítica
Esta herramienta está desarrollada contemplando las metodologías referentes a la

seguridad mencionadas en el estado del arte. Principalmente gira entorno al OWASP TOP
10, ya que incluye los diez riesgos que más afectan hoy en día a las páginas web. Por esta
razón, se han buscado herramientas que sean capaces de analizar estos riesgos. Sin
embargo, resulta obvio que no todos pueden ser comprobados de forma automática,
dado que es esencial el papel de un pentester en una prueba de penetración. Si pudiera
llevarse a cabo un análisis completo e íntegro con un simple clic, no existirían los trabajos
que realizan los pentesters. Teniendo en cuenta esta situación, desde un primer
momento se ha previsto una solución realista al proyecto planteado, que consiste en
realizar un entorno capaz de analizar de la forma más sencilla y completa posible aquellos
puntos o riesgos que afectan a las páginas web. A continuación, se verán los riesgos
escogidos en el proyecto.
Broken Access Control (número uno del OWASP TOP 10). Dentro de este riesgo se han
escogido tanto la vulnerabilidad “CSRF” o Cross-Site Request Forgery (CWE-352) como
Path Trasversal (CWE-23).
– CSRF. Esta vulnerabilidad permite que el atacante lleve a cabo acciones en nombre
de una víctima. Para aprovechar esta vulnerabilidad, el atacante envía a la víctima una
dirección a una página maliciosa con lo que, al entrar en este link, la página maliciosa
puede emitir una petición en nombre de la víctima [34]. Para evitar este tipo de
ataques la página web puede introducir un CSRF token [35] que va asociado al id de
sesión del usuario, de tal manera que el atacante no puede acceder a este token y no
puede enviar peticiones en su nombre.
– Path Trasversal. Esta vulnerabilidad se da debido a que las páginas web incluyen
recursos locales mediante rutas que pueden ser introducidas por el usuario. Un
atacante podría aprovechar este fallo de configuración para introducir rutas que
pueden suponer un gran riesgo para la página web. Un ejemplo podría ser:
http://paginaweb/cargarImagen?filename=../../../etc/passwd. De esta forma se
suben un numero “x” de directorios hasta llegar al archivo “passwd” [36].
Cryptographic failures (número dos del OWASP TOP 10). Dentro de este riesgo se han
escogido vulnerabilidades relacionadas con una mala configuración del certificado
“TLS/SSL” y de las “Cabeceras”.
– Certificado TLS/SSL. El uso de un TLS/SSL desactualizado o su ausencia puede suponer
la exposición de información sensible. Cuando una página web dispone de un
certificado TLS/SSL, muestra en su dirección una “s” al final del protocolo, por ejemplo
“https” (protocolo de transferencia segura de hipertexto) lo cual significa que, en las
en los intercambios de información con el servidor, la información transmitida se
encuentra cifrada gracias a los algoritmos aportados por un certificado TLS/SSL. El
cifrado de datos dificulta a un atacante el hecho de poder interpretar la información
intercambiada [37]. Existen varias vulnerabilidades relacionadas con este apartado,
por ejemplo, Heartbleed. Cuando se produce una conexión entre un cliente y un
servidor, esta conexión tiende a ser cerrada por parte del servidor, ya que este tiene
un límite de conexiones con clientes por lo que el navegador envía un mensaje
indicando que no cierre la conexión, porque el cliente sigue ahí. Estos mensajes se
asemejan a los latidos de un corazón por lo que de ahí viene la palabra Heart (corazón
en inglés) y contienen cualquier cosa de hasta 64 KB. Los mensajes enviados por el
cliente son respondidos con 64 KB por parte del servidor. Para sustraer información
lo que el atacante hace es enviar 1 KB de información que será respondida con 1KB
por parte del servidor, pero para sustraer información el cliente (atacante en este
caso) puede reclamar el resto de los datos que contiene este tipo de mensajes por lo
que el servidor enviará 1KB junto con 63KB de información adicional que puede
contener identificadores de sesión, contraseñas u otro tipo de información sensible.
De esta extracción de información viene la parte de Bleed (sangrar en castellano) que
termina el nombre Heartbleed [38].
– Cabeceras. Las cabeceras son unos parámetros que permiten enviar información
adicional al cliente o servidor a través de una petición o respuesta [39]. Una mala
configuración de las cabeceras puede convertirse en una posible vulnerabilidad. Un
ejemplo es la cabecera “X-XSS-Protection”, que evita posibles ataques de inyección
XSS. Esta vulnerabilidad consiste en la posibilidad de un atacante de inyectar de
scripts, los cuales que suelen ser redactados en JavaScript y que pueden ser de tres
tipos: el primer tipo son los XSS reflejados o no persistentes, llamados así porque se
reflejan en el navegador del usuario y porque no persisten en el servidor. El segundo
tipo son los XSS persistentes, que son aquellos que persisten en el servidor, y los del
tercer tipo son los XSS basados en DOM donde se permite modificar el DOM, que es
el árbol de objetos del html de la página web [40]. Otro ejemplo es la cabecera “X-
Frame-Options”, que puede evitar la vulnerabilidad “Clickjacking”, donde un atacante
puede establecer una interfaz en la página web vulnerable que hace de intermediaria
entre la página web y el usuario de tal manera que, por ejemplo, si el usuario inicia
sesión en la página, sus credenciales podrían ser sustraídas por parte del atacante sin
que el propio usuario se dé cuenta [41].
Security Misconfiguration (número cinco del OWASP TOP 10). Las vulnerabilidades de
este riesgo tienen que ver con la existencia de funciones innecesarias, cuentas con
valores predeterminados, uso de puertos innecesarios etc., por lo que el escáner evaluará
la URL introducida para analizar si se siguen una serie de buenas prácticas y para ver si
existen vulnerabilidades.
Vulnerable and outdated components (número seis del OWASP TOP 10). Con este escáner
se pretende analizar el proyecto de la página web en cuestión en busca de componentes
vulnerables y obsoletas.
Identification and autentication failures (número siete del OWASP TOP 10). La
vulnerabilidad relacionada con este riesgo son los ataques de fuerza bruta a logins. Con
este tipo de ataque lo que se hace es probar una lista muy larga de contraseñas (o incluso
nombres de usuario) en una ventana de inicio de sesión con el objetivo de encontrar la
contraseña o usuario correcto y ganar acceso al sistema. Este tipo de vulnerabilidades se
producen debido a que la página web no controla el número de intentos que puede
realizar un usuario al iniciar sesión.
Information gathering. Además de los riesgos anteriormente citados, al igual que en otros
entornos como Nessus, se ha añadido un escáner que puede llegar a ser de utilidad para
determinar la información sobre los puertos de la página web, información general
(lenguaje utilizado, servidor, etc.) e incluso información sobre los trabajadores de la
organización.
Existe la posibilidad de introducir otro tipo de riesgos como puede ser el riesgo número
tres (Injection) o el riesgo número diez (Server Side Request Forgery), pero dado que son
ataques complejos de llevar a cabo, necesitan ser estudiados en mayor detalle, por lo
que, al estar dirigida esta herramienta a PYMES, se ha prescindido de ellos, aunque no
está descartado añadirlos a largo plazo tal y como se mencionará durante el Capítulo 5
en el apartado de Trabajo Futuro. En cuanto al resto de riesgos existen cuestiones que
impiden en cierto modo comprobarlos de manera completamente automática. Algunos
de estos riesgos son:
Insecure desing. Este tipo de riesgo está relacionado con un diseño inseguro de la
aplicación el cual expone información sensible debido al uso de un ciclo de vida del
desarrollo del software inseguro. Alguna de este tipo de exposiciones de información
sensible tiene que ver con el uso de mensajes de error que contienen información
sensible (CWE-209) o el uso de credenciales insuficientemente protegidas (CWE-522). No
obstante, mediante el escáner Cryptographic failures puede determinarse si existe una

cabecera (X-Frame-Options) que evita una vulnerabilidad conocida como Clickjacking la
cual pertenece a este riesgo.
Software and Data Integrity Failures. Este tipo de vulnerabilidades se producen debido a
la incapacidad del software para mantener la integridad de los datos. Para realizar este
tipo de comprobaciones sería necesaria una herramienta que probara qué datos pueden
encontrarse corruptos, pero no ha sido posible encontrar una herramienta que se ajuste
a este tipo de riesgo.
Security logging and monitoring failures. Estas vulnerabilidades están relacionadas con
una mala monitorización, registro de eventos o la ausencia de detección de errores o
inicios de sesión, con lo que este tipo de vulnerabilidades han detectarse no con un
escáner, si no con un sistema SIEM, que consiste en un sistema de seguridad que permite
tener control sobre los eventos que suceden en el sistema y permite detectar
comportamientos que se encuentren fuera de lo común [42]. También están relacionadas
con el almacenamiento de información sensible en logs. Esto significa que existiría la
posibilidad de acceder a esa información, por ejemplo, con una vulnerabilidad Path
trasversal, que está incluida en el escáner de Broken acess control.
3.3.2 Parte técnica
Durante el proceso se ha utilizado como editor de código Visual Studio Code [43] en la
distribución de Linux, Kali Linux [44] la cual es una distribución hecha específicamente
para la ciberseguridad, ya que incluye multitud de herramientas. También se han
obtenido herramientas no incluidas en Kali mediante el uso de GitHub [45]. El entorno ha
sido desarrollado en Python 3 con multitud de librerías que han facilitado el proceso del
diseño de esta aplicación de escritorio. La librería sobre la que se cimenta la interfaz de
la aplicación es tkinter la cual ha sido usada por su sencillez y por la gran cantidad de
documentación que tiene disponible en la red. Se han empleado Widgets (objetos de la
librería tkinter) como Frames para hacer las ventanas, Buttons (botones), Labels para
introducir texto e imágenes y Entries (entradas) para que el usuario introduzca texto (lo
que se suele conocer como forms en HTML). Para crear el logo del entorno, llamado
“Apolo”, se ha utilizado Photoshop al igual que para editar cada imagen de cada escáner.
Cuando se abre la aplicación, se muestra la siguiente pantalla
Ilustración 40. Pantalla principal

La aplicación se divide principalmente en 3 partes. La primera se corresponde con la
pantalla principal, donde se encuentran situados los escáneres disponibles de la
aplicación y que pueden crearse pulsando en “Crear escáner” (Ilustración 41).
Ilustración 41. Ventana de los escáneres

La segunda pantalla se corresponde con la salida de los escáneres utilizados. Esta ventana
ha sido incluida para dar cierta retroalimentación al usuario de lo que está sucediendo
(Ilustración 42).
Ilustración 42. Ventana del Output (salida)

La tercera ventana es la del historial, que se compone de una tabla donde se almacenan
algunos datos referentes al escáner como es el nombre del escáner, el host objetivo, la
fecha y los escáneres seleccionados. También se compone de tres botones. Uno es para
inspeccionar la carpeta, titulado “inspeccionar”, en la que se han situado los escáneres
que por defecto vienen creados dentro de otra carpeta creada por el entorno llamada
“reportes”. Para borrar los escáneres creados y sus reportes, hay otro botón titulado
“borrar”. Para utilizar ambos botones es necesario seleccionar previamente el escáner de
la tabla con el que se quiere interactuar. El tercer botón, o más bien botones, está situado
en la columna “Nombre” y son cada uno de los nombres de los escáneres (Escáner1,
Escáner2… etc.). Si se presiona este botón, se abrirán todos los reportes pertenecientes
a ese escáner en concreto (Ilustración 43).
Ilustración 43. Ventana del historial

A continuación, se verá el flujo de trabajo que sigue el entorno. Desde la pantalla

principal, para crear un escáner hay que seleccionar los escáneres deseados y pulsar en
“Crear escáner”, con lo que se añade una nueva pantalla donde se piden los parámetros
del escáner o escáneres seleccionados (Ilustración 44).
Ilustración 44. Ejemplo de ventana de parámetros

Posteriormente, hay que pulsar en “Lanzar escáner” y los escáneres comenzarán. Al
terminar los escáneres, se generarán los reportes de cada escáner creado que serán
guardados en una carpeta llamada mediante la combinación del nombre “Escáner” y el
número de escáner que se ha realizado, por ejemplo, “Escáner1”. A su vez todas estas
carpetas que albergan los reportes se almacenarán dentro de otra carpeta llamada
“reportes” y que es creada la primera vez que se ejecuta el entorno.
Para lanzar cada herramienta de cada escáner, se ha utilizado la librería Subprocess
(Ilustración 45), que permite ejecutar comandos en segundo plano. Además, para no
bloquear el resto de las funciones del entorno, se ha iniciado esta serie de comandos en
un nuevo hilo creado gracias a la librería Threading (Ilustración 46).
Ilustración 45. Creación de un nuevo hilo

Ilustración 46. Ejecución de los comandos

Capítulo 4
Experimentos y Resultados
4.1 Introducción
En este capítulo se hablará sobre las herramientas que posee cada escáner del entorno,
sobre la funcionalidad de cada una de ellas, sobre los parámetros requeridos por el
escáner del entorno, sobre el comando que se ejecuta en el código fuente de cada
herramienta y sobre los reportes obtenidos al ejecutar cada escáner sobre un objetivo.
4.2 Pruebas realizadas
Con el objetivo de preservar el anonimato de los objetivos sobre los que se han realizado
las pruebas, se censurará su identidad en todos los reportes mostrados en este capítulo.
Broken access control. En este escáner se utilizan dos herramientas, “Bolt CSRF”, para el
análisis de la vulnerabilidad CSRF y “Dotdotpwn”, para analizar URLs que puedan
contener un Path trasversal.
– Bolt CSRF. Esta herramienta detecta, en caso de que exista un CSRF Token, si el CSRF
Token de la página web evaluada es lo suficientemente fuerte, realizando, entre otras
medidas, una comparación de varios CSRF Token mediante la emisión de 100
peticiones simultaneas con el objetivo de determinar si en algún caso el CSRF Token
es similar o igual. La herramienta incorpora un crawler o rastreador que recopila los
53
54 Capítulo 4 Experimentos y Resultados
enlaces presentes en el objetivo para posteriormente analizarlos en búsqueda del

CSRF Token anteriormente mencionado. Para realizar el escáner con Bolt CSRF el
entorno requiere la dirección del objetivo junto con la profundidad a la que se quiere
que llegue el rastreador (Ilustración 47).
Ilustración 47. Parámetros del CSRF requeridos por el entorno

Visto desde el código fuente del entorno, el comando ejecutado sería el siguiente:
python3 bolt.py -u <objetivo> -l <Profundidad>
Donde con el parámetro “-u” se añade el objetivo y, con el parámetro “-l”, la

profundidad a la que se quiere que llegue el rastreador. En el caso de la página web
testeada, el resultado es el de la Ilustración 48.
Ilustración 48. Resultado obtenido de CSRF

Como se puede observar, no se ha conseguido encontrar un CSRF Token por lo que
existe la posibilidad de que la página web testeada sea vulnerable a un ataque CSRF
(Ilustración 48).
– Dotdotpwn. Su funcionamiento consiste en una fuerza bruta que contiene distintas
combinaciones que permiten comprobar que la dirección introducida es vulnerable.
Al tratarse de un ataque de fuerza bruta, no se recomienda ejecutar este escáner de
4.2 Pruebas realizadas 55
Path Trasversal junto con otros escáneres, ya que puede llevar una gran cantidad de
tiempo y puede entorpecer el resto de los escáneres. Para realizar el escáner con
Dotdotpwn se requiere la dirección del objetivo, y la URL específica que va a ser
testeada (Ilustración 49).
Ilustración 49. Parámetros del Path Trasversal requeridos por el entorno

perl dotdotpwn.pl -m http-url -h <objetivo> -u

<URL_test>=TRAVERSAL -k "root" -b
Este comando tiene varios parámetros. El primer parámetro es “-m”, que es para
escoger un módulo y, como en este caso es una web, se escoge el módulo “http-url”;
luego tiene “-h”, que es para escoger la dirección de la página web, por ejemplo:
http://www.ejemplo.com/; seguidamente tiene “-u”, para escoger la URL específica
a testear, por ejemplo http://www.ejemplo.com/path_trasversal.php?page=, esta
URL se iguala a la palabra clave “TRASVERSAL” para indicar de manera precisa dónde
se quiere ejecutar el ataque; posteriormente tiene el parámetro “-k”, que va seguido
de “root” y que sirve para indicar a la herramienta que cuando encuentre un fichero
con esa palabra clave (“root”), avise de que es vulnerable; por último tiene el
parámetro “-b” que indica a la herramienta que pare el ataque al encontrar un Path
Trasversal. Se ha decidido incluir el parámetro “-b” debido a que la intención es
detectar que esta vulnerabilidad existe no encontrar todas las combinaciones
posibles. En el caso de la página web testeada, el resultado es el de la Ilustración 50.
Ilustración 50. Resultado obtenido de Path Trasversal

Tras ejecutar sucesivas combinaciones que pueden revelar la existencia de esta
vulnerabilidad, la herramienta ha encontrado que, en la URL indicada, el objetivo
es vulnerable, ya que permite la visualización del archivo “/etc/passwd”
(Ilustración 50).
Cryptographic failures. En este escáner se utilizan dos herramientas, una es “Testssl” para
el análisis de certificados TLS/SSL y otra es “Shcheck”, para el análisis de las cabeceras.
– Testssl. Esta herramienta analiza los certificados que utiliza la página web en
búsqueda de algún certificado que se encuentre ausente u obsoleto y determina si la
página es vulnerable a usa serie de vulnerabilidades comunes. Para realizar el escáner
con Testssl se requiere presionar el botón “testssl” y añadir la dirección del objetivo
(Ilustración 51).
Ilustración 51. Parámetros de Testssl requeridos por el entorno

testssl --vulnerable --protocols <objetivo>
En el comando se han introducido los parámetros “—vulnerable”, con el que Testssl

hace un análisis para buscar una serie de vulnerabilidades comunes; “—protocols”,
para revisar las versiones de los certificados TLS/SSL ofrecidas por el objetivo; y por
último se ha introducido la dirección del objetivo. En el caso de la página web

testeada, el resultado es el de la ilustración 52.
Ilustración 52. Resultado de Testssl
Por una parte, se obtiene un análisis de las versiones de los certificados TLS/SSL que
la página web ofrece. Dentro de este análisis se ha obtenido que tanto el TLS 1 como
el TLS 1.1 se encuentran obsoletos. Por otra parte, se ha encontrado una
vulnerabilidad a la que potencialmente no se es vulnerable (“BREACH”) y otras dos a
las que sí es vulnerable. En cuanto a las que sí es vulnerable, consisten en “BEAST” y
“LUCKY13”. Ambas vulnerabilidades están relacionadas con el uso de TLS 1 y TLS 1.1
que utilizaba un tipo de cifrado débil, por lo que sería recomendarle dejar de utilizar
estas versiones (Ilustración 52).
– Shcheck. Esta herramienta revisa la página web en función a una lista de cabeceras,
buscando aquellas que le faltan y aquellas que posee. Para realizar el escáner con
Shcheck se requiere presionar el botón “shcheck” y añadir la dirección del objetivo

(Ilustración 53).
Ilustración 53. Parámetros de Shcheck requeridos por el entorno
shcheck -k <objetivo>
Los parámetros introducidos son “-k”, que es para indicar que se muestren las
cabeceras que se encuentran desactualizadas y el objetivo al que se quiere lanzar la
herramienta. El resultado obtenido del análisis de la página en cuestión es el de la
Ilustración 54.
Ilustración 54. Resultado obtenido de shcheck

Como se puede observar, faltan todas las cabeceras analizadas, aunque hay dos que
sí que están presentes pero que se encuentran desactualizadas (Ilustración 54). A
continuación, se hablará sobre dichas cabeceras:
– X-XSS-Protection. De esta cabecera se habló durante el análisis y es una
protección frente a inyecciones de tipo XSS, ya que impide la carga de una página
cuando se detecta un ataque XSS [46]. Esta cabecera sí que está presente en la
página web, pero se encuentra desactualizada.
– X-Frame-Options. Esta cabecera indica si un navegador puede renderizar una
página en un <frame>,<iframe>, <object> o <embed>. Evita la vulnerabilidad
Clicjacking, ya que su contenido no es embebido en otros sitios [47].
– X-Content-Type-Options. Cuando el administrador de una página web no
devuelve correctamente los tipos de archivos tratados en una página web (esto
se hace con la cabecera Content-Type), el navegador, tiene que determinar de
qué tipo es este archivo teniendo que inspeccionar el archivo que puede ser un
archivo camuflado como una imagen. Cuando el navegador entra en el archivo y
determina que es un HTML y no una imagen, intenta ejecutar dicho archivo que
podría contener algún tipo de JavaScript malicioso. Esta inspección del navegador
conocida como MIME sniffing, es la que precisamente esta cabecera bloquea [48].
– Strict-Transport-Security. Esta cabecera solo permite al sitio web comunicarse
con HTTPS en vez de HTTP [49].
– Content-Security-Policy. Esta cabecera permite establecer una lista de fuentes
fiables de las que aceptar scripts, imágenes u otros recursos. Por esta razón añade
una protección frente a inyecciones [50].
– X-Permitted-Cross-Domain-Policies. Se utiliza para indicar a clientes como Flash y
Acrobat qué peticiones de un dominio a otro pueden utilizar [51]. Esto se hace
con el objetivo de evitar posibles peticiones dañinas de documentos Adobe Flash
y PDF [52]. Esta cabecera se encuentra presente en la página web, pero esta
desactualizada.
– Expect-CT. Evita que la página web utilice certificados emitidos incorrectamente
y asegura que no pasen desapercibidos [53].
– Referrer-Policy. Esta cabecera permite restringir la información de referencia de
una solicitud anterior, es decir, evita que se filtre desde donde se ha realizado una
petición a la página web visitada. Este tipo de cabeceras es útil para evitar que se
filtre información sobre el usuario a páginas webs de terceros [54].
– Permissions-Policy. Esta cabecera permite controlar el acceso que tienen las
páginas web a los recursos o características del navegador a los que tiene acceso
una página. Un ejemplo: se tiene una página web llamada “ejemplo.com”. Esta
web obtiene anuncios de “anuncios.com” que es una página desconfiable y

también toma recursos de “página-confiable.com” que es confiable. Pues esta
cabecera permite impedir el acceso a recursos del navegador (como la
geolocalización) a anuncios.com y puede dárselos a página-confiable.com.
– Cross-Origin-Embedder-Policy. Previene que un documento cargue datos de
origen cruzado que no garanticen los permisos del documento [55].
– Cross-Origin-Resource-Policy. Esta cabecera permite que el navegador bloquee
aquellas solicitudes de origen/sitio cruzado sin que se tenga CORS al recurso dado
[56]. CORS es una cabecera que permite al servidor indicar de que fuentes permite
la carga de recursos [57].
– Cross-Origin-Opener-Policy. Asegura que un documento de nivel superior no
comparte un grupo de contexto de navegación con documentos de origen
cruzado [55].
Identification failures. Tal y como se comentó en el desarrollo, para contemplar el riesgo

de Identification failures se ha utilizado una herramienta dedicada a realizar ataques por
fuerzas bruta. En este caso, aunque hay una gran variedad de ellas, en este caso, se ha
optado por “Hydra”, ya que viene incluida en Kali Linux. Con este escáner se puede
comprobar tanto el uso de contraseñas o usuarios por defecto como la falta de
protección frente a ataques por fuerza bruta. Al igual que con el análisis del Path
Trasversal, no se recomienda ejecutar este escáner junto con otros, ya que puede llevar
una gran cantidad de tiempo y entorpecer al resto de los escáneres escogidos.
Para realizar este escáner se requiere el host, la request o solicitud junto con algunos
parámetros requeridos por Hydra, como es el mensaje de error vertido por una petición
fallida; el usuario o lista de usuarios y la contraseña o lista de contraseñas (Ilustración 55).
Ilustración 55. Parámetros de Hydra requeridos por el entorno

Para elegir entre un usuario o lista de usuarios y una contraseña o lista de contraseñas,
basta con hacer clic en el botón “Usuario” y en el botón de “Contraseña”, de tal manera
que se cambiará el nombre de “Usuario” por “Lista de usuarios” y el de Contraseña por
el de “Lista de contraseñas”, a su vez, a la izquierda de los campos de los usuarios y
contraseñas, aparecerá un botón nombrado como “Browse” con el que se podrá buscar
la lista de usuarios o contraseñas deseada (Ilustración 56).
Ilustración 56. Parámetros de Hydra (listas) requeridos por el entorno

Hydra -l <usuario> -p <contraseña> http-post-form <peticion>

=”mensaje_error” -V
Primero se ha introducido “-l”, para añadir un solo usuario o “-L”, para añadir una lista de
usuarios, seguidamente se añade “-p”, para añadir una contraseña, o “-P” para añadir
una lista de contraseñas, posteriormente hay que indicar que se va a hacer la fuerza bruta
a un formulario poniendo “http-post-form” junto con la petición y el mensaje de error
que produce el login cuando se produce un intento fallido, por último, se añade “-V” para
ver cada uno de los intentos de Hydra en el output. En el caso de la página web testeada
el resultado es el de la Ilustración 57.
Ilustración 57. Resultado obtenido de Hydra

Como se puede ver, tras sucesivos intentos, se ha encontrado la contraseña asociada al

usuario utilizado. Por lo tanto, este login no solo no está protegido contra una fuerza
bruta si no que utiliza un usuario con una contraseña realmente débil (Ilustración 54).
Security Misconfiguration. Para analizar este riesgo se ha tratado de buscar una

herramienta que fuera capaz de evaluar la página web en función de una serie de buenas
prácticas. La herramienta escogida ha sido “Lighthouse”, la cual fue desarrollada
recientemente por Google y para hacer análisis SEO, aunque también contiene una
sección para analizar este riesgo. Para realizar este escáner en el entorno es necesario
únicamente introducir la dirección que se desea analizar (Ilustración 58).
Ilustración 58. Parámetros de Lighthouse requeridos por el entorno

Lighthouse <objetivo> --only-categories=best-practices
Se ha introducido como parámetros el objetivo y el parámetro “–only-categories=best-

practices”, ya que el único análisis que se necesita es el de buenas prácticas. En el caso
de la página web testeada el resultado es el de la Ilustración 59:
Ilustración 59. Resultado obtenido de Lighthouse

Como se puede ver, se han realizado varias comprobaciones y en función a ellas se ha
obtenido una puntuación, en este caso 86 (Ilustración 59). Las comprobaciones se dividen
en varias secciones, de entre ellas las que están relacionadas con Security
Misconfiguration son:
– “Passed audits”. Donde salen comprobaciones que la página ha aprobado como el
uso de HTTPS o el uso de APIs actualizadas (Ilustración 60).
Ilustración 60. Resultado obtenido de Lighthouse (Passed audits)

– “Trust and safety”. Aquí se hacen comprobaciones referentes a la seguridad. En este
caso indica que ha encontrado algunos scripts de terceros que pueden llegar a
contener vulnerabilidades conocidas. También indica que no se ha encontrado un
Content Security Policy (CSP) que asegura que el contenido obtenido proviene de
fuentes fiables y que puede suponer la exposición a inyecciones XSS (Ilustración 61).
Ilustración 61. Resultado obtenido de Lighthouse (Trust and safety)

Vulnerable and outdated components. Para analizar este riesgo se ha utilizado una
herramienta que sea capaz de evaluar las dependencias de una página web, como es
“Dependency-check”. Para poder realizar este escáner es necesario un único parámetro
que es la ruta de la carpeta del código fuente de la página web, por lo tanto, para este
escáner se requiere la posesión del proyecto de la página web (Ilustración 62).
Ilustración 62. Parámetros de Dependency-check requeridos por el entorno

dependency-check.sh –scan <ruta_proyecto>
El parámetro introducido es simplemente “—scan” que sirve para indicar la ruta del
proyecto que se quiere analizar. Antes de mostrar la prueba, es necesario aclarar que en
esta prueba no ha sido necesario censurar la página web empleada como objetivo, ya
que el proyecto empleado pertenece al estudiante de Ingeniería Informática. En el caso
de la página web testeada, el resultado obtenido es el de la Ilustración 63 y la Ilustración
64.
Ilustración 63. Resultado obtenido de Dependency-check (Summary)

Ilustración 64. Resultado obtenido de Dependency-check (Dependencies)
En el resultado se puede apreciar un apartado que contiene un resumen (Ilustración 63)

en una tabla con todas las vulnerabilidades encontradas para cada dependencia y un
apartado donde se habla sobre cada dependencia y su vulnerabilidad (Ilustración 64). En
el caso de esta prueba, se ha encontrado una vulnerabilidad en la dependencia
“Passport”. La vulnerabilidad, es un Session Fixation, que consiste en la posibilidad de un
atacante de fijar el ID de sesión dentro de un parámetro en la URL que posteriormente
es enviada a la víctima, de tal manera, que, si inicia sesión en la página web vulnerable,
dará acceso al atacante a esa sesión [58].
Information gathering. Este escáner recopila información variada de la página web

introducida. Es por esta razón por la que no se compone solo de una herramienta. En
este caso se ha elegido “Nmap”, “Whatweb” y “theHarvester”.
– Nmap. Con esta herramienta se obtienen aquellos puertos que se encuentran

abiertos. Para realizar este escáner con Nmap únicamente es necesario pulsar el
botón de “Nmap” e introducir el objetivo (Ilustración 65).
Ilustración 65. Parámetros de Nmap requeridos por el entorno
Nmap <objetivo>
Este comando únicamente contiene la dirección del objetivo, ya que solo se pretende
obtener los puertos que se encuentran abiertos. En la página web testeada se han
encontrado los puertos mostrados en la Ilustración 66.
Ilustración 66. Resultado obtenido de Nmap

Se ha obtenido dos puertos, en este caso el puerto 80 del servicio HTTP y el puerto
443 de HTTPS (Ilustración 66).
– Whatweb. Esta herramienta obtiene información de general de la página web. Para
realizar este escáner con Whatweb únicamente es necesario pulsar el botón de
“Whatweb” e introducir el objetivo (Ilustración 67).
Ilustración 67. Parámetros de Whatweb requerido por el entorno

Whatweb <objetivo> -v
En el comando se ha introducido simplemente el objetivo y el parámetro -v para que

muestre una explicación de los plugin, con el objetivo de que se entiendan mejor los
datos obtenidos. En la página web testeada se han encontrado los resultados de la
Ilustración 68.
Ilustración 68. Resultado obtenido de Whatweb

En el reporte se puede ver el “Status” o código de estado devuelto por la página web,
el “Title” o título, la IP, el “Country” o país y un “Summary” o resumen del análisis
donde se muestran todos los datos obtenidos en una línea (Ilustración 68). Un poco
más abajo se ve otra sección titulada “Detected plugins”. En esta sección se habla
sobre los diferentes plugin que emplea la herramienta para obtener cada uno de los
datos, como es el servidor, que es un Apache, el string de las cookies, que es
“PHPSESSID”, un email obtenido y otros datos como el uso de HTML5, de JQuery, etc.
– theHarvester. Esta herramienta obtiene información sobre los trabajadores de la

página web haciendo búsquedas en varios navegadores y redes sociales. Por
preservar el anonimato no se mostrará los nombres de los trabajadores obtenidos
mediante esta herramienta. Para realizar este escáner con theHarvester solo es
necesario pulsar el botón de “theHarvester” e introducir el objetivo (Ilustración 69).
Ilustración 69. Parámetros de theHarvester requeridos por el entorno

theHarvester -d <objetivo> -b google,linkedin,twitter,yahoo,

duckduckgo,bing
Se ha introducido el parámetro “-d” para indicar el objetivo y el parámetro “-b” para

indicar dónde se quiere que se hagan las búsquedas de información. En este caso se ha
escogido Google, Linkedin, Twitter, Yahoo!, Duckduckgo y Bing. En la página web testeada
se han encontrado los resultados de la Ilustración 70.
Ilustración 70. Resultado obtenido de theHarvester

En este caso no se ha conseguido encontrar mucha información, pero se han obtenido
algunos nombres de trabajadores de la empresa junto con algunos subdominios, dado
que theHarvester incluye por defecto el uso de “Sublist3r” [59], que es otra herramienta
orientada a la búsqueda de subdominios (lustración 70).
Capítulo 5
Conclusiones y Trabajo Futuro
En este capítulo se hablará sobre las conclusiones del trabajo realizado, pasando por unos
comentarios sobre el entorno, una reflexión sobre la importancia de la existencia de
entornos como el de este proyecto y se hablará sobre la utilidad del Grado en este
trabajo. Finalmente, se hablará en un apartado llamado “Trabajo Futuro” sobre las
posibles mejoras de este proyecto.
5.1 Conclusiones
A partir de los resultados obtenidos en los casos prácticos, se concluye que este proyecto
se ha finalizado con éxito, porque el entorno realizado es capaz de proporcionar una
manera sencilla de analizar una página web. Es cierto que el entorno tiene algunos puntos
que podrían mejorarse a largo plazo (se hablará de ellos en el apartado 5.2 titulado
“Trabajo Futuro”), pero se ha conseguido el resultado esperado. Lo que podría
considerarse como la principal desventaja de este entorno es que para leer los reportes
es necesario disponer de un mínimo de conocimientos, pero esto, en realidad, supone
una ventaja, ya que, facilitando el uso de estos escáneres, se consigue un acercamiento
más sencillo a la ciberseguridad, lo cual es muy importante ya no solo para las PYMES, a
las cuales va dirigido este entorno, si no para los particulares que no dispongan de tantos
conocimientos y decidan utilizarlo.
71
72 Capítulo 5 Conclusiones y Trabajo Futuro
Que la sociedad avance hacia un futuro totalmente ligado a las tecnologías, hace que un
entorno como el de este proyecto tome incluso más importancia, ya que las tecnologías
pueden facilitar la vida de las personas en muchos sentidos, pero si no se realiza un acto
de concienciación y no se toman las medidas pertinentes para aumentar la seguridad de
estas tecnologías, se estará avanzando hacia un futuro igual de caótico que tecnológico.
En este proyecto están plasmados, estos cinco años de experiencia y aprendizaje. Se han
tenido en cuenta varios conocimientos adquiridos durante el Grado de Ingeniería
Informática. Para comenzar, se ha tenido en cuenta el uso de metodologías de desarrollo,
las cuales fueron vistas durante la asignatura “Ingeniería del Software II”. Seguidamente,
para la creación de la interfaz del entorno, se ha tenido en cuenta la creación de
interfaces vista en Java, de la asignatura “Lenguajes de programación I” que, aunque, no
se haya utilizado para desarrollar el entorno, ha facilitado el aprendizaje del uso de
librería tkinter de Python, la cual presenta varias similitudes. A la hora de evitar que el
entorno se quedara bloqueado, se ha tenido en cuenta el manejo de hilos, de la
asignatura “Programación concurrente”. Por último, también se han tenido en cuenta
todos los conocimientos adquiridos durante la asignatura “Seguridad en redes”, donde
se vio terminología y conocimientos básicos de la ciberseguridad y algunas de las
herramientas utilizadas en los escáneres de este entorno, como son Nmap y
theHarvester.
Con este proyecto, también se han adquirido nuevos conocimientos. Se ha aprendido
sobre las metodologías empleadas en las pruebas de penetración web (metodologías de
OWASP) , sobre cómo una empresa establece sus políticas de ciberseguridad (ISO 27001),
sobre el uso metodologías de desarrollo ágiles (uso de una variante de SCRUM), sobre
cómo programar en Python 3 y sobre las principales vulnerabilidades que afectan a las
páginas web. Además, este trabajo no solo ha mejorado los conocimientos en
ciberseguridad, si no que ha aumentado el hambre de adquirir nuevos conocimientos de
cara a plantear un futuro profesional ligado a la ciberseguridad.
A lo largo de este trabajo se han aplicado varias competencias adquiridas a lo largo del
Grado. De entre todas las competencias se nombrarán las más destacadas y se justificará
su aplicación:
5.1 Conclusiones 73
– [IC6] Capacidad para comprender, aplicar y gestionar la garantía y seguridad de los

sistemas informáticos. Debido a que ha sido necesario comprender cómo funcionan
las pruebas de penetración web para poder evaluar la seguridad de las páginas web
mediante el entorno de este proyecto.
– [CO1] Capacidad para diseñar, desarrollar, seleccionar y evaluar aplicaciones y
sistemas informáticos, asegurando su fiabilidad, seguridad y calidad, conforme a
principios éticos y a la legislación y normativa vigente. Debido a que se ha realizado
una aplicación de escritorio robusta capaz de gestionar los flujos alternativos
existentes.
– [CO14] Conocimiento y aplicación de los principios fundamentales y técnicas básicas
de la programación paralela, concurrente, distribuida y de tiempo real. Debido a
durante el desarrollo del entorno ha sido necesario gestionar hilos con para que el
entorno no se bloqueara en ningún caso.
– [CO17] Capacidad para diseñar y evaluar interfaces persona computador que
garanticen la accesibilidad y usabilidad a los sistemas, servicios y aplicaciones
informáticas. Debido a que ha sido necesario diseñar para el entorno una interfaz
accesible para los públicos con el conocimiento más básico en ciberseguridad.
Por último, se ilustrará mediante un diagrama de Gantt el tiempo dedicado a cada una
de las actividades realizadas durante el proyecto (Ilustración 71). En total se han dedicado
entorno a las 300 horas.
74 Capítulo 5 Conclusiones y Trabajo Futuro
Ilustración 71. Diagrama de Gantt

5.2 Trabajo futuro
En cierto modo, parece que el proyecto se ha quedado algo escaso en el número de

riesgos que se analizan, dado que se han tratado de introducir aquellos riesgos cuyo uso
es el más sencillo posible porque el entorno está en la actualidad orientado
especialmente hacia PYMES, las cuales poseen conocimientos básicos de ciberseguridad.
Entonces, una posible actualización de la herramienta podría introducir una vertiente
algo más profesional, mediante la adición de nuevos escáneres más avanzados y que
puedan ser combinados con otras herramientas como Burp Suite. Entre algunos de los
nuevos riesgos, podrían introducirse tanto los de inyección como los del SSRF o Server
Side Request Forgery.
Otro punto por mejorar en la actualidad, son los reportes. No todas las herramientas
incorporan un sistema de reportes, por lo que, la solución utilizada, es redirigir su salida
hacia un archivo de formato TXT. El problema con este formato es que no coincide con el
mostrado por la terminal, que es para el que están adaptadas estas herramientas, ya que
están orientadas al uso y visualización de los resultados mediante la terminal. Por lo
tanto, la única forma en la que se conserva el formato correcto de estos reportes es en
la terminal y han de ser visualizados mediante el uso del comando “cat”. Por ello, en la
versión actual se dispone de los botones de la columna “Nombre” que permiten abrir
todos estos reportes haciendo un cat en una nueva terminal. Sin embargo, esta solución
simplemente abre una terminal y muestra los resultados, por lo que trabajar de esta
manera no resulta cómodo para el público al que va destinado el entorno (PYMES). Por
tanto, una posible mejora vendría con la creación de un sistema de reportes que sea
capaz de generar archivos en formatos más utilizados, como html y pdf. Para ello, sería
necesario indagar sobre el formato utilizado en la terminal y traducirlo de alguna manera
a html y pdf, intentando conservar los colores, la negrita y todas las características del
formato original. Otra posible solución sería modificar estas herramientas para que sean
capaces de generar reportes en formato html y pdf.
75
76 Bibliografía
Bibliografía
[1] Avast, “El ataque del ransomware WannaCry: ¿qué es? | Avast.” Accessed: Jun.
08, 2022. [Online]. Available: https://www.avast.com/es-es/c-wannacry#topic-3
[2] i.blogs, “1366_2000.jpg (1200×794).”
https://i.blogs.es/3f5b3a/wannacrypt/1366_2000.jpg (accessed Jul. 02, 2022).
[3] Tekcrispy, “Estos han sido los hackeos más grandes de los últimos 5 años.”
Accessed: Jun. 08, 2022. [Online]. Available:
https://www.tekcrispy.com/2020/08/02/estos-han-sido-los-hackeos-mas-
grandes-de-los-ultimos-5-anos/
[4] Business Insider, “El impacto de los ciberdelitos ya es superior al 1% del PIB
mundial | Business Insider España.” Accessed: Jun. 08, 2022. [Online]. Available:
https://www.businessinsider.es/impacto-ciberdelitos-ya-superior-1-pib-
mundial-768519
[5] DSI UCLM, “Bloque 1. Introducción Tema 1.2. Introducción a la Seguridad
Informática y de la Información.” Accessed: Jul. 08, 2022. [Online]. Available:
https://campusvirtual.uclm.es/pluginfile.php/116353/mod_resource/content/3
/1.2%20-%20Seguridad%20-
%20Introduccio%CC%81n%20a%20la%20Seguridad.pdf
[6] INCIBE, “¿Qué es el pentesting? Auditando la seguridad de tus sistemas |
INCIBE.” https://www.incibe.es/protege-tu-empresa/blog/el-pentesting-
auditando-seguridad-tus-sistemas (accessed Jun. 08, 2022).
[7] OWASP, “4.0 Testing Guide”, Accessed: Jun. 08, 2022. [Online]. Available:
http://www.owasp.org
[8] OWASP, “OWASP Web Application Penetration Checklist Version 1.1.” [Online].
Available: http://csrc.nist.gov/publications/nistpubs/index.html#sp800-30
[9] OWASP, “OWASP Top 10:2021.” https://owasp.org/Top10/ (accessed Jun. 08,
2022).
Bibliografía 77
[10] OWASP, “A01 Broken Access Control - OWASP Top 10:2021.”

https://owasp.org/Top10/A01_2021-Broken_Access_Control/ (accessed Jun. 08,
2022).
[11] OWASP, “A02 Cryptographic Failures - OWASP Top 10:2021.”
https://owasp.org/Top10/A02_2021-Cryptographic_Failures/ (accessed Jun. 08,
2022).
[12] OWASP, “A03 Injection - OWASP Top 10:2021.”
https://owasp.org/Top10/A03_2021-Injection/ (accessed Jun. 08, 2022).
[13] OWASP, “A04 Insecure Design - OWASP Top 10:2021.”
https://owasp.org/Top10/A04_2021-Insecure_Design/ (accessed Jun. 08, 2022).
[14] OWASP, “A05 Security Misconfiguration - OWASP Top 10:2021.”
https://owasp.org/Top10/A05_2021-Security_Misconfiguration/ (accessed Jun.
08, 2022).
[15] OWASP, “A06 Vulnerable and Outdated Components - OWASP Top 10:2021.”
https://owasp.org/Top10/A06_2021-Vulnerable_and_Outdated_Components/
(accessed Jun. 08, 2022).
[16] OWASP, “A07 Identification and Authentication Failures - OWASP Top 10:2021.”
https://owasp.org/Top10/A07_2021-
Identification_and_Authentication_Failures/ (accessed Jun. 08, 2022).
[17] OWASP, “A08 Software and Data Integrity Failures - OWASP Top 10:2021.”
https://owasp.org/Top10/A08_2021-Software_and_Data_Integrity_Failures/
[18] OWASP, “A09 Security Logging and Monitoring Failures - OWASP Top 10:2021.”
https://owasp.org/Top10/A09_2021-
Security_Logging_and_Monitoring_Failures/ (accessed Jun. 08, 2022).
[19] OWASP, “A10 Server-Side Request Forgery (SSRF) - OWASP Top 10:2021.”
https://owasp.org/Top10/A10_2021-Server-
Side_Request_Forgery_%28SSRF%29/ (accessed Jun. 08, 2022).
[20] Organización Internacional de Normalización, “ISO/IEC 27001:2013,” 2017.
[Online]. Available: www.aenor.com
[21] Seccond, “¿Qué es ISO 27001? | Seccond.” https://www.seccond.es/que-es-iso-
27001-resumen-de-la-norma/ (accessed Jun. 08, 2022).
78 Bibliografía
[22] Tryhackme, “TryHackMe | Burp Suite: The Basics.”

https://tryhackme.com/room/burpsuitebasics (accessed Jun. 08, 2022).
[23] S0md3v, “GitHub - s0md3v/Bolt: CSRF Scanner.”
https://github.com/s0md3v/Bolt (accessed Jun. 08, 2022).
[24] Wireghoul, “dotdotpwn | Kali Linux Tools.”
https://www.kali.org/tools/dotdotpwn/ (accessed Jun. 08, 2022).
[25] Drwetter, “testssl.sh | Kali Linux Tools.” https://www.kali.org/tools/testssl.sh/
[26] Santoru, “GitHub - santoru/shcheck: A basic tool to check security headers of a
website.” https://github.com/santoru/shcheck (accessed Jul. 05, 2022).
[27] Google, “GitHub - GoogleChrome/lighthouse: Automated auditing, performance
metrics, and best practices for the web.”
https://github.com/GoogleChrome/lighthouse (accessed Jul. 05, 2022).
[28] OWASP, “OWASP Dependency-Check Project | OWASP.”
https://owasp.org/www-project-dependency-check/ (accessed Jun. 08, 2022).
[29] Nmap, “GitHub - nmap/nmap: Nmap - the Network Mapper. Github mirror of
official SVN repository.” https://github.com/nmap/nmap (accessed Jul. 07,
2022).
[30] Urbanadventurer, “GitHub - urbanadventurer/WhatWeb: Next generation web
scanner.” https://github.com/urbanadventurer/WhatWeb (accessed Jul. 07,
2022).
[31] laramies, “theharvester | Kali Linux Tools.”
https://www.kali.org/tools/theharvester/ (accessed Jun. 09, 2022).
[32] Mark C. Layton and Steven J. Ostermiller, Agile Project Management For
Dummies. 2017.
[33] K. Schwaber, “El Framework Scrum Tema 2 Referencia: Agile Project
Management with SCRUM.”
[34] Rejah Rehim, Effective Python Penetration Testing. 2016.
[35] Web Security Academy, “What is CSRF (Cross-site request forgery)? Tutorial &
Examples | Web Security Academy.” https://portswigger.net/web-security/csrf
(accessed Jul. 02, 2022).
[36] Juned Ahmed Ansari, Web Penetration Testing with Kali Linux. 2015.
Bibliografía 79
[37] DigiCert, “¿Qué es SSL, TLS y HTTPS? | DigiCert.”

https://www.websecurity.digicert.com/es/es/security-topics/what-is-ssl-tls-
https (accessed Jul. 02, 2022).
[38] Heather Adkins, Building Secure and Reliable Systems: Best Practices for
Designing, Implementing, and Maintaining Systems. 2020.
[39] MDN, “HTTP headers - HTTP | MDN.”
https://developer.mozilla.org/es/docs/Web/HTTP/Headers (accessed Jul. 02,
2022).
[40] Jeremiah Grossman, Robert Hansen, Petko D. Petkov, and Anton Rager, Cross
Site Scripting Attacks: XSS Exploits and Defense. 2011.
[41] Kaspersky, “Qué es el clickjacking y cómo evitarlo.”
https://www.kaspersky.es/resource-center/definitions/clickjacking (accessed
Jul. 02, 2022).
[42] Ambit, “¿Qué significa SIEM y cómo funciona?” https://www.ambit-
bst.com/blog/qu%C3%A9-significa-siem-y-c%C3%B3mo-funciona (accessed Jul.
07, 2022).
[43] Microsoft, “Visual Studio Code - Code Editing. Redefined.”
https://code.visualstudio.com/ (accessed Jul. 03, 2022).
[44] Offensive security, “Kali Linux | Penetration Testing and Ethical Hacking Linux
Distribution.” https://www.kali.org/ (accessed Jul. 03, 2022).
[45] GitHub, “GitHub: Where the world builds software · GitHub.”
https://github.com/ (accessed Jul. 03, 2022).
[46] MDN, “X-XSS-Protection - HTTP | MDN.”
https://developer.mozilla.org/es/docs/Web/HTTP/Headers/X-XSS-Protection
[47] MDN, “X-Frame-Options - HTTP | MDN.”
https://developer.mozilla.org/es/docs/Web/HTTP/Headers/X-Frame-Options
[48] MDN, “X-Content-Type-Options - HTTP | MDN.”
https://developer.mozilla.org/es/docs/Web/HTTP/Headers/X-Content-Type-
Options (accessed Jul. 05, 2022).
80 Bibliografía
[49] MDN, “Strict-Transport-Security - HTTP | MDN.”

https://developer.mozilla.org/es/docs/Web/HTTP/Headers/Strict-Transport-
Security (accessed Jul. 05, 2022).
[50] MDN, “Content-Security-Policy - HTTP | MDN.”
https://developer.mozilla.org/es/docs/Web/HTTP/Headers/Content-Security-
Policy (accessed Jul. 05, 2022).
[51] SerSart, “X-Permitted-Cross-Domain-Policies - SerSart.” https://sersart.com/x-
permitted-cross-domain-policies/ (accessed Jul. 07, 2022).
[52] Fluidattacks, “Insecure or unset HTTP headers - X-Permitted-Cross-Domain-
Policies | Fluid Attacks Documentation.”
https://docs.fluidattacks.com/criteria/vulnerabilities/137/ (accessed Jul. 07,
2022).
[53] GeeksforGeeks, “Encabezados HTTP | Expect-CT - GeeksforGeeks.”
https://www.geeksforgeeks.org/http-headers-expect-ct/ (accessed Jul. 07,
2022).
[54] Acuenix, “Insecure Referrer Policy - Vulnerabilities - Acunetix.”
https://www.acunetix.com/vulnerabilities/web/insecure-referrer-policy/
[55] MDN, “Cross-Origin-Embedder-Policy - HTTP | MDN.”
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-
Embedder-Policy (accessed Jul. 07, 2022).
[56] MDN, “Cross-Origin-Resource-Policy - HTTP | MDN.”
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-
Resource-Policy (accessed Jul. 07, 2022).
[57] MDN, “Cross-Origin Resource Sharing (CORS) - HTTP | MDN.”
https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS (accessed Jul. 07,
2022).
[58] Acuenix, “What Is Session Fixation | Acunetix.”
https://www.acunetix.com/blog/web-security-zone/what-is-session-fixation/
Bibliografía 81
[59] abouL3Ia, “GitHub - aboul3la/Sublist3r: Fast subdomains enumeration tool for

penetration testers.” https://github.com/aboul3la/Sublist3r (accessed Jul. 07,
2022).
Anexo I. Guía de instalación de Apolo
I.1 Guía de Instalación
En esta sección se describirán una serie de pasos necesarios para la para instalación del
entorno del proyecto:
i) Para instalar la herramienta es necesario clonar el repositorio:
git clone https://github.com/RamonFuentesM/Apolo.git

ii) Tras completar el proceso, hay que acceder a la carpeta "Herramientas", dar permisos
de ejecución al instalador y ejecutar el instalador. Son necesarios los siguientes
comandos:
cd Apolo/Herramientas/
chmod +x Installer.sh
sudo ./Installer.sh
iii) Una vez instalado, para ejecutar la herramienta es necesario acceder al directorio:
cd ..
iv) Y ejecutar la herramienta:
python3 Apolo.py
83

TFG Apolo

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

TFG Apolo

Cargado por

Copyright:

Formatos disponibles

Universidad de Castilla-La Mancha

Escuela Superior de Ingeniería Informática

Trabajo Fin de Grado

Entorno para el testeo de seguridad de

Autor: Ramón Fuentes Montoya

Capítulo 1 Introducción ______________________________________________ 1

1.2 Objetivo ___________________________________________________________ 5

1.3 Estructura del proyecto _______________________________________________ 5

Capítulo 2 Estado del Arte ____________________________________________ 7

2.2 Metodologías _______________________________________________________ 8

2.3 Herramientas del mercado ___________________________________________ 21

2.4 Escáneres para nuestro proyecto ______________________________________ 38

Capítulo 3 Metodología y Desarrollo ___________________________________ 41

3.2 Metodología de desarrollo ___________________________________________ 41

3.3 Desarrollo del entorno_______________________________________________ 43

4.1 Introducción _______________________________________________________ 53

4.2 Pruebas realizadas __________________________________________________ 53

Capítulo 5 Conclusiones y Trabajo Futuro _______________________________ 71

5.1 Conclusiones ______________________________________________________ 71

5.2 Trabajo futuro _____________________________________________________ 75

Anexo I. Título del anexo ______________________ ¡Error! Marcador no definido.

I.1 Sección _________________________________________ ¡Error! Marcador no definido.

I.2 Sección _________________________________________ ¡Error! Marcador no definido.

Ilustración 1: Ransomware WannaCry [2]. .................................................................................................. 2

Tabla 1. Herramientas para nuestro proyecto ........................................................................................... 38

Ilustración 1: Ransomware WannaCry [2].

Ilustración 2: Noticia de la BCC sobre el hackeo en Twitter en 2020 [3].

Ilustración 3: Noticia sobre el impacto del cibercrimen [4]

1.1.1 Conceptos Básicos

¿Qué es la ciberseguridad? ¿ Y la seguridad de la información?

la protección de la información digital, que se encuentra encapsulada en la seguridad de

¿Qué es un pentest o prueba de penetración?

1.3 Estructura del proyecto

Este proyecto se encuentra dividido principalmente en 4 partes que son:

En el caso de la introducción, como se ha podido ver, se comienza con algunos datos

Ilustración 4. Acciones de un pentester [8].

Se pueden dividir las pruebas realizadas en dos tipos de testing:

– Pruebas de autorización. La autorización consiste en permitir el acceso a los

2.2.2 OWASP TOP 10

2. Cryptographic Failures [11]. Este tipo de riesgo está principalmente relacionado

o Determinar qué información es sensible de acuerdo con las leyes de

diseño inseguro es mucho más difícil de reparar porque es un problema de raíz.

5. Security Misconfiguration [14]. Este tipo de riesgo está principalmente

6. Vulnerable and Outdated Components [15]. Este tipo de riesgo está

Para evitar caer en este riesgo, es necesario, entre otras medidas:

7. Identification and Authentication Failures [16]. Este tipo de riesgo está

o Asegurarse de que los inicios de sesión, el control de acceso y la validación

2.2.3 ISO 27001

Es una norma internacional que provee de los requisitos para el establecimiento,

de proteger sus activos de información esenciales”. Este sistema trata de preservar la

– Tener en consideración los riegos apreciados, su tratamiento y los requisitos de

2.3 Herramientas del mercado

Nessus es un software de escaneo de vulnerabilidades desarrollado por Tenable, Inc. Este

Ilustración 5. Pantalla Principal

Ilustración 6. Escáneres de Nessus

Ilustración 7. Flujo de trabajo de Nessus

1. Definición de parámetros. Este paso, de divide en varios tipos de parámetros. Los

Ilustración 8. Parámetros básicos (General)

Ilustración 9. Parámetros básicos (Schedule)

Ilustración 10. Parámetros básicos (Notifications)

Ilustración 11. Discovery

Ilustración 12. Assessment

Ilustración 13. Report