OWASP Top 10 en máquina bWAPP

Secciones

1. Introducción:

Este post es la resolución al ejercicio: https://github.com/breatheco-de/owasp-top10-exercises.git

En el ámbito de la seguridad informática, las vulnerabilidades en aplicaciones web representan uno de los riesgos más críticos para organizaciones y usuarios. El proyecto OWASP Top 10 destaca las amenazas más recurrentes y peligrosas, sirviendo como guía esencial para desarrolladores, auditores y profesionales de la ciberseguridad. Este documento se enfoca en explorar estas vulnerabilidades mediante la plataforma educativa bWAPP (Buggy Web Application), un entorno controlado diseñado para practicar técnicas de identificación, explotación y mitigación de fallos de seguridad.

A lo largo de este informe, se detallan paso a paso ejemplos prácticos de las 10 vulnerabilidades principales del OWASP, desde Broken Access Control hasta el uso de Componentes Vulnerables y Desactualizados. Cada sección incluye demostraciones en bWAPP, utilizando herramientas como MySQL para análisis de bases de datos, inyecciones SQL, scripts XSS y técnicas de fuerza bruta con John the Ripper. El objetivo es proporcionar una comprensión clara de cómo explotar estas fallas, así como concienciar sobre la importancia de implementar medidas de seguridad robustas desde el diseño hasta la monitorización continua.

2. Broken Access Control – Insecure DOR (Change Secret)

Broken Access Control son vulnerabilidades en las aplicaciones web que ocurre cuando los controles que restringen el acceso a recursos o funcionalidades no están implementados correctamente.

Crear un nuevo usuario

Accede a la interfaz web de bWAPP desde tu navegador usando la dirección IP de la máquina beebox.
Inicia sesión en bWAPP:

Usuario: bee
Contraseña: bug

Crea un nuevo usuario:

Crea un usuario llamado geeks con el secret: secret test.

Verificación en MySQL

Abre la terminal en la VM Beebox.
Accede a MySQL usando el siguiente comando:

mysql -u root -p

💡 La contraseña predeterminada: bug

Selecciona la base de datos de bWAPP:

USE bWAPP;

Verifica que el usuario geeks y su «secret» hayan sido creados:

SELECT * FROM users;

Modificación del secreto de otro usuario

Selecciona la vulnerabilidad Insecure DOR (Change Secret) y «Hack».
Inspeccionar el Formulario HTML.

En el código HTML inspeccionado, localiza el valor del campo oculto (input) que contiene el valor «bee».
Cambia este valor por «geeks» para que, al enviar el formulario, se modifique el «secret» del usuario geeks en lugar del usuario bee.
Cambia el «secret» a hello geeks en el formulario, y envíalo.

Comprobación en la Base de Datos:

Vuelve a la terminal de MySQL.
Verifica que el «secret» del usuario geeks haya sido modificado:

SELECT * FROM users;

Deberías ver que el «secret» ha cambiado a «hello geeks».

3. Identification & authentication failures – Broken Authentication

La autenticación rota es una vulnerabilidad de seguridad crítica que surge cuando las aplicaciones web no gestionan adecuadamente la autenticación de los usuarios.

Formularios de login inseguros

Selecciona la vulnerabilidad Broken Authentication/Insecure Login Forms y «Hack». Serás redirigido a una vista de formulario donde puedes probar ingresar cualquier dato, pero te dará un mensaje de Invalid credentials!.
Haz clic derecho en la página y selecciona Ver código fuente de la página en el menú. Esto abrirá una nueva pestaña con el archivo HTML.
Localiza el formulario de inicio de sesión y revisa los valores, donde verás que el nombre de usuario es tonystark y la contraseña es I am Iron Man, lo que inicialmente resulta en un mensaje de «Credenciales inválidas».

Usa estas credenciales (usuario: tonystark, contraseña: I am Iron Man) si hay un problema de autenticación rota, el sistema te dirá que el usuario ha iniciado sesión con éxito y te mostrará un mensaje.

Gestión de cierre de sesión.

Selecciona la vulnerabilidad Broken Authentication/Logout Management y «Hack». Serás redirigido a una vista donde aparece un mensaje que dice «Click to Logout».

Haz click en ese mensaje. Te pedirá una confirmación para cerrar sesión.

Haz clic en OK y serás redirigido a un formulario de inicio de sesión, lo que indica que aparentemente has cerrado sesión correctamente.

