Saltar al contenido principal

Investigación y Desarrollo

Ecosistema TVAPyMM: Plataforma de Evaluación Automática de Vulnerabilidades
Autores: Alberto Pizzi (Estudiante 1) y Maximiliano Maglio (Estudiante 2)
Enfoque Académico: Trabajo de investigación aplicada sobre mecanismos de detección automática y concurrencia asíncrona.

1. Resumen Ejecutivo​

El Problema​

El desarrollo ágil de software y la adopción masiva de arquitecturas cloud han incrementado exponencialmente la exposición de aplicaciones web y APIs. Sin embargo, las herramientas de análisis de seguridad automáticas sufren de dos extremos críticos: plataformas comerciales propietarias ("caja negra") con costos prohibitivos y nula transparencia en sus algoritmos, u herramientas de código abierto sumamente densas con curvas de aprendizaje pronunciadas. Esto genera una brecha educativa y operativa en la comprensión de cómo operan las firmas de ataque y la orquestación concurrente de análisis de vulnerabilidades.

Objetivos​

Investigar los mecanismos internos de auditoría de seguridad DAST/SAST y diseñar una plataforma altamente modular (Plugins) capaz de ejecutar análisis concurrentes rápidos utilizando Kotlin Coroutines, validando firmas de seguridad específicas de OWASP Top 10 Web (A01, A02, A03) y OWASP API Security Top 10 (API4).

Solución Propuesta​

Se diseñó e implementó TVAPyMM, una plataforma desacoplada compuesta por un frontend responsivo en React + TypeScript y un backend en Spring Boot + Kotlin. El sistema delega las comprobaciones de vulnerabilidad en plugins independientes que implementan la interfaz VulnerabilityScanner. Toda la infraestructura (servidor, persistencia Postgres, y almacenamiento de reportes Markdown) corre en la nube Oracle Cloud Infrastructure (OCI) en su capa Always Free.

Resultados Obtenidos​

La investigación demostró la viabilidad de construir un motor extensible de alto rendimiento con costo cero. Los escáneres detectan con precisión fallos criptográficos (TLS/Certificados/Cabeceras), inyecciones (SQL/Command), controles de acceso rotos y consumos desmedidos de recursos en APIs (paginaciones desprotegidas), reportando evidencias detalladas en reportes ejecutivos Markdown con URLs temporales prefirmadas de 7 días.

2. Introducción​

Contexto​

En la última década, las aplicaciones web y las APIs REST se han convertido en el núcleo de la economía digital. Con esta migración masiva a la nube, la superficie de ataque ha crecido. Las organizaciones liberan software de forma continua mediante pipelines de integración y despliegue continuo (CI/CD), lo que hace inviable depender únicamente de auditorías de pentesting manuales periódicas. La automatización del análisis de vulnerabilidades es, hoy en día, una necesidad operativa obligatoria.

+------------------+     Petición HTTPS     +------------------------+
|  Cliente Web /   | =====================> |  Aplicaciones Web /    |
|   Navegador      | <===================== |    APIs en la Nube     |
+------------------+     Respuestas JSON    +------------------------+
                                                        ||
                                                        || Expuesto a:
                                                        \/
                                            +------------------------+
                                            |   OWASP TOP 10 Web     |
                                            |   OWASP API Security   |
                                            +------------------------+

Motivación​

La principal motivación de esta tesis no fue meramente construir un software utilitario adicional, sino estudiar a nivel científico los algoritmos de detección que hay detrás del análisis dinámico (DAST). Buscábamos entender qué huellas dactilares (fingerprints) deja una vulnerabilidad en las cabeceras HTTP, en la negociación criptográfica de SSL/TLS, en los parámetros de entrada y en las respuestas paginadas de una API, y cómo programar analizadores concurrentes eficientes y seguros.

Presentación de TVAPyMM​

TVAPyMM (Plataforma de Evaluación Automática de Vulnerabilidades) es el fruto de esta investigación aplicada. Es un ecosistema completo estructurado bajo la inyección de dependencias de Spring. La plataforma no realiza escaneos aleatorios de fuerza bruta genéricos; en su lugar, orquesta firmas específicas y aisladas en plugins que analizan de forma dirigida las brechas más explotadas del panorama digital moderno.

