HackingLab UEx: Aplicación Web Interactiva para la Formación en Seguridad Web

HackingLab UEx: Aplicaci´ on Web Interactiva para la Formaci´ on en Seguridad Web Alberto L´ opez Trigo Universidad de Extremadura Escuela Polit´ ecnica de C´ aceres [email protected] Javier Alonso D´ ıaz Universidad de Extremadura Escuela Polit´ ecnica de C´ aceres ja[email protected] Agust´ ın Javier Di Bartolo Universidad de Extremadura Escuela Polit´ ecnica de C´ aceres [email protected] Jos´ e Carlos Sancho N´ u˜ nez Universidad de Extremadura Centro Universitario de M´ erida [email protected] Mar´ ıa Mar ´ Avila Vegas Universidad de Extremadura Escuela Polit´ ecnica de C´ aceres mma[email protected] Resumen—La cantidad de ataques cibern´ eticos que se producen en la actualidad y sus consecuencias son la raz´ on de que las organizaciones destinen gran parte de sus recursos a la ciberseguridad. La falta de talento en ciberseguridad es un caldo de cultivo perfecto para la proliferaci´ on de vulnerabilidades. Este art´ ıculo propone el dise˜ no de una aplicaci´ on web enfocada a la formaci´ on de los desarrolladores, donde puedan aprender sobre programaci´ on segura y enfrentarse a los riesgos m´ as comunes de una aplicaci´ on web. La aplicaci´ on pone a disposici´ on del usuario dos escenarios: uno vulnerable que permite explotar c´ odigo, y otro seguro ante ataques. El usuario puede comprobar y examinar el c´ odigo de los dos escenarios, adem´ as de poder elegir el lenguaje de programaci´ on que se muestra. De esta forma, tiene la oportunidad de comparar el c´ odigo seguro y el vulnerable en diferentes lenguajes de programaci´ on, adquiriendo una doble visi´ on: como pentester y desarrollador. Index Terms—Ciberseguridad, Web App; CTF; OWASP; Seguridad Web, Formaci´ on, Software Seguro. Tipo de contribuci´ on: Formaci´ on e innovaci´ on educativa I. INTRODUCCI´ ON Aunque la tecnolog´ ıa y las aplicaciones web no son nada nuevo y llevan d´ ecadas entre nosotros, a´ un siguen en auge. El papel que desempe˜ nan es fundamental para la mayor´ ıa de las industrias y para nuestro d´ ıa a d´ ıa: entretenimiento, comercio en l´ ınea, tr´ amites con las administraciones p´ ublicas y un largo etc´ etera. A pesar de su relevancia, la seguridad de las aplicaciones web se pasa por alto. Este reporte realizado por la Agencia de la Uni´ on Europea para la Ciberseguridad (ENISA) [1] revela que muchas de las debilidades detectadas est´ an relacionadas con la tecnolog´ ıa web. Este tipo de vulnerabilidades tienden a ser los objetivos principales de los ciberdelincuentes, ya que puede servir como punto de entrada para acceder a la red de la v´ ıctima. Este tipo de comportamiento est´ a recogido en el framework MITRE ATT&CK como t´ ecnica T1190 [2]. Las empresas y las organizaciones no ignoran la ciberseguridad, para ellos es muy importante y la tienen en cuenta. Encuestas realizadas por ENISA indican que el gasto medio en seguridad de la informaci´ on (SI) de los operadores de servicios esenciales y proveedores de servicios digitales en la Uni´ on Europea fue de 700.000 euros en 2022, mientras que el gasto medio en 2023 fue de 5,1 millones de euros [3]. El principal problema que encuentran las industrias a la hora de adoptar medidas de ciberseguridad y planes ante ataques, es la falta de personal y talento. Esto se conoce como la cybersecurity skill gap [4]. Seg´ un el Information Systems Audit and Control Association (ISACA) [5], el estado actual de la ciberseguridad es desolador: una mano de obra envejecida junto con poca oferta de puestos de trabajo de nivel b´ asico. ISACA tambi´ en menciona la existencia de barreras para los noveles que quieren dedicarse al sector (gatekeeping) y denuncia que las descripciones de los nuevos puestos de trabajo son problem´ aticos. Si esto se suma al agotamiento sufrido por los empleados y la incertidumbre econ´ omica actual, el resultado es la falta de profesionales dentro del sector de la ciberseguridad. La estrategia de la Uni´ on Europea para afrontar la cyber skill gap es fomentar programas e iniciativas centradas en formar a los estudiantes de ense˜ nanza superior [6]. Estos programas se centran en solventar la falta de oferta educativa en ciberseguridad, la escasa interacci´ on con la industria, la poca comprensi´ on del mercado laboral, las plataformas desfasadas o poco realistas en los entornos educativos y las dificultades para seguir el ritmo del mundo exterior [7]. Sin embargo, aunque se resolviera la falta de profesionales en ciberseguridad, la responsabilidad de desarrollar software seguro y resiliente no deber´ ıan recaer ´ unicamente en los expertos en ciberseguridad. Sigue existiendo la necesidad de formar a los desarrolladores tanto en desarrollo seguro como en testing, ya que juegan un papel crucial en detectar vulnerabilidades en el software y parchearlos. La cyber skill gap tambi´ en afecta a los programadores: la falta de formaci´ on y concienciaci´ on de los desarrolladores es la principal causa de las vulnerabilidades. Si no se centran los esfuerzos en ense˜ nar a los desarrolladores c´ omo programar c´ odigo seguro (sobretodo a los perfiles j´ unior), seguir´ an proliferando las vulnerabilidades en las aplicaciones web. Esto presenta un riesgo real de ser atacados por agentes externos malintencionados. En el trabajo desarrollado por Gasiba T., Lechner U. y Pinto-Albuquerque M. [8], los autores proponen un juego basado en desaf´ ıos cuyo objetivo es la de concienciar y JNIC 2024 ISBN:978-84-09-62140-8 182 formar a desarrolladores de software sobre c´ omo programar c´ odigo seguro. Como resultado, los programadores que han participado respondieron positivamente ante la actividad. Este trabajo propone el desarrollo de una aplicaci´ on web para la formaci´ on en desarrollo de software seguro, enfocada en la programaci´ on web. La propuesta consiste en una aplicaci´ on web que se ejecuta en la m´ aquina del usuario, donde este pueda adquirir conocimientos sobre las vulnerabilidades m´ as importantes de las aplicaciones web. Adem´ as, la aplicaci´ on presenta una serie de laboratorios que muestran dos escenarios: un escenario vulnerable, donde se simula una aplicaci´ on web con una serie de vulnerabilidades implementadas de forma intencional para que el desarrollador pueda poner en pr´ actica sus habilidades como pentester; y un escenario seguro, donde las vulnerabilidades existentes en el escenario vulnerable est´ an parcheadas y el usuario sea incapaz de realizar con ´ exito un ataque. La presencia de estos dos escenarios seleccionables, junto con la presentaci´ on del c´ odigo responsable de cada escenario y el material did´ actico, tiene como objetivo desarrollar una doble visi´ on al desarrollador: tanto de pentester, capaz de detectar vulnerabilidades y explotarlas mediante ataques, como de desarrollador de software seguro, capaz de solventar las debilidades y tapar los agujeros de seguridad presentes en el software que desarrolla. Las contribuciones de este art´ ıculo se detallan a continuaci´ on: 1. El estudio y la comparativa de las distintas aplicaciones web vulnerables para la formaci´ on en seguridad y pentesting web. 2. La creaci´ on de una aplicaci´ on web para la formaci´ on en competencias en seguridad web con dos escenarios simult´ aneos: uno seguro y otro vulnerable. De esta forma, se proporcionan dos enfoques distintos al usuario: como desarrollador de software seguro y como tester de c´ odigo. Adem´ as, la aplicaci´ on soporta varios lenguajes de programaci´ on populares que el usuario puede elegir: Java, Python y Node.js 3. La r´ eplica de 7 vulnerabilidades que se encuentran dentro de las 5 categor´ ıas de los riesgos m´ as habituales y destacables de la seguridad web. II. ESTADO DEL ARTE En la literatura, se han propuesto diversas plataformas y aplicaciones web que son dise˜ nadas intencionadamente con vulnerabilidades. Por ejemplo, algunas contribuciones implementan cursos de seguridad web basados en el OWASP Top 10, destacando los desaf´ ıos de impartir este plan de estudios a trav´ es de la educaci´ on a distancia [9]. Otros trabajos proponen cursos universitarios de seguridad web con ejercicios pr´ acticos para inculcar la mentalidad de seguridad [10]. Adem´ as, se han desarrollado herramientas espec´ ıficas para la ense˜ nanza de desarrollo web seguro en cursos de inform´ atica universitaria, utilizando entornos virtualizados [11]. Por otro lado, existe un enfoque distinto que se centra en la metodolog´ ıa de ense˜ nanza pr´ actica en ciberseguridad. Mukherjee y colaboradores revisan y modernizan los conocimientos existentes para ayudar a los educadores en el dise˜ no de asignaturas de ciberseguridad [12]. Asimismo, Bratus S. et al. comparten su experiencia aplicando los principios del Curr´ ıculum Hacker en programas de educaci´ on para estudiantes universitarios. II-A. Vulnerabilidades comunes A continuaci´ on se presentan los dos proyectos m´ as relevantes cuyo objetivo es recoger las vulnerabilidades m´ as comunes y significativas dentro del software y del desarrollo de aplicaciones web: el OWASP Top Ten y el CWE Top 25. II-A1. OWASP Top Ten: El OWASP Top Ten [13] es un documento de concienciaci´ on sobre seguridad en aplicaciones web, enfocado hacia los desarrolladores y profesionales de la seguridad web. Este proyecto es creaci´ on de la fundaci´ on Open Web Application Security Project (OWASP) y se publica una nueva versi´ on cada 3 o 4 a˜ nos. El objetivo de este documento es identificar las vulnerabilidades m´ as comunes y relevantes de las aplicaciones web, as´ ı como establecer una clasificaci´ on de las 10 categor´ ıas de riesgos m´ as importantes. Esto se basa en estad´ ısticas proporcionadas por distintas organizaciones y encuestas a expertos en seguridad web. Cada categor´ ıa contiene informaci´ on sobre los riesgos, incluyendo descripci´ on, prevenci´ on y ejemplos, junto con referencias adicionales y los CWEs (Common Weakness Enumerations) que forman dicha categor´ ıa. II-A2. MITRE CWE Top 25: El Common Weakness Enumeration (CWE) [14] es una lista de debilidades presentes en el software y en el hardware desarrollada por la comunidad. Esta lista ayuda a conocer y clasificar las debilidades en el software, firmware, hardware y componentes existentes que pueden contribuir a la introducci´ on de vulnerabilidades. Esta lista est´ a mantenida por MITRE y el Homeland Security Systems Engineering and Development Institute (HSSEDI), y cuenta con un gran apoyo por parte de la comunidad que participa activamente en el desarrollo del proyecto. Esta lista se actualiza 3 o 4 veces por a˜ no y cuenta con algunas agrupaciones de debilidades m´ as espec´ ıficas, como por ejemplo el Common Weakness Enumeration (CWE) Top 25 Most Dangerous Software Weaknesses list (CWE Top 25) [15]. El CWE Top 25 es un subconjunto del la lista CWE, en donde se agrupan las 25 debilidades m´ as peligrosas presentes en el software. Esta lista, que es actualizada cada a˜ no o dos a˜ nos, se confecciona a partir de los datos proporcionados por los equipos del Common Vulnerabilities and Exposures (CVE), del National Institute of Standards and Technology (NIST), del National Vulnerability Database (NVD) y del Common Vulnerability Scoring System (CVSS). II-A3. Comparativa OWASP Top Ten y CWE Top 25: Las dos listas presentadas previamente que recogen vulnerabilidades comunes, OWASP Top Ten y CWE Top 25, presentan las siguientes diferencias: 1. El CWE Top 25 recoge m´ as vulnerabilidades (25) que el OWASP Top Ten (10). Eso s´ ı, el OWASP Top Ten se compone de categor´ ıas de riesgo que agrupan varios CWEs. 2. El OWASP Top Ten se enfoca en los riesgos en aplicaciones web, mientras quel CWE Top 25 se centra en las debilidades en el software en general. 3. La frecuencia de actualizaci´ on de las dos listas son distintas: mientras que OWASP renueva su lista cada 3o4a˜ nos, MITRE actualiza su top cada a˜ no o dos. HackingLab UEx: Aplicaci´on Web Interactiva para la Formaci´on en Seguridad Web 183 Tabla I COMPARATIVA DE APLICACIONES WEB VULNERABLES DVWA Webgoat Juice Shop Web Security Academy Lenguaje PHP Java Javascript (Node) Desconocido N´ umero de vulnerabilidades 14 10 15 25 Tipos de vulnerabilidades Vulnerabilidades web Vulnerabilidades web Vulnerabilidades web Vulnerabilidades web Enfoque - Desarrollo seguro - Pentesting - Desarrollo seguro - Pentesting Pentesting -Desarrollo seguro - Pentesting Instalaci´ on/uso - Instalaci´ on local - Docker container - LAMP Stack - Docker container - Node - Docker container - Proveedor de cloud (Google, AWS, Azure, etc.) Registro online 4. A diferencia del CWE Top 25, el OWASP Top Ten no solo se centra en los datos. Tambi´ en agrega a la ecuaci´ on encuestas y votaciones realizadas a la comunidad de expertos en seguridad web para representar riesgos y vulnerabilidades que est´ an en alza pero a´ un no aparecen en los datos. En este art´ ıculo se va a centrar en el OWASP Top Ten por su enfoque hacia la seguridad web. Sin embargo, como se ha mencionado, las categor´ ıas del top contienen varios CWEs, muchos de los cuales est´ an presentes en el CWE Top 25. II-B. Aplicaciones vulnerables para la formaci´ on en seguridad web En este subapartado se presentan 4 aplicaciones web vulnerables que se utilizan para la formaci´ on y concienciaci´ on en seguridad web. Las herramientas vulnerables estudiadas en este art´ ıculo son: DVWA, WebGoat, Juice Shop y Web Security Academy. II-B1. DVWA: Damn Vulnerable Web Application (DVWA) [16] es una web desarrollada con PHP y MySQL que, de forma intencional, presenta vulnerabilidades. Est´ a dirigida tanto a profesionales de la seguridad, para poner a prueba sus habilidades en un entorno legal, como a los desarrolladores de aplicaciones web, para que comprendan mejor los procesos de seguridad en el desarrollo web. La aplicaci´ on presenta una interfaz web que contiene una serie de apartados que corresponden a las vulnerabilidades presentes en la aplicaci´ on. El objetivo de DVWA es permitir que el usuario practique ataques contra algunas de las vulnerabilidades web m´ as comunes, permitiendo seleccionar la dificultad de los retos. II-B2. WebGoat: WebGoat [17] es una aplicaci´ on web intencionadamente insegura mantenida por OWASP, dise˜ nada para ense˜ nar sobre seguridad en aplicaciones web. Est´ a desarrollada en Java y ofrece un entorno interactivo compuesto por retos. El proyecto se basa en el OWASP Top Ten, mostrando los fallos de seguridad m´ as comunes de las aplicaciones web en el lado del servidor. II-B3. Juice Shop: OWASP tambi´ en nos ofrece Juice Shop [18], una de las aplicaciones web inseguras m´ as modernas, desarrollada en Angular y Node.js. A diferencia de las aplicaciones web vulnerables mencionadas anteriormente, Juice Shop se enfoca especialmente en los pentesters y expertos en ciberseguridad. Esta aplicaci´ on est´ a dise˜ nada para ser utilizada en retos Capture The Flag (CTF), para realizar demostraciones y concienciar al p´ ublico sobre la seguridad web, adem´ as de servir como entorno de pruebas para el desarrollo de herramientas de seguridad web. Juice Shop abarca todas las vulnerabilidades presentes en el OWASP Top Ten, as´ ı como otros fallos de seguridad comunes en aplicaciones del mundo real. II-B4. Web Security Academy: PortSwigger Web Security Academy [19] es un recurso online gratuito para el entrenamiento y formaci´ on en seguridad web. Se actualiza constantemente y ofrece una amplia variedad de teor´ ıa y actividades interactivas sobre vulnerabilidades web. Adem´ as, incluye los Learning Paths, que son una recopilaci´ on de material enfocado en una tem´ atica espec´ ıfica. Esta plataforma, tambi´ en proporciona una certificaci´ on llamada Burp Suite Certified Practitioner (BSCP) para que los profesionales de la seguridad web puedan demostrar su competencia en este ´ area. II-B5. Comparativa de herramientas vulnerables: En la Tabla I se realiza una comparaci´ on de las aplicaciones web vulnerables para la formaci´ on de la seguridad web. Se puede observar en la Tabla I que las aplicaciones web vulnerables se centran m´ as en el perfil del pentester y de los profesionales de la seguridad que en el perfil del desarrollador web. Su contenido se enfoca en ense˜ nar al usuario c´ omo llevar a cabo un ataque, dejando en segundo plano la ense˜ nanza sobre c´ omo escribir c´ odigo seguro. Adem´ as, se nota la ausencia de la posibilidad de visualizar el c´ odigo que se est´ a ejecutando en los laboratorios en la mayor´ ıa de las aplicaciones analizadas. La ´ unica excepci´ on es DVWA, que permite al usuario ver el c´ odigo utilizado en la dificultad seleccionada mediante un bot´ on en el men´ u. Por ´ ultimo, es importante destacar que estas aplicaciones web se enfocan principalmente en simular entornos vulnerables para practicar ataques, pero no proporcionan una comparaci´ on directa con entornos seguros. Ser´ ıa altamente beneficioso para los programadores poder distinguir entre el c´ odigo seguro y el vulnerable. Esto les permitir´ ıa no solo aprender sobre las vulnerabilidades web y los ataques asociados, sino tambi´ en comprender la diferencia entre trabajar en un entorno seguro y uno vulnerable. De esta manera, podr´ ıan desarrollar una perspectiva m´ as completa, tanto desde la perspectiva de un pentester como de un desarrollador. III. PROPUESTA DE APLICACI ´ ON En base a las conclusiones obtenidas del estado del arte, este trabajo propone el desarrollo de una herramienta web vulnerable que aborde las deficiencias identificadas en las A. L´opez Trigo, J. Alonso D´ıaz, A. J. Di Bartolo, J. C. Sancho N´u˜nez and M. Avila Vegas 184 Tabla II CATEGOR´ IAS DEL OWASP TOP TEN Categor´ ıa OWASP Top Ten Tasa de incidencias Explotaci´ on Impacto A01 P´ erdida de Control de Acceso 55.97 % 6.92 5.93 A02 Fallos Criptogr´ aficos 46.44 % 7.29 6.81 A03 Inyecci´ on 19.09 % 7.25 7.15 A04 Dise˜ no Inseguro 24.19 % 6.46 6.78 A05 Configuraci´ on de Seguridad Incorrecta 19.84 % 8.12 6.56 A06 Componentes Vulnerables y Desactualizados 27.96 % 5.00 5.00 A07 Fallos de Identificaci´ on y Autenticaci´ on 14.84 % 7.40 6.50 A08 Fallos en el Software y en la Integridad de los Datos 16.67 % 6.94 7.94 A09 Fallos en el Registro y la Monitorizaci´ on 19.23 % 6.87 4.99 A10 Falsificaci´ on de Solicitudes del Lado del Servidor (SSRF) 2.72 % 8.28 6.72 aplicaciones web analizadas en la secci´ on II-B5. Para ello, se ha dise˜ nado una metodolog´ ıa para la selecci´ on de las vulnerabilidades a integrar en los laboratorios de aplicaci´ on web vulnerable, as´ ı como para determinar las funcionalidades a implementar en la aplicaci´ on, tomando como referencia las carencias observadas en las otras aplicaciones previamente estudiadas. III-A. Selecci´ on de las vulnerabilidades La selecci´ on de las vulnerabilidades a implementar en la aplicaci´ on se ha basado en la informaci´ on proporcionada por el OWASP Top Ten[13]. Principalmente, se han estudiado las categor´ ıas que forman la lista y las estad´ ısticas por cada categor´ ıa, como la tasa de incidencia, la puntuaci´ on ponderada de impacto y explotaci´ on siguiendo el CVSS v3.0 [20] y los CWEs [14] que forman cada categor´ ıa. Para la selecci´ on de las pruebas, se parte desde el OWASP Top Ten. Se seleccionan las categor´ ıas m´ as relevantes para la primera versi´ on de la aplicaci´ on y a partir de las categor´ ıas seleccionadas, se seleccionan los CWEs m´ as importantes por cada categor´ ıa. A partir de esos CWEs, se implementan los laboratorios de la aplicaci´ on. Como se puede observar en la Tabla II, cada categor´ ıa cuenta con una tasa de incidentes, una puntuaci´ on en explotaci´ on de la vulnerabilidad y una puntuaci´ on en impacto. La tasa de incidentes es el porcentaje de aplicaciones encuestadas por OWASP en el que, al menos, una vulnerabilidad de esa categor´ ıa se encuentra presente. Para calcular las puntuaciones en explotaci´ on e impacto, OWASP ha agrupado los CWEs relacionados por cada categor´ ıa y ha ponderado las puntuaciones de Explotaci´ on e Impacto seg´ un su puntuaci´ on CVSS 3.0. En la Tabla II se representa las puntuaciones del Top Ten, siguiendo la escala de colores definida en la secci´ on Qualitative Severity Rating Scale del CVSS v3.0 [20]. A partir del Top Ten de OWASP, se han establecido una serie de requisitos para seleccionar las categor´ ıas m´ as relevantes para el proyecto y descartar las categor´ ıas que no se ajusten bien al contenido de la aplicaci´ on. Los requisitos fijados para la selecci´ on de las categor´ ıas de la clasificaci´ on propuesta por OWASP son: 1. No debe ser necesario el uso de herramientas externas para poder explotar las vulnerabilidades presentes en la aplicaci´ on. 2. Las vulnerabilidades deben ser f´ aciles de implementar. 3. Las vulnerabilidades con mayor probabilidad de aparecer en una aplicaci´ on y las m´ as relevantes para la formaci´ on del desarrollador deben estar presentes en la aplicaci´ on. 4. Las vulnerabilidades que sean m´ as propensas a manifestarse en el c´ odigo de los desarrolladores m´ as inexpertos tienen que mostrarse en la aplicaci´ on. Una vez establecidas las condiciones de selecci´ on, se escoge las siguientes categor´ ıas para la primera versi´ on de la aplicaci´ on: A01:2021 – P´ erdida de Control de Acceso A02:2021 – Fallos Criptogr´ aficos A03:2021 – Inyecci´ on A04:2021 – Dise˜ no Inseguro A10:2021 – Falsificaci´ on de Solicitudes del Lado del Servidor (SSRF) Las primeras 2 categor´ ıas (A01 y A02) cuentan con la mayor tasa de incidencias del Top Ten y presentan un riego medio y alto de explotaci´ on e impacto seg´ un la calificaci´ on CVSS. Las categor´ ıas A03 y A04 no superan en tasa de incidencias a las otras categor´ ıas que se encuentran por debajo, pero A03 y A04 son muy relevantes en la formaci´ on del desarrollador, ya que estas vulnerabilidades suelen aparecen en el c´ odigo de los programadores j´ unior y sus puntuaciones en explotaci´ on e impacto son elevadas. La ´ ultima categor´ ıa (A10), aunque cuenta con la menor tasa de incidencia de toda la lista, ocupa el primer lugar en la encuesta de la comunidad realizada por OWASP. Como se menciona en el OWASP Top Ten [13] ((Los resultados de los datos se limitan principalmente a lo que podemos comprobar de forma automatizada. Si hablas con un profesional [...], te hablar´ a de las cosas que encuentra y de las tendencias que ve y que a´ un no est´ an en los datos. Se necesita tiempo para desarrollar metodolog´ ıas de pruebas para ciertos tipos de vulnerabilidades y m´ as tiempo a´ un para que esas pruebas sean automatizadas y ejecutadas contra una gran poblaci´ on de aplicaciones. Todo lo que encontramos est´ a mirando al pasado y puede que falten algunas tendencias, que a´ un no est´ an presentes en los datos)). Con las categor´ ıas de vulnerabilidades seleccionadas, se han implementado los laboratorios enunciados en la Tabla III seleccionando los CWEs m´ as significativos de cada categor´ ıa. III-B. Funciones de la aplicaci´ on Como se ha mencionado previamente, las aplicaciones web vulnerables utilizadas para la formaci´ on en seguridad est´ an m´ as centradas en el entrenamiento del perfil de pentester que en la concienciaci´ on y la formaci´ on para el desarrollador. Cabe destacar la ausencia del c´ odigo que se est´ a empleando cuando el usuario est´ a realizando un laboratorio, a excepci´ on HackingLab UEx: Aplicaci´on Web Interactiva para la Formaci´on en Seguridad Web 185 Tabla III VULNERABILIDADES IMPLEMENTADAS Ataque CWE Categor´ ıa OWASP Top 10 SQL Injection CWE-89: Improper Neutralization of Special Elements used in an SQL Command (’SQL Injection’) A03 Inyecci´ on Password Storing CWE-328: Use of Weak Hash A02 Fallos Criptogr´ aficos CWE-759: Use of a One-Way Hash without a Salt CWE-312: Cleartext Storage of Sensitive Information A04 Dise˜ no Inseguro Cross-Site Scripting (XSS) CWE-79: Improper Neutralization of Input During Web Page Generation (’Cross-site Scripting’) A03 Inyecci´ on Path Traversal CWE-22: Improper Limitation of a Pathname to a Restricted Directory (’Path Traversal’) A01 P´ erdida de Control de Acceso Server-Side Request Forgery (SSRF) CWE-918: Server-Side Request Forgery (SSRF) A10 Falsificaci´ on de Solicitudes del Lado del Servidor (SSRF) Insecure Direct Object References (IDOR) CWE-639: Authorization Bypass Through User-Controlled Key A01 P´ erdida de Control de Acceso Input Validation CWE-20: Improper Input Validation A03 Inyecci´ on de la herramienta DVWA. Esta aplicaci´ on nos permite consultar el c´ odigo en PHP responsable de la prueba que el usuario est´ e completando en ese momento. Despu´ es del an´ alisis de las aplicaciones web vulnerables para la formaci´ on en seguridad web del apartado II-B5, se ha decidido implementar las siguientes funcionalidades en nuestra soluci´ on de herramienta web vulnerable: 1. La implementaci´ on de una serie de pruebas (laboratorios) con las vulnerabilidades que se han seleccionado previamente. Los laboratorios estar´ an formados por dos escenarios: Un escenario vulnerable en el que el usuario sea capaz de realizar un ataque con ´ exito y un escenario seguro en el que el usuario no pueda ejecutar un ataque de forma exitosa. 2. En cada laboratorio se mostrar´ a en pantalla el c´ odigo que est´ a involucrado. Si se ha seleccionado el escenario vulnerable, se expone el c´ odigo vulnerable responsable de la prueba y viceversa. 3. El contenido de la aplicaci´ on estar´ a dividido en secciones organizadas por las vulnerabilidades implementadas en la Tabla III. Por cada secci´ on habr´ a contenido did´ actico que explique la vulnerabilidad, c´ omo funcionan los distintos ataques, el impacto derivado de un ataque y las distintas medidas para subsanar la vulnerabilidad. 4. La aplicaci´ on contar´ a con soporte para varios lenguajes de programaci´ on. El usuario podr´ a seleccionar el lenguaje en el que quiera formarse y realizar las pruebas propuestas. Con las vulnerabilidades seleccionadas y las funciones de la aplicaci´ on definidas, se procede al dise˜ no de la herramienta web vulnerable. IV. DISE ˜ NO Y ARQUITECTURA DE LA APLICACI ´ ON Para el dise˜ no de la aplicaci´ on web vulnerable se ha seguido la arquitectura m´ as com´ un en el desarrollo web, como se muestra en la Figura 1: Separar la aplicaci´ on en front-end yback-end. Estos componentes se comunicar´ an entre s´ ı por HTTP mediante una API Restful. Figura 1. Arquitectura de la aplicaci´ on: Paso 0 El problema de esta arquitectura es la falta de soporte multilenguaje que se requiere para este proyecto: Aunque el front-end sea com´ un para todos los usuarios, el back-end deber´ ıa esta implementado en el lenguaje de programaci´ on que el usuario ha elegido dentro de la aplicaci´ on. Adem´ as, el usuario debe tener la opci´ on de seleccionar otro lenguaje de programaci´ on mientras est´ a utilizando la aplicaci´ on de forma instant´ anea, para poder comparar las diferentes implementaciones que se muestran en la p´ agina. Para resolver este inconveniente, se ha a˜ nadido un proxy inverso en la arquitectura de la aplicaci´ on entre el front-end y el back-end, y se ha implementado varios back-ends con distintos lenguajes de programaci´ on con la misma definici´ on de la API. Este dise˜ no se representa en la Figura 2. Figura 2. Arquitectura de la aplicaci´ on: Paso 1 As´ ı, en la selecci´ on del lenguaje, el proxy se encarga de A. L´opez Trigo, J. Alonso D´ıaz, A. J. Di Bartolo, J. C. Sancho N´u˜nez and M. Avila Vegas 186 Figura 3. Pantalla de la aplicaci´ on: laboratorio SQL Injection redirigir el tr´ afico al back-end seleccionado por el usuario, sin que el front-end tenga toda la responsabilidad de esta tarea. Adem´ as, como los 3 back-ends implementan la misma API, el front-end no tiene que modificar las solicitudes HTTP, independientemente del backend que reciba la solicitud. Figura 4. Arquitectura final de la aplicaci´ on Para poder desplegar la aplicaci´ on en una misma m´ aquina para que el usuario pueda utilizar el programa en local, cada componente est´ a contenido en una imagen de Docker y el despliegue est´ a definido en un archivo docker-compose.yml. El usuario simplemente desplegar´ ıa la aplicaci´ on utilizando el programa docker compose y ya tendr´ ıa disponible la aplicaci´ on web en su m´ aquina local. En la Figura 4 se describe la arquitectura final de la aplicaci´ on web vulnerable. V. RESULTADOS En la Figura 3 se muestra la aplicaci´ on web vulnerable y los distintos componentes que forman el men´ u resaltados y enumerados. En la mencionada Figura 3, se aprecia que el selector de lenguaje (1) se encuentra en la barra superior de la aplicaci´ on. En esta versi´ on, la aplicaci´ on soporta Java, Python y Node.js. Las secciones de la aplicaci´ on (2) las forman las vulnerabilidades que se seleccionaron en el apartado III-A, y cada secci´ on est´ a formada por tres apartados: Overview: En esta secci´ on se proporciona una descripci´ on general de la vulnerabilidad, se explican los mecanismos de los ataques, se discute el alcance del impacto y se detallan las medidas para detectar y prevenir la vulnerabilidad. Code: Este apartado comienza analizando el c´ odigo vulnerable utilizado en la prueba. Posteriormente, se procede a implementar, paso a paso, diversas medidas y buenas pr´ acticas para transformar el c´ odigo en una versi´ on segura, resistente a ataques. Test: En esta parte se realiza la implementaci´ on del laboratorio presentado en la Figura 3. Aqu´ ı se proporciona al usuario un entorno para llevar a cabo ataques contra la aplicaci´ on. Dependiendo del escenario seleccionado, el usuario puede tener ´ exito o no en sus intentos de ataque. Observando la Figura 3, se puede examinar con mayor HackingLab UEx: Aplicaci´on Web Interactiva para la Formaci´on en Seguridad Web 187 Figura 5. Comparaci´ on entre escenario vulnerable y seguro detalle los laboratorios de la aplicaci´ on. Cada laboratorio est´ a compuesto por una pantalla principal (3) que simula una aplicaci´ on web, ofreciendo al usuario la posibilidad de realizar ataques. Para elegir entre el escenario vulnerable y el seguro, la aplicaci´ on dispone de un selector (4). Finalmente, debajo de la pantalla principal (5), se muestra el c´ odigo correspondiente, ya sea vulnerable o seguro, dependiendo del escenario seleccionado. Adem´ as, el resultado del ataque (6) se presenta m´ as abajo en la interfaz. En la Figura 5 se expone los distintos resultados que arroja el escenario vulnerable y el escenario seguro ante el mismo ataque. En el laboratorio SQL Injection presentado tambi´ en en la Figura 3, se realiza un ataque de inyecci´ on SQL en el formulario de login con el siguiente payload:((b’ or ’1’ = ’1)). El resultado del escenario vulnerable, representado a la derecha de la Figura 5, se muestra como el ataque ha finalizado de forma exitosa. Esto se expone en la secci´ on recieved response, que muestra todos los usuarios existentes en la base de datos. En cambio, en la parte izquierda de la Figura 5, se observa como el ataque no ha sido satisfactorio en el escenario seguro. Comparando con la respuesta recibida en el escenario vulnerable, el escenario seguro no muestra ning´ un usuario existente de la base de datos. Cabe destacar que el c´ odigo que se muestra en los dos escenarios son diferentes, aunque en la Figura 5 no se pueda apreciar. en el Listado 1 se encuentra el c´ odigo vulnerable del laboratorio SQL Injection y en el Listado 2 se encuentra el c´ odigo seguro del mismo laboratorio. Ambos est´ an programados en Python. Observando el c´ odigo, se puede descifrar el porqu´ e de los resultados de cada escenario ante el mismo ataque. En el Listado 1, correspondiente al escenario vulnerable, vemos como los par´ ametros email ypassword son directamente concatenados en una cadena de caracteres que forma la cl´ ausula WHERE de una sentencia SQL. Como el c´ odigo no hace ning´ un tipo de validaci´ on, es posible introducir caracteres y palabras clave que el int´ erprete de consultas SQL interpretar´ a como parte de la consulta leg´ ıtima. De esta forma, con el payload ((b’ or ’1’ = ’1)), la cl´ ausula WHERE quedar´ ıa de esta forma: ((WHERE email = ’a’ and password = ’b’ or ’1’=’1’)). Como la condici´ on ((’1’=’1’)) siempre se cumple para todas las filas de la tabla, la aplicaci´ on devuelve todas las filas que hay en la tabla. En cambio, en el Listado 2, correspondiente al escenario seguro, vemos como se hace uso de una consulta parametrizada. De esta forma, el int´ erprete de consultas SQL puede diferenciar entre la consulta y los datos introducidos por el usuario. As´ ı, evita la inyecci´ on de caracteres y palabras clave del lenguaje SQL dentro de la consulta. A. L´opez Trigo, J. Alonso D´ıaz, A. J. Di Bartolo, J. C. Sancho N´u˜nez and M. Avila Vegas 188 1def vulnerableLogin(db: Session, email: str, password:str): 2return db.query(models.User) 3.filter(text("email = ’" + email + "’ and password = ’" + password + "’")) 4.all() Listado 1. C´ odigo vulnerable en Python 1def secureLogin(db: Session, email: str, password:str): 2return db.query(models.User) 3.filter(models.User.email == email, models.User.password == password) 4.all() Listado 2. C´ odigo seguro en Python VI. CONCLUSIONES Y TRABAJOS FUTUROS Este trabajo propone una aplicaci´ on web vulnerable con un enfoque educativo dirigido espec´ ıficamente a desarrolladores de software. La aplicaci´ on es multiplataforma y admite tres de los lenguajes de programaci´ on m´ as populares: Java, Python y Node.js. Permite al usuario elegir entre dos escenarios simult´ aneos: uno seguro y otro vulnerable, ofreciendo as´ ı dos perspectivas diferentes: la de desarrollador de software seguro y la de pentester. Adem´ as, la aplicaci´ on ofrece la posibilidad de replicar siete ataques que se encuentran entre las cinco categor´ ıas m´ as destacadas de riesgos de seguridad en las aplicaciones web. Este proyecto sigue en desarrollo con el objetivo de ampliar las habilidades de seguridad de sus usuarios. Los esfuerzos se centran en replicar un mayor n´ umero de vulnerabilidades, admitir nuevos lenguajes de programaci´ on, crear un entorno de consulta online y aislado que garantice la seguridad, y desarrollar un panel de gamificaci´ on para analizar el progreso en las competencias adquiridas por los usuarios. AGRADECIMIENTOS Cabe destacar que esta iniciativa se realiza en el marco de los fondos del Plan de Recuperaci´ on, Transformaci´ on y Resiliencia, financiados por la Uni´ on Europea (Next Generation) en el marco del proyecto con referencia C109/23 ((Proyecto estrat´ egico UEx (Escuela Polit´ ecnica de C´ aceres)-INCIBE)). REFERENCIAS [1] E. U. A. for Cybersecurity, I. Lella, C. Ciobanu, E. Tsekmezoglou, M. Theocharidou, E. Magonara, A. Malatras, and R. Svetozarov Naydenov, ENISA threat landscape 2023 – July 2022 to June 2023, I. Lella, C. Ciobanu, M. Theocharidou, E. Magonara, A. Malatras, R. Svetozarov Naydenov, and E. Tsekmezoglou, Eds., 2023. [2] “Exploit public-facing application, technique t1190 - enterprise — mitre att&ck®.” [Online]. Available: https://attack.mitre.org/techniques/ T1190/ [3] E. U. A. for Cybersecurity, M. Adamczyk, A. Drougkas, E. Philippou, P. Abel, F. Gratiolet, and E. Maaskant, NIS investments – Cybersecurity policy assessment – November 2023. European Union Agency for Cybersecurity, 2023. [4] C. A. Ramezan, “Examining the cyber skills gap: An analysis of cybersecurity positions by sub-field,” Journal of Information Systems Education, vol. 34, no. 1, pp. 94–105, 2023. [Online]. Available: Availableat:https://aisel.aisnet.org/jise/vol34/iss1/8 [5] ISACA, “State of cybersecurity 2023: Global update on workforce efforts, resources and cyberoperations state of cybersecurity,” 2023. [6] E. U. A. for Cybersecurity, J. R. Nurse, K. Adamos, A. Grammatopoulos, and F. Di Franco, Addressing the EU cybersecurity skills shortage and gap through higher education, 2021. [7] E. U. A. for Cybersecurity, T. De Zan, and F. Di Franco, Cybersecurity skills development in the EU – The certification of cybersecurity degrees and ENISA’s Higher Education Database. European Network and Information Security Agency, 2019. [8] T. Gasiba, U. Lechner, and M. Pinto-Albuquerque, “Cybersecurity challenges for software developer awareness training in industrial environments,” in Innovation Through Information Systems, F. Ahlemann, R. Sch¨ utte, and S. Stieglitz, Eds. Cham: Springer International Publishing, 2021, pp. 370–387. [9] B. Ksiezopolski, K. Mazur, M. Miskiewicz, and D. Rusinek, “Teaching a hands-on ctf-based web application security course,” Electronics (Switzerland), vol. 11, 11 2022. [10] T. Srivatanakul and T. Moore, “Promoting security mindset through hands-on exercises for computer science undergraduate students,” in 2021 2nd Information Communication Technologies Conference (ICTC), 2021, pp. 343–347. [11] L.-C. Chen and L. Tao, “Teaching web security using portable virtual labs,” in 2011 IEEE 11th International Conference on Advanced Learning Technologies, 2011, pp. 491–495. [12] M. Mukherjee, N. T. Le, Y.-W. Chow, and W. Susilo, “Strategic approaches to cybersecurity learning: A study of educational models and outcomes,” Information, vol. 15, p. 117, 2 2024. [13] “Owasp top 10:2021.” [Online]. Available: https://owasp.org/Top10/ [14] “Cwe - common weakness enumeration.” [Online]. Available: https://cwe.mitre.org/about/index.html [15] “Cwe - cwe top 25 most dangerous software weaknesses.” [Online]. Available: https://cwe.mitre.org/top25/ [16] “Github - digininja/dvwa: Damn vulnerable web application (dvwa).” [Online]. Available: https://github.com/digininja/DVWA [17] “Github - webgoat/webgoat: Webgoat is a deliberately insecure application.” [Online]. Available: https://github.com/WebGoat/WebGoat [18] “Github - juice-shop/juice-shop: Owasp juice shop: Probably the most modern and sophisticated insecure web application.” [Online]. Available: https://github.com/juice-shop/juice-shop [19] “Web security academy: Free online training from portswigger.” [Online]. Available: https://portswigger.net/web-security [20] “Cvss v3.0 specification document.” [Online]. Available: https: //www.first.org/cvss/v3.0/specification-document HackingLab UEx: Aplicaci´on Web Interactiva para la Formaci´on en Seguridad Web 189