💡 Sin embargo, si usas la opción de regresar a la página anterior (presionando la flecha de «atrás» en tu navegador), verás que vuelves a la página en la que estabas antes de cerrar sesión, con acceso completo a la cuenta autenticada, lo que demuestra que el cierre de sesión no fue exitoso.

⚠ Cuando el sistema no invalida correctamente la sesión del usuario después de cerrar sesión, encontraremos vulnerabilidades críticas; ya que, aunque el usuario aparentemente cierra sesión, el servidor no invalida la sesión de manera efectiva y esto expone a los atacantes la posibilidad de acceder a una cuenta sin autorización, especialmente si utiliza un dispositivo compartido donde el usuario anterior no haya cerrado sesión correctamente.

4. Injection – SQL injection

Selecciona la vulnerabilidad SQL Injection (GET/Search) y «Hack».
Explora el formulario vulnerable. Verás un formulario con un campo para ingresar una búsqueda (generalmente llamado title o id). Ingresa un término simple, por ejemplo, test, y haz clic en Search. La URL generada de esa búsqueda será algo como:

http://<tu_ip>/bWAPP/sqli_1.php?title=test&action=search

El resultado de la búsqueda realizada será «not found» eso significa que estaremos bien, ya que test no existe en la tabla, pero no nos ha dado ningún error.

Descubre el número de columnas

Para identificar cuántas columnas devuelve la consulta original, realiza una prueba utilizando la siguiente inyección. Probemos con la consulta ORDER BY:

http://<tu_ip>/bWAPP/sqli_1.php?title=test' ORDER BY 1-- &action=search

Si no ves ningún error y solo un «not found», significa que la consulta tiene al menos una columna.

Incrementa el número del ORDER BY para seguir verificando hasta que obtengas un error de sintaxis. Por ejemplo:

http://<tu_ip>/bWAPP/sqli.php?title=test' ORDER BY 2-- &action=search

http://<tu_ip>/bWAPP/sqli.php?title=test' ORDER BY 3-- &action=search

Cuando llegues al número donde obtienes un error, significa que la consulta tiene una columna menos de la última que probaste con éxito.

Inyección con UNION SELECT

Una vez que hayas determinado el número de columnas, utiliza una inyección UNION SELECT para extraer información. Como descubrimos que había 7 columnas, escribiremos lo siguiente:

http://<tu_ip>/bWAPP/sqli.php?title=1' UNION SELECT 1, database(), version(), 4, 5, 6, 7-- &action=search

Esto te mostrará el nombre de la base de datos y la versión del servidor SQL.

Exploración de nuevas funciones

Ahora que has obtenido la base de datos y la versión del servidor, puedes explorar más funciones para obtener información adicional.

Obtención del nombre del usuario actual:

http://<tu_ip>/bWAPP/sqli_1.php?title=test' UNION SELECT 1, 2, user(), 4, 5, 6, 7-- &action=search

Obtención de los nombres de las tablas.

Realiza una consulta UNION SELECT para acceder a la tabla information_schema.tables, que contiene los nombres de las tablas en la base de datos actual. Si el número total de columnas es 7, usa la siguiente URL:

http://<tu_ip>/bWAPP/sqli_1.php?title=test' UNION SELECT 1, table_name, 3, 4, 5, 6, 7 FROM information_schema.tables WHERE table_schema=database()-- &action=search

En esta consulta:

table_name es la columna que contiene los nombres de las tablas.
table_schema=database() limita la consulta a la base de datos actual.

Siempre asegúrate de que las columnas en la consulta UNION SELECT coincidan con el número de columnas en la consulta original. La salida debería mostrar los nombres de las tablas disponibles en la base de datos.

Obtener nombres de columnas.

Una vez que tengas los nombres de las tablas, obtén las columnas de una tabla específica. Por ejemplo, si una de las tablas se llama users, usa:

http://<tu_ip>/bWAPP/sqli_1.php?title=test' UNION SELECT 1, column_name, 3, 4, 5, 6, 7 FROM information_schema.columns WHERE table_name='users'-- &action=search

Esto te devolverá los nombres de las columnas en la tabla users.

Obtener datos sensibles.

Finalmente, extrae información sensible. Si descubres una columna llamada password, puedes obtener las contraseñas (o sus hashes) con la siguiente consulta:

