Vea cómo es un informe de Agentic Deep Scan web
Una evaluación de 227 páginas de VulnBank, una aplicación bancaria deliberadamente vulnerable, y de su API. Muestra cómo cada hallazgo se prueba con peticiones reproducibles, se puntúa y se vincula a su causa raíz.
- Objetivo
- Aplicación web y API de VulnBank
- Escaneo
- Web Agentic Deep Scan
- Extensión
- 227 páginas
- Resultado
- Riesgo global: crítico
Realizado sobre un objetivo de demostración deliberadamente vulnerable. Sin datos de clientes.
Qué incluye
Resumen ejecutivo
El riesgo global, las principales rutas de ataque y qué corregir primero, al principio del informe.
Tabla de hallazgos
Cada hallazgo con su riesgo, puntuación CVSS, estado y una breve descripción.
Exploits probados
Análisis detallados de los principales problemas críticos y altos, con evidencias e impacto en el negocio.
Cómo corregir
La causa raíz de cada hallazgo y cómo corregirlo, con pasos de reproducción que puede repetir.
Hallazgo comentado
Un hallazgo, paso a paso
Cómo el informe lleva un hallazgo desde el objetivo probado hasta la corrección. Cada paso remite a su página en el informe completo.
- Objetivo
vulnbank.org, un banco de demostración en línea
Una aplicación de banca en línea y su API, deliberadamente vulnerables y creadas para formación en seguridad, probadas en vivo. El informe recoge sus funciones y la tecnología observada.
Página 2 del informe - Alcance
Un dominio y todos los endpoints encontrados
Inicio de sesión, transferencias, préstamos, tarjetas, subidas de archivos, el panel de administración y la API del agente de IA, probados del 14 de diciembre de 2025 al 16 de marzo de 2026 sin credenciales de prueba. Los subdominios quedaron fuera del alcance.
Página 2 del informe - Método
Cada hallazgo llega con su prueba
Los agentes exploran la aplicación e intentan cada ataque. Los hallazgos confirmados incluyen las peticiones que los reproducen e intentos de validación; las pistas que no se pudieron confirmar se marcan como potenciales.
Página 7 del informe - Flujo
Inicio de sesión y control de acceso
El hallazgo está en la capa de inicio de sesión y autorización que protege cada petición, incluidas las funciones de administración.
Página 48 del informe - Hallazgo
Crítico (CVSS 9.8): tokens de acceso sin verificar
El servidor aceptaba tokens de acceso sin comprobar que fueran auténticos, así que el panel y las acciones de administración eran accesibles sin cuenta.
Página 48 del informe - Evidencia
Las peticiones y respuestas que lo prueban
El informe muestra las peticiones y respuestas del escaneo, abreviadas: una petición sin un token válido se rechaza, luego se elude la comprobación y una acción de administración se completa.
Página 49 del informe - Corrección
Verificar cada token y comprobar los roles en el servidor
El informe atribuye el fallo a tokens decodificados sin comprobar su firma y a una autorización que confía en el valor is_admin del token. La corrección: verificar cada firma y cargar el rol del usuario en el servidor.
Página 58 del informe - Estado
Puntuado, clasificado y con seguimiento
La tabla de hallazgos muestra cada problema con su riesgo, puntuación CVSS, estado y una breve descripción.
Página 20 del informe
Cómo decidió el agente
Por qué cuenta como un riesgo
Un escáner informa de todo lo que coincide con una regla. Antes de informar, el agente comprueba que una pista lleva a un daño real y descarta las explicaciones inofensivas. Así razonó sobre un hallazgo en vulnbank.org.
Paso 1
¿Por qué la página de saldo responde sin iniciar sesión?
GET /check_balance/<número de cuenta> devolvió 200 con el nombre de usuario y el saldo de otro cliente, sin token ni cookie.
Página 23 del informePaso 2
¿Podría ser una copia en caché?
El agente repitió la petición con cabeceras no-cache y un nonce único. La respuesta indicaba cf-cache-status: DYNAMIC: venía del servidor, no de una caché.
Página 24 del informePaso 3
¿El endpoint es simplemente permisivo con los tokens?
Una petición con un token inventado, Bearer invalid, recibió el mismo 200 y los mismos datos. El endpoint no comprueba el token en absoluto.
Página 24 del informePaso 4
¿Son datos reales o una demo estática?
Con la sesión de un usuario, el agente hizo una transferencia de 12,34 y luego leyó las transacciones de ese usuario sin iniciar sesión. La nueva transacción estaba ahí.
Página 25 del informePaso 5
¿Por qué ocurre?
POST /transfer rechaza una petición sin token con 401, así que la autenticación existe, pero no se aplica a estas dos lecturas. La especificación de la API las declara sin seguridad.
Página 26 del informePaso 6
Entonces, ¿es un riesgo?
Sí, crítico. Cualquiera en internet puede leer saldos e historiales de transacciones, y usar las respuestas 200 o 404 para encontrar números de cuenta válidos.
Página 27 del informePaso 7
¿Cómo se corrige?
Exigir un token válido en ambos endpoints y devolver 401 si falta. Después, comprobar que la cuenta pertenece a quien la pide y devolver 403 si no.
Página 27 del informe
¿Quiere este informe para su propia aplicación?
Reserve una demo y le mostraremos un escaneo de su aplicación móvil, su aplicación web o su API.