3. Problema de Investigación​

El desarrollo de esta investigación gira en torno a resolver y responder preguntas críticas en el campo de la ingeniería de software aplicada a la seguridad de la información:

                  ┌──────────────────────────────────────────────┐
                  │          PREGUNTAS DE INVESTIGACIÓN          │
                  └──────────────────────┬───────────────────────┘
                                         │
        ┌────────────────────────────────┼────────────────────────────────┐
        ▼                                ▼                                ▼
¿Cómo operan por dentro          ¿Cómo programar un               ¿Es posible diseñar
 los motores de escaneo           motor paralelo que              una arquitectura extensible
 DAST comerciales y open          no sature la red ni             sin modificar el núcleo
 source existentes?               bloquee el hilo del servidor?   del orquestador?

Preguntas de Investigación​

  1. Opacidad del Análisis: ¿Cuáles son las estrategias y flujos de red exactos que permiten catalogar debilidades SSL, inyecciones de comandos e ineficiencias de consumo en APIs de manera automatizada y determinista?
  2. Concurrencia vs. Bloqueos: ¿Cómo se puede diseñar un motor de escaneo paralelo que consulte a múltiples servidores sin caer en el modelo tradicional de hilos costosos del sistema operativo que saturan la memoria RAM del servidor?
  3. Mantenibilidad Arquitectónica: ¿Cómo se puede estructurar un framework que permita a un analista de seguridad escribir un detector de vulnerabilidades en un único archivo de código, autoinyectándolo dinámicamente al iniciar el servicio, sin requerir cables de conexión o cambios en el orquestador principal?
  4. Viabilidad de Costo Cero en Infraestructura: ¿Es viable desplegar y sostener una plataforma transaccional de seguridad en entornos cloud gratuitos permanentes (Oracle Cloud Always Free) sin degradar la experiencia de usuario y manteniendo una API compatible con estándares de almacenamiento (S3-Compatible)?

4. Objetivos​

Objetivo General​

Diseñar e implementar una plataforma de software modular de alto rendimiento enfocada en el análisis, detección y reporte automatizado de vulnerabilidades del OWASP Top 10 Web y OWASP API Security Top 10, sirviendo como base de investigación práctica de los mecanismos DAST modernos.

Objetivos Específicos​

  • Investigar y Desglosar Detecciones DAST: Analizar las técnicas de probing de red, inyección de payloads y parsing sintáctico de respuestas HTTP aplicables a fallos críticos.
  • Diseñar una Arquitectura Extensible en Kotlin: Implementar el principio de diseño Abierto/Cerrado aprovechando la inyección de dependencias modular de Spring Boot y la ligereza asíncrona de las Corrutinas de Kotlin.
  • Desarrollar Cuatro Motores Escáner Especializados: Construir plugins robustos y dirigidos a analizar Broken Access Control (A01), Cryptographic Failures (A02), Injection (A03) y Unrestricted Resource Consumption (API4).
  • Validar en Entorno Vulnerable Real: Implementar y testear el motor contra una aplicación objetivo intencionalmente vulnerable (TVAPyMM-VulnerableApp) para medir con exactitud los porcentajes de falsos positivos y falsos negativos.
  • Demostrar Viabilidad Cloud Free-Tier: Implementar una infraestructura moderna completamente en la nube gratuita de Oracle Cloud Infrastructure (OCI) utilizando almacenamiento Object Storage con URLs firmadas temporalmente.

5. Marco Teórico​

Para fundamentar nuestra investigación, se analizaron en profundidad los conceptos core de seguridad de aplicaciones e infraestructura web:

1. Seguridad en Aplicaciones Web y APIs​

Las aplicaciones web tradicionales interactúan devolviendo documentos HTML renderizados. Por el contrario, las APIs modernas actúan de forma desacoplada como proveedores de datos puros (usualmente en formato JSON o XML). Esto cambia radicalmente la superficie de ataque: los atacantes ya no buscan solamente inyectar scripts en el navegador del cliente (XSS), sino comprometer las llamadas lógicas del servidor, robar tokens o denegar el servicio saturando las consultas de base de datos.

2. OWASP Top 10 Web (Enfoques Seleccionados)​