http://<tu_ip>/bWAPP/sqli_1.php?title=test' UNION SELECT 1, email, password, 4, 5, 6, 7 FROM users-- &action=search

Esto te mostrará los nombres de usuario y sus contraseñas.

5. Injection – Cross-site scripting (XSS) Reflected GET and POST

Cross-Site Scripting (XSS) Reflected (GET)

Selecciona la vulnerabilidad Cross-Site Scripting (XSS) Reflected (GET).
En la página que se abre, verás un formulario que solicita First name y Last name. Introduce cualquier valor en ambos campos, por ejemplo:

First name: Test

Last name: User

Al enviar el formulario, verás que los valores ingresados se muestran como un mensaje en la página y también se incluyen en la URL como parámetros GET. Algo similar a esto:

http://localhost/bWAPP/xss_get.php?firstname=Test&lastname=User

Inyectar el Script XSS en el Formulario

En lugar de valores regulares, ingresa el siguiente script en cualquiera de los campos del formulario para inyectar un ataque XSS:

First name: <script>alert(‘XSS con GET’)</script>

Last name: User (o cualquier otro valor)

Al enviar el formulario, el script se ejecutará, mostrando una alerta con el mensaje «XSS con GET».

Cross-Site Scripting (XSS) Reflected (POST)

Selecciona la vulnerabilidad Cross-Site Scripting (XSS) Reflected (POST).
En la página que se abre, verás un formulario que solicita First name y Last name. Introduce el siguiente script en cualquiera de los campos del formulario para inyectar un ataque XSS

First name: <script>alert(‘XSS con POST’)</script>

Last name: User (o cualquier otro valor)

Al enviar el formulario, el script se ejecutará, mostrando una alerta con el mensaje «XSS con POST».

Verificación de la Explotación

A diferencia del método GET, aquí no verás los parámetros en la URL, ya que se envían en el cuerpo de la solicitud POST.
Verifica que la alerta se muestre en la página, confirmando que la inyección de XSS ha sido exitosa.

💡 Sobre GET y POST en XSS:

GET: Los datos se muestran en la URL, lo que lo hace más fácil de explotar y compartir, pero más visible.
POST: Los datos se envían en el cuerpo de la solicitud, lo que hace que el ataque sea menos visible, pero más complicado de ejecutar y compartir sin interacción del usuario.

Ambos métodos permiten ejecutar scripts maliciosos en el navegador de la víctima si la página no sanitiza adecuadamente las entradas, pero cada uno tiene sus particularidades en cuanto a la explotación y visibilidad.

6. Security Misconfiguration – Local File Inclusion (LFI)

Selecciona la vulnerabilidad Remote & Local File Inclusion (RFI/LFI) para la actividad guiada y haz clic en «Hack».

⚠ Es posible que encuentres Remote & Local File Inclusion (RFI/LFI) listado en Missing Functional level access control ya que la vulnerabilidad Remote & Local File Inclusion (RFI/LFI) puede aparecer en múltiples categorías de seguridad según el contexto en el que se analice. Aunque es más común clasificarla como parte de Security Misconfiguration, en algunos casos puede estar listada bajo categorías como Missing Function Level Access Control, como lo ha hecho bWAPP.

En la página de LFI, verás una URL que incluye un parámetro para seleccionar un archivo, por ejemplo:

http://<tu_ip>/bWAPP/rlfi.php?language=lan_en.php&action=go

💡Observa que el parámetro «language» probablemente está siendo usado para incluir un archivo de idioma en la página.

Modifica el parámetro «language» para intentar incluir un archivo del sistema. Por ejemplo:

http://<tu_ip>/bWAPP/rlfi.php?language=../../../../etc/passwd&action=go

Cuando estás realizando un ataque de Local File Inclusion (LFI), el objetivo es incluir archivos que están almacenados en el servidor (donde está alojado la página que quieres atacar). En este caso, intentaremos acceder al archivo /etc/passwd, que es un archivo común en servidores Linux y que contienen información sobre los usuarios del sistema. Al modificar el parámetro «language», estás tratando de incluir un archivo del servidor donde se ejecuta bWAPP. En este caso, cuando colocas ../../../../etc/passwd en la URL, el navegador envía esa solicitud al servidor, y si la vulnerabilidad de LFI existe, el servidor incluye el contenido del archivo /etc/passwd y te lo muestra en la página web.

Exploración Adicional de vulnerabilidades