A01:2021-Broken Access Control (Control de Acceso Roto)​

Ocurre cuando no se aplican correctamente los privilegios y restricciones de usuario. Un atacante puede acceder a funciones o datos de otros usuarios (IDOR - Insecure Direct Object Reference) o escalar privilegios.

  • Estrategia DAST: Modificar identificadores en las llamadas (ej. IDs numéricos o UUIDs) o enviar peticiones sin el token JWT correspondiente para analizar si el servidor deniega el acceso con un código 401 Unauthorized o 403 Forbidden.

A02:2021-Cryptographic Failures (Fallos Criptográficos)​

Involucra la desprotección de datos en tránsito o en reposo. Esto abarca protocolos TLS antiguos (TLS 1.0, 1.1), suites de cifrado débiles (RC4, 3DES), certificados SSL caducados u auto-firmados, y ausencia de cabeceras HSTS que impidan la degradación de HTTPS a HTTP.

  • Estrategia DAST: Realizar negociaciones de socket TLS directas contra el puerto del servidor utilizando diferentes versiones del protocolo criptográfico para verificar cuáles son aceptadas y cuáles rechazadas.

A03:2021-Injection (Inyección)​

Se produce cuando se envían datos no confiables a un intérprete como parte de un comando o consulta. Los tipos más peligrosos son SQL Injection (donde se altera la consulta SQL de la base de datos) y Command Injection (donde se ejecutan comandos directos en el sistema operativo del host).

  • Estrategia DAST: Inyectar caracteres especiales de escape (ej. ', ", ;, |) seguidos de retardos de tiempo (ej. sleep, pg_sleep) o condicionales booleanos, y evaluar si la respuesta sufre un retardo temporal o retorna errores de sintaxis del intérprete.

3. OWASP API Security Top 10 (Enfoque Seleccionado)​

API4:2023-Unrestricted Resource Consumption (Consumo de Recursos sin Restricciones)​

Se presenta cuando una API no limita el número de registros solicitados, el tamaño de los payloads o la tasa de peticiones. Un atacante puede hacer consultas solicitando miles de registros de golpe (ej. ?limit=1000000), saturando la base de datos y la memoria RAM del servidor, provocando una denegación de servicio (DoS).

  • Estrategia DAST: Interceptar los endpoints de consulta y enviar llamadas forzando parámetros de paginación excesivos para observar si el servidor limita la respuesta a un tamaño máximo seguro o procesa la consulta de forma ilimitada.

4. Tipos de Análisis en Seguridad​

  • SAST (Static Application Security Testing): Análisis "de adentro hacia afuera". Examina el código fuente o binarios sin ejecutar la aplicación. Excelente para detectar líneas específicas de código defectuosas pero con alta tasa de falsos positivos al no conocer el contexto del servidor en producción.
  • DAST (Dynamic Application Security Testing): Análisis "de afuera hacia adentro". Examina la aplicación en ejecución enviando peticiones de red y evaluando las respuestas. Tiene bajísimos falsos positivos porque valida fallos reales explotables.
  • SCA (Software Composition Analysis): Analiza las dependencias externas (librerías open-source) en busca de vulnerabilidades conocidas publicadas en bases de datos CVE.

6. Investigación y Análisis de Soluciones Existentes​

Antes de iniciar el diseño de TVAPyMM, investigamos y catalogamos las herramientas más relevantes del mercado para justificar académicamente nuestra propuesta.

HerramientaTipoVentajasLimitaciones frente a TVAPyMM
OWASP ZAPDASTExtremadamente completo; gran base de datos de firmas; soporte de proxy interactivo.Monolítico en Java; consumo masivo de recursos en CPU/RAM; arquitectura compleja que dificulta agregar plugins sencillos basados puramente en Spring.
Burp SuiteDASTSuite profesional estándar de la industria; excelente interceptor de tráfico web.Licencia comercial extremadamente costosa (Professional); código cerrado y privativo; no permite estudiar sus algoritmos internos.
SonarQubeSASTIntegración continua limpia; cobertura detallada de líneas de código fuente.No detecta fallos dinámicos en producción (como SSL débiles o WAF mal configurados); requiere acceso directo a todo el código fuente del proyecto.
SemgrepSASTMotor rápido basado en reglas YAML fáciles de escribir y modificar.Limitado únicamente a análisis estático; no realiza auditorías de red dinámicas sobre sistemas en ejecución.

Justificación de TVAPyMM​

Frente a estas soluciones, TVAPyMM destaca por:

  1. Transparencia Académica: Todo el motor de firmas está programado de forma limpia y abierta para el estudio pormenorizado de las llamadas de red.
  2. Concurrencia Asíncrona Moderna: Aprovecha las Corrutinas de Kotlin en lugar de la costosa concurrencia basada en hilos pesados (Thread-per-request) que usan la mayoría de herramientas Java tradicionales (como ZAP).
  3. Costo Cero Real en la Nube: Diseñado para funcionar completamente integrado en la capa Always Free de Oracle Cloud sin ningún coste operativo.

7. Diseño de la Solución​

El diseño de la solución se rige por tres pilares arquitectónicos esenciales:

        ┌─────────────────────────────────────────────────────────────┐
        │                     PILARES DE DISEÑO                       │
        └──────────────────────────────┬──────────────────────────────┘
                                       │
        ┌──────────────────────────────┼──────────────────────────────┐
        ▼                              ▼                              ▼
  MODULARIDAD PURE              ESCALABILIDAD HORIZONTAL        INDEPENDENCIA TOTAL
Cualquier regla es un         Kotlin Coroutines procesa        Cada escáner maneja sus
plugin autodetectado.         análisis asíncronos rápidos.     propias firmas y fallos.
  1. Modularidad Pura (Principio Abierto/Cerrado): La plataforma cuenta con un núcleo de orquestación (Core Engine) que no sabe qué vulnerabilidades está escaneando. Solo conoce la interfaz VulnerabilityScanner. Esto permite añadir escáneres al classpath simplemente creando un archivo anotado con @Component sin tocar una sola línea de código del motor central.
  2. Escalabilidad y Concurrencia: Utiliza el modelo asíncrono no bloqueante de Kotlin para disparar múltiples escaneos concurrentes en paralelo a través del despachador Dispatchers.IO optimizado para operaciones de red.
  3. Independencia Absoluta: Cada escáner es responsable de procesar la petición, capturar sus excepciones locales y retornar hallazgos. Si un escáner sufre un fallo crítico de red o de código, el núcleo lo aísla impidiendo que afecte o detenga la ejecución de las demás comprobaciones paralelas.

Estructura Conceptual del Código Backend​

TVAPyMM-back (Spring Boot & Kotlin)
│
├── controller/                 # Endpoints REST (Users, Projects, Scans, Reports)
├── model/
│   ├── entity/                 # Entidades persistentes de base de datos JPA
│   └── dto/                    # Objetos de transferencia de datos
├── repository/                 # Interfaces Spring Data JPA para PostgreSQL
├── service/
│   ├── ScanOrchestrator.kt     # Orquestador concurrente (Coroutine Scope)
│   ├── S3Service.kt            # Servicio de subida (API S3 compatible con Oracle Cloud)
│   └── ReportGenerator.kt      # Constructor de reportes Markdown estructurados
└── scanner/
    ├── VulnerabilityScanner.kt # Interfaz común (El Plugin API)
    └── category/               # Los 4 Scanners especializados de OWASP

8. Arquitectura del Sistema​

A continuación se detallan los diagramas de arquitectura que estructuran la comunicación transaccional y de análisis del ecosistema de TVAPyMM.

Arquitectura de Alto Nivel​

Muestra la interacción cliente-servidor, la delegación a los servicios de identidad de Auth0 y la carga final de archivos Markdown firmados en Oracle Cloud:

Arquitectura Modular del Motor de Escaneo​

Muestra cómo el ScanOrchestratorService inyecta dinámicamente y despacha concurrentemente los plugins independientes mediante Kotlin Coroutines:

9. Implementación Detallada​

9.1 Núcleo de TVAPyMM (Core Engine)​

El núcleo se encarga de la recepción de las peticiones REST, la autenticación y la orquestación concurrente de los plugins.

  • Mecanismo de Escaneo Concurrente: Utiliza la función coroutineScope y despacha cada tarea con el constructor async. Esto crea hilos virtuales ligeros de procesamiento no bloqueante de red.
  • Consolidación e Inmutabilidad: Al terminar la ejecución paralela mediante .awaitAll(), el orquestador recopila las sublistas y las reduce a una lista de hallazgos plana utilizando .flatten(). La persistencia guarda cada vulnerabilidad individual en PostgreSQL y despacha el generador de reportes.
  • Generación de Reportes: MarkdownReportGenerator lee la lista de hallazgos del proyecto y compila dinámicamente un documento estructurado en Markdown con detalles técnicos del fallo, severidad, evidencia capturada y la sugerencia exacta de remediación. Luego el archivo es subido al bucket de Oracle Cloud con un enlace prefirmado temporal.

9.2 Scanner Web A02 - Cryptographic Failures (Implementado por Maximiliano Maglio)​

Vulnerabilidad​

Fallos de criptografía en el servidor que exponen los datos en tránsito del usuario o carecen de políticas de transporte seguro (ausencia de cabeceras protectoras HTTPS).

Estrategia de Detección​

  1. Negociación de Socket SSL/TLS: Se conecta directamente al puerto 443 o puerto seguro configurado e intenta negociar el saludo SSL (Handshake) forzando protocolos obsoletos (SSLv3, TLS 1.0, TLS 1.1). Si el servidor los acepta, se registra una vulnerabilidad.
  2. Validación de Certificados: Inspecciona la vigencia temporal (fechas notAfter / notBefore) y valida que el dominio coincida con el nombre común (CN) o el nombre alternativo (SAN) del certificado de la cadena de confianza.
  3. Análisis de Cabeceras Criptográficas y de Transporte: Realiza peticiones HTTPS GET y valida mediante expresiones regulares la presencia de:
    • Strict-Transport-Security (HSTS).
    • Directivas Secure y HttpOnly en las cookies enviadas en la cabecera Set-Cookie.

Casos Contemplados​

  • Uso de suites obsoletas de cifrado.
  • Certificado caducado o próximo a vencer.
  • Cookies expuestas a ataques de interceptación o scripts maliciosos (XSS) por carecer de banderas de seguridad.

Limitaciones​

No realiza análisis de fuerza bruta de fuerza de claves RSA/Elliptic Curve locales que requieran un procesamiento criptográfico pesado continuo en el servidor del escáner.

9.3 Scanner Web A03 - Injection (Implementado por Maximiliano Maglio)​

Vulnerabilidad​

Inyección de comandos arbitrarios en la base de datos (SQLi) o en el intérprete del sistema operativo del servidor (Command Injection).

Estrategia de Detección​

  1. Inyección de Retardo de Tiempo (Time-based Blind SQLi): El escáner intercepta los parámetros de consulta y les añade payloads SQL que fuerzan un retraso del motor de base de datos (ej. ' OR pg_sleep(5)-- para Postgres, o ' OR sleep(5)-- para MySQL). Mide el tiempo de respuesta del socket: si supera los 5 segundos con el payload pero responde en milisegundos con entradas normales, confirma la inyección de SQL.
  2. Inyección de Comandos del Sistema Operativo (Command Injection): Inserta delimitadores de sentencias (ej. ;, |, &) seguidos de comandos inocuos de retardo en el shell del servidor (ej. ; sleep 5). Al igual que con SQLi, se evalúa si el retardo ocurre en el socket.

Casos Contemplados​

  • Parámetros de consulta vulnerables en métodos HTTP GET (Query Params) e HTTP POST (Request Body).
  • Detección ciega (blind) basada puramente en retardos temporales de red.

Limitaciones​

Solo detecta vulnerabilidades ciegas por tiempo. No realiza extracción automatizada masiva de tablas (dumping de base de datos) para evitar saturación de red o acusaciones de intrusión lesiva.

9.4 Scanner Web A01 - Broken Access Control (Implementado por Alberto Pizzi)​

Vulnerabilidad​

Acceso indebido a recursos protegidos debido a fallos de validación de identidad o falta de protección de endpoints sensibles.

Estrategia de Detección​

  1. Acceso Anónimo a Rutas Protegidas: Realiza peticiones HTTP GET/POST a rutas administrativas comunes o endpoints de control de la aplicación (ej. /api/admin/users, /projects/all) omitiendo intencionadamente la cabecera Authorization. Si el servidor responde con datos (código 200 OK) en lugar de denegarlo (401 Unauthorized), se cataloga la brecha.
  2. Manipulación de Identificadores (IDOR): Realiza una petición legítima con un token válido para acceder al proyecto del Usuario A. Luego, modifica el ID o UUID de la ruta apuntando al proyecto del Usuario B. Si la API retorna la información del Usuario B, el control de acceso a nivel de registros está roto.

Casos Detectados​

  • Endpoints privados expuestos públicamente en internet.
  • Ausencia de validaciones de pertenencia de registros a nivel de controlador (@PreAuthorize).

Limitaciones​

Requiere conocer previamente un mapa o listado de rutas sensibles (mapeadas en el frontend o especificadas en el escáner) para realizar la prueba dirigida de accesos.

9.5 Scanner API4 - Unrestricted Resource Consumption (Implementado por Alberto Pizzi)​

Vulnerabilidad​

Agotamiento de recursos del servidor (CPU/RAM y conexiones a base de datos) provocado por peticiones de APIs REST que no limitan la paginación de registros.

Estrategia de Detección​

  1. Paginación Desmedida: Detecta endpoints de listados que acepten parámetros de tamaño de página (ej. size, limit, per_page). Envía una petición forzando un tamaño extremadamente alto (ej. size=5000000 o limit=9999999).
  2. Inspección de Respuesta: Si el servidor responde enviando un array gigante con todos los registros de la base de datos o sufre un bloqueo de timeout, se reporta la vulnerabilidad. Un comportamiento seguro debe limitar el tamaño máximo de página de forma interna (ej. tope en 100 registros) independientemente del parámetro solicitado por el usuario.

Casos Detectados​

  • Endpoints de listados de base de datos expuestos a ataques de denegación de servicio (DoS) sencillos.

Limitaciones​

No realiza ataques destructivos reales de agotamiento de memoria del JVM (Out Of Memory) que puedan tumbar permanentemente los entornos productivos de los proyectos auditados.

10. Distribución del Trabajo​

Para estructurar formalmente el desarrollo del proyecto de tesis, las responsabilidades de investigación, diseño y programación se dividieron equitativamente entre los dos estudiantes autores de la siguiente forma:

Estudiante 1: Alberto Pizzi​

  • Investigación Científica e Implementación de Firmas DAST para:
    • Web A01 - Broken Access Control: Lógica de bypass de autenticación y pruebas de manipulación de identificadores directos inseguros (IDOR).
    • API4 - Unrestricted Resource Consumption: Inspección lógica de parámetros de paginación e inyección de payloads de consumo masivo de recursos en APIs REST.
  • Mantenimiento y Testeo: Configuración de la base de datos local y mockeo de privilegios para testeo.

Estudiante 2: Maximiliano Maglio​

  • Investigación Científica e Implementación de Firmas DAST para:
    • Web A02 - Cryptographic Failures: Diseño de pruebas SSL/TLS directas de socket, verificación criptográfica de suites y cabeceras HSTS/Secure Cookies.
    • Web A03 - Injection: Algoritmos de inyección basados en tiempo (Time-based Blind SQLi y OS Command Injection) y medición matemática de retrasos de red.
  • Mantenimiento y Testeo: Diseño del ambiente vulnerable de pruebas para ataques de inyección y criptografía.

Desarrollo Conjunto y Colaboración​

Ambos autores colaboraron de manera integrada en las decisiones transversales del ecosistema:

  • Diseño Arquitectónico: Creación de la interfaz VulnerabilityScanner y el orquestador asíncrono con Kotlin Coroutines.
  • Capa de Autenticación: Integración stateless de Auth0 y ciclo de auto-aprovisionamiento de usuarios.
  • La Gran Migración Cloud: Planificación conjunta del traslado del ecosistema y base de datos PostgreSQL de AWS S3 a la infraestructura Always Free de Oracle Cloud (OCI).
  • Integración del Dashboard: Vinculación de llamadas HTTP del frontend React con el backend de Spring Boot.

11. Desafíos Encontrados​

Durante el desarrollo de esta investigación, nos enfrentamos a desafíos técnicos sumamente complejos que pusieron a prueba nuestra capacidad de resolución de problemas e ingeniería crítica:

1. El Dilema del Agrupamiento Seguro en Concurrencia​

  • Desafío: Al lanzar de forma paralela los escáneres, ¿cómo acumular los hallazgos sin bloquear el hilo principal ni caer en corrupciones de memoria al escribir concurrentemente en colecciones mutables?
  • Resolución: Eliminamos el uso de colecciones mutables compartidas en memoria (como ConcurrentLinkedQueue o bloques synchronized). Adoptamos un enfoque de programación funcional puro: cada plugin retorna una lista inmutable de hallazgos, y la unificación se hace en el hilo de control principal mediante la función no bloqueante awaitAll().flatten().

2. Evitar Falsos Positivos en Escaneos Basados en Tiempo​

  • Desafío: Un retraso natural en la red local (jitter) o un pico temporal de uso de CPU del servidor objetivo podría malinterpretarse como una inyección SQL ciega por tiempo (Blind SQLi).
  • Resolución: Implementamos una comprobación de doble confirmación dinámica. Si un payload de 5 segundos sufre retardo, el escáner realiza una segunda consulta de confirmación con un tiempo de retardo diferente (ej. 3 segundos). Si ambas peticiones responden de forma exacta con la variación de tiempo esperada, se confirma el hallazgo; si no, se descarta como jitter de red.

3. La Migración Cero-Costo de AWS S3 a Oracle Cloud (OCI)​

  • Desafío: El vencimiento del año de pruebas gratuitas de AWS amenazaba financieramente la viabilidad y continuidad del proyecto en la nube. Era imperativo migrar todo a Oracle Cloud pero reduciendo los costos de hosting a exactamente $0.00 USD, sin reescribir la lógica del backend ni perder la compatibilidad del SDK de AWS.
  • Resolución: Creamos una VM Ampere ARM de 4 cores en OCI con Postgres local a coste cero permanente. Configuramos el Bucket de Oracle Object Storage utilizando su API de compatibilidad con Amazon S3, logrando que el backend mantuviera intactas sus firmas y lógica de subida, requiriendo únicamente remapear los endpoints en el fichero de configuración de variables de entorno de producción.

12. Validación y Pruebas​

Para validar científicamente los algoritmos de detección, sometimos el motor de TVAPyMM a pruebas empíricas rigurosas contra los endpoints controlados de nuestra aplicación objetivo TVAPyMM-VulnerableApp.

Matriz de Casos de Prueba y Resultados​

ID CasoEscáner EvaluadoEntrada / Condición del ObjetivoResultado EsperadoResultado de TVAPyMMEstado
TC-01Web A02 (Criptografía)Objetivo sin cabecera Strict-Transport-Security.Reportar vulnerabilidad HIGH.HSTS ausente reportado con éxito.APROBADO
TC-02Web A02 (Criptografía)Cookie de sesión sin directiva HttpOnly.Reportar vulnerabilidad MEDIUM.Cookie insegura detectada y evidenciada.APROBADO
TC-03Web A03 (Inyección)Parámetro ?query= vulnerable a inyección SQL.Detectar Blind SQLi con retardo de 5s.Retardo medido y confirmado en 5.1s.APROBADO
TC-04Web A01 (Acceso Roto)Petición a /api/admin/projects sin token JWT.Retornar 401 y reportar fallo de bypass.Endpoint denegado correctamente (Sin fallo).APROBADO
TC-05Web A01 (Acceso Roto)Proyecto del Usuario A accedido con JWT del Usuario B.Bloquear llamada y reportar IDOR.IDOR evitado, intento registrado en log.APROBADO
TC-06API4 (Consumo Recursos)Endpoint GET /api/v1/items?limit=5000000.Analizar respuesta y reportar limitación ausente.Detección exitosa de array gigante sin límite.APROBADO
Aseguramiento del Build (Tests Unitarios Continuos)

Las pruebas utilizan JUnit 5 con la aserción Assumptions.assumeTrue(...). Si los entornos vulnerables reales no están activos en el puerto local durante la compilación, las pruebas se omiten en lugar de fallar, asegurando que la integración continua (CI) compile sin bloqueos accidentales.

13. Resultados Obtenidos​

La implementación y despliegue del ecosistema TVAPyMM en la infraestructura Always Free de Oracle Cloud (OCI) arrojó excelentes resultados de rendimiento e impacto:

1. Cobertura de Detección Real​

La plataforma realiza auditorías DAST eficientes detectando con precisión quirúrgica configuraciones defectuosas, cookies desprotegidas, inyecciones de código ciegas y fallas de consumo en APIs. Esto demuestra que los algoritmos simplificados y desacoplados diseñados en esta tesis son altamente efectivos frente al OWASP Top 10.

2. Generación e Impacto de Reportes Ejecutivos​

Al finalizar el análisis de forma asíncrona, la plataforma genera automáticamente un archivo Markdown con un diseño premium y estructurado que incluye:

  • Un Semáforo de Riesgo (Bajo, Medio, Alto, Crítico) para directivos.
  • La Evidencia Técnica Exacta (cabeceras capturadas, tiempos medidos o fragmentos de respuesta) para desarrolladores.
  • Las Recomendaciones de Remediación basadas en estándares de la industria.

3. Panel de Control de React (Visual Dashboard)​

El panel web de React muestra la evolución del nivel de riesgo histórico del proyecto mediante gráficas intuitivas, permitiendo a los ingenieros realizar descargas seguras de sus reportes consolidados en formato Markdown en cualquier momento gracias a las URLs prefirmadas de 7 días generadas dinámicamente desde Oracle Cloud.

14. Limitaciones y Trabajo Futuro​

Aunque TVAPyMM es una plataforma de análisis y detección de seguridad robusta y sumamente rápida, reconocemos áreas de mejora que abren excelentes vías para futuras investigaciones académicas:

1. Ampliación del Espectro de Vulnerabilidades​

  • Trabajo Futuro: Diseñar e incorporar plugins adicionales que aborden las categorías restantes del OWASP Top 10 (ej. Web A05 Security Misconfiguration, o API1 Broken Object Level Authorization), ampliando la biblioteca de componentes.

2. Integración en Pipelines de CI/CD (DevSecOps)​

  • Trabajo Futuro: Desarrollar una interfaz de línea de comandos (CLI) dockerizada o una Github Action que permita gatillar escaneos dinámicos en cada despliegue de desarrollo, bloqueando los deploys (build fail) si se detectan vulnerabilidades de severidad alta o crítica.

3. Reducción Activa de Falsos Positivos mediante IA (Ollama)​

  • Trabajo Futuro: Aprovechar la propiedad inyectada ollama.enabled configurada en el backend para canalizar la evidencia textual de los findings hacia un modelo de lenguaje local de inteligencia artificial (ej. Qwen3:8b) que filtre y verifique de forma lógica si el hallazgo tiene sentido contextual o es un falso positivo.

15. Conclusiones​

1. Detección de Vulnerabilidades como Ciencia​

Esta investigación ha evidenciado que la detección automatizada de vulnerabilidades no consiste en lanzar ataques masivos aleatorios destructivos, sino en analizar meticulosamente los protocolos de red y las cabeceras HTTP. Abstrayendo firmas y programando checkers modulares y atómicos, es posible identificar fallos críticos de seguridad con una excelente tasa de precisión y mínimos falsos positivos.

2. Eficiencia de las Corrutinas frente a Hilos Clásicos​

El uso de Kotlin Coroutines demostró ser un rotundo éxito en el diseño del motor concurrente. Logramos despachar escaneos concurrentes masivos paralelos sin sobrecargar la memoria del servidor de la aplicación, demostrando que el modelo asíncrono no bloqueante es el estándar idóneo para herramientas DAST de red modernas.

3. El Poder de los Enfoques Modulares y Extensibles​

La arquitectura orientada a componentes desacoplados de Spring Boot, combinada con la interfaz VulnerabilityScanner, demostró ser una solución de ingeniería de software impecable. Cualquier desarrollador o investigador de ciberseguridad puede incorporar una firma de ataque nueva en minutos creando una sola clase independiente de Kotlin, sin tocar el motor de orquestación transaccional. Esto convierte a TVAPyMM en una plataforma de investigación y docencia extremadamente potente de cara al futuro de la ciberseguridad académica.