Una vez confirmado el LFI, explora otros archivos sensibles del sistema. Algunos ejemplos incluyen:

Nombre del servidor de bWAPP:

http://<tu_ip>/bWAPP/rlfi.php?language=../../../../etc/hostname&action=go

Configuración principal de Apache.:

http://<tu_ip>/bWAPP/rlfi.php?language=../../../../etc/apache2/apache2.conf&action=go

7. Server side request forgery – port scan

Server-Side Request Forgery (SSRF) es una vulnerabilidad en la que un atacante puede manipular a un servidor vulnerable para que realice solicitudes en su nombre a otros recursos, tanto internos como externos. Este comportamiento es particularmente peligroso cuando se utiliza para realizar un escaneo de puertos en la red interna. En el siguiente ejercicio combinaremos elementos de Server-Side Request Forgery (SSRF) y Remote/Local File Inclusion (RFI/LFI), para realizar un escaneo de puertos en la red interna, y utilizar la lección de RFI/LFI como vector para esta explotación.

Escaneo de puertos

Selecciona la vulnerabilidad Server-Side Request Forgery (SSRF) para la actividad guiada y haz clic en «Hack».
Al iniciar la lección de SSRF, serás redirigido a una página que te permite realizar un escaneo de puertos en un servidor.

En la ventana de escaneo de puertos, ingresa una URL interna, como http://localhost/evil/ssrf-1.txt, para ver si el servidor puede acceder a recursos internos.

Manipulación de la lección de RFI/LFI

En una nueva pestaña del navegador, abre la lección de Remote & Local File Inclusion (RFI/LFI) en bWAPP. La URL será: http://localhost/bWAPP/rlfi.php
Haz clic en «Go» para ejecutar la funcionalidad por defecto.

Explotación de SSRF mediante modificación de URL

En la URL resultante (http://localhost/bWAPP/rlfi.php?language=lang_en.php&action=go), elimina el valor de lang_en.php y reemplázalo por: http://localhost/evil/ssrf-1.txt

💡 Despues de la modificación deberias tener una URL asi:

http://localhost/bWAPP/rlfi.php?language=http://localhost/evil/ssrf-1.txt&action=go

Presiona Enter para ejecutar la solicitud con la URL modificada.
Revisa los resultados. Si la explotación fue exitosa, verás los resultados del escaneo de puertos o cualquier otro recurso interno en la pantalla.

Observa cómo el servidor ha sido manipulado para hacer solicitudes a sí mismo o a otros servicios internos, lo que permite obtener información sobre la infraestructura. Esto te permite comprender cómo un servidor mal configurado puede ser utilizado como intermediario para acceder a recursos internos y comprometer la seguridad de una organización.

8. Insecure Design – Login Page

Este ejercicio simula un diseño inseguro utilizando la vulnerabilidad de Broken Authentication en bWAPP para demostrar cómo un sistema sin controles de seguridad adecuados puede ser comprometido. Aunque la vulnerabilidad Insecure Design no está listada explícitamente en bWAPP, se puede replicar con esta vulnerabilidad para ilustrar cómo la falta de seguridad en el diseño puede llevar a problemas críticos.

Selecciona la vulnerabilidad Broken Authentication – Insecure login forms para la actividad guiada y haz clic en «Hack». Serás redirigido a una página de inicio de sesión sin medidas de seguridad adecuadas.
Inspecciona los elementos de la página utilizando las herramientas de desarrollador del navegador. Abre el inspector de elementos de tu navegador y localiza los campos de entrada. (input) del formulario de autenticación.
Cambia el color del campo de entrada de las credenciales a negro para poder visualizar los datos de autenticación ocultos.

Al modificar el color del input, podrás ver que las credenciales del usuario tonystark con la contraseña «I am Iron Man» están visibles.

Explotemos del diseño inseguro. Intenta iniciar sesión con esas credenciales. Deberías poder acceder al sistema sin restricciones, lo que muestra la falta de medidas de seguridad como el cifrado de datos sensibles y mecanismos de autenticación robustos.

Con este paso a paso hemos aprendido a identificar y explotar una vulnerabilidad relacionada con Insecure Design a través de un diseño débil en la autenticación de usuarios. Esta vulnerabilidad destaca la importancia de considerar la seguridad desde la fase de diseño, ya que un mal diseño no puede ser corregido simplemente con la implementación de parches.

9. Fallos de criptografía – Hashing Débil de Contraseñas

Una implementación débil de hashing de contraseñas representa una vulnerabilidad critica de fallos criptográficos, ya que, en lugar de almacenar las contraseñas en texto plano, estas deben ser hasheadas (convertidas a un valor no reversible mediante un algoritmo criptográfico) antes de ser almacenadas en una base de datos. Sin embargo, si se utilizan algoritmos de hash débiles o inadecuados, como MD5 o SHA-1 (que ya no son seguros), los atacantes pueden crackearlos fácilmente usando técnicas como ataques de diccionario o fuerza bruta.

A través de este ejercicio identificaremos la vulnerabilidad con SQL Injection para obtener hashes de contraseñas desde la base de datos y explotaremos la vulnerabilidad de fallas criptográficas crackeando los hashes a través de la utilización de herramientas como John the Ripper. Posteriormente iniciaremos sesión con las contraseñas obtenidas para demostrar la vulnerabilidad.

Obtención de hashes de contraseñas

Selecciona la vulnerabilidad SQL Injection (GET/Search) y «Hack».
Tal como lo hicimos en el ejercicio de sql injection explora el formulario vulnerable. Verás un formulario con un campo para ingresar una búsqueda (generalmente llamado title o id).
Apoyandonos en lo aprendido en el ejercicio sql injection introduce un payload para obtener el nombre del usuario actual:

http://<tu_ip>/bWAPP/sqli_1.php?title=test' UNION SELECT 1, 2, user(), 4, 5, 6, 7-- &action=search

Si obtienes como resultado el nombre de usuario, la aplicación es vulnerable.

Extraer hashes de contraseñas. Usa una inyección SQL avanzada para extraer los datos sensibles (nombres de usuario, contraseñas) como lo hicimos en sql injection

💡 Pista: Los nombres de los usuarios estan guardados en la columna login toma esto en cuenta para cuando quieras obtener el nombre de usuario.

Crackear los hashes

Crea un archivo llamado hash.txt con el siguiente formato (ajusta el formato según el hash que hayas obtenido):

aim:6885858486f31043e5839c735d99457f045affd0
bee:6885858486f31043e5839c735d99457f045affd0
geeks:fdddbbaa4a5451f116b1dd3dd1289a04e50e968bc

Utiliza John the Ripper para crackear el hash. Ejecuta el siguiente comando en tu terminal, posicionado en la carpeta donde creaste el archivo:

john --format=raw-sha1 hash.txt

💡 Puedes instalar John the Ripper en la maquina de beebox pero puede llegar a tener algunas complicaciones y vas perder mucho tiempo en su instalación, por el contrario podrias usar kali linux para hacer el crakeo ya que tiene la herramienta John the Ripper instalada por defecto, elige tu camino sabiamente.

Revisa los resultados. Si John el Ripper crackea el hash correctamente, verás algo como:

Inicia sesión a bWAPP con la contraseña crackeada

Ve al formulario de inicio de sesión en bWAPP.
Ingresa el nombre de usuario y la contraseña crackeada (por ejemplo, bee y 123).
Verifica si puedes acceder a la cuenta del usuario con las credenciales obtenidas.

⚠ Mitigar los problemas relacionados con Weak Password Hashing es crucial porque un atacante que logre acceder a la base de datos de contraseñas podría obtener el control total de las cuentas de los usuarios.

10. Security Logging and Monitoring Failures

Security Logging and Monitoring Failures se refiere a la falta de un adecuado registro y monitoreo de eventos críticos en una aplicación. Cuando una aplicación no registra actividades importantes, como intentos de ataque, o no monitorea estos registros de manera efectiva, los atacantes pueden pasar desapercibidos. Esto aumenta el riesgo de que un ataque comprometa la seguridad sin ser detectado.

Dado que ya hemos trabajado con la vulnerabilidad SQL Injection (GET/Search), aprovecharemos esto para verificar si la aplicación registra los intentos de inyección SQL. La idea es realizar una inyección SQL y luego investigar si la aplicación registra esos intentos o si carece de un sistema de monitoreo adecuado.

Verificación de Intentos de SQL Injection en bWAPP

Selecciona la vulnerabilidad SQL Injection (GET/Search) y «Hack».
Realiza un Intento de Inyección SQL. En el campo de búsqueda, introduce el siguiente payload de SQL Injection para probar si la aplicación es vulnerable:

' OR 1=1 #

Haz click en el botón de Search. Si la aplicación muestra un resultado diferente o toda la tabla, significa que es vulnerable a la inyección SQL.

Revisar si la aplicación registra el intento de inyección SQL

Una vez realizada la inyección, debes verificar si la aplicación registra este intento en algún archivo de log o si hay un sistema de monitoreo configurado para detectar esta actividad.

Comprueba archivos de Log en el servidor (si son accesibles). En muchos sistemas Linux, los logs del servidor Apache se encuentran en:

/var/log/apache2/access.log

/var/log/apache2/error.log

Abre estos archivos y busca entradas relacionadas con tu intento de inyección SQL. Si encuentras la entrada con el intento de inyección SQL, el sistema está registrando, pero quizás no esté generando alertas.

⚠ Si encuentras registros sin alertas en el sistema, esto indica que, aunque el servidor está registrando las actividades, no está tomando ninguna acción proactiva o preventiva en respuesta a posibles ataques. Este es un problema importante en la categoría de Security Logging and Monitoring Failures, ya que afecta directamente la capacidad de la organización para detectar y responder a amenazas en tiempo real.

11. Vulnerable and outdated components

El propósito de este ejercicio es demostrar cómo los componentes desactualizados y vulnerables pueden ser explotados para realizar ataques como Cross-Site Scripting (XSS) Persistente. El uso de versiones antiguas o sin parches de bibliotecas de software, como una versión desactualizada de jQuery o un sistema de manejo de entradas mal implementado, facilita el abuso de vulnerabilidades ya conocidas.

En este ejercicio, utilizaremos el módulo Stored Blog de bWAPP para simular cómo un componente vulnerable permite la inyección y ejecución de código malicioso, demostrando así el impacto que puede tener el no mantener los componentes del software actualizados.

Instrucciones

Selecciona la vulnerabilidad Cross Site Scripting Stored (Blog) y «Hack». Serás redirigido a una página con un campo donde los usuarios pueden dejar comentarios.
Escribe el siguiente código JavaScript para simular un ataque de XSS:

Haz click en Publicar para guardar el comentario.
Luego de publicar el comentario, vuelve a la página del blog. Al recargar la página, verás que el script malicioso se ejecuta automáticamente, mostrando una alerta con el mensaje «XSS Persistente en Stored Blog». Este comportamiento ocurre porque el comentario no ha sido validado ni escapado correctamente antes de ser almacenado y visualizado, exponiendo la vulnerabilidad.

Para evaluar la extensión del ataque, crea dos o tres nuevos usuarios en bWAPP. Por ejemplo, crea usuarios llamados user, user1, y user2.

Cada uno de estos usuarios puede publicar su propio comentario malicioso usando un código similar al siguiente:

<script>alert('XSS de user')</script> hola, dejé un script de JS

Estos comentarios maliciosos quedarán almacenados en la base de datos y se ejecutarán cada vez que se acceda a la página del blog.

Verificación como usuario administrador. Inicia sesión nuevamente como el administrador bee.
Vuelve a la página del blog y revisa los comentarios publicados por los usuarios user, user1, y user2. Notarás que cada vez que el administrador visualiza los comentarios, el código JavaScript inyectado se ejecuta, mostrando las alertas correspondientes a cada comentario.

12. Conclusión

Las vulnerabilidades descritas en este documento ilustran los riesgos a los que se enfrentan las aplicaciones web modernas si no se prioriza la seguridad en todas las etapas de su ciclo de vida. La explotación exitosa de fallos como SQL Injection, XSS o Server-Side Request Forgery (SSRF) en bWAPP demuestra cómo un atacante podría comprometer datos sensibles, suplantar identidades o tomar control de sistemas.

Es crucial adoptar un enfoque proactivo: validar y sanitizar entradas, implementar controles de acceso estrictos, actualizar componentes y monitorear registros de actividad. Además, herramientas como bWAPP son invaluables para entrenar equipos en entornos seguros, fomentando prácticas de codificación segura y respuesta ante incidentes.

La ciberseguridad no es un destino, sino un proceso continuo. Este documento refuerza la necesidad de integrar estándares como el OWASP Top 10 en el desarrollo, auditorías y mantenimiento de aplicaciones, asegurando así la protección de usuarios y recursos en un panorama digital cada vez más complejo. La educación y la práctica constante siguen siendo las mejores defensas contra las amenazas emergentes.