Vea cómo es un informe de Agentic Deep Scan web
Una evaluación de 205 páginas de VulnBank, una aplicación bancaria deliberadamente vulnerable, y de su API. Muestra cómo cada hallazgo se prueba con peticiones reproducibles y se vincula a su causa raíz.
- Objetivo
- Aplicación web y API de VulnBank
- Escaneo
- Web Agentic Deep Scan
- Extensión
- 205 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 y cuántos hallazgos hay en cada nivel de gravedad, al principio del informe.
Tabla de hallazgos
Cada hallazgo con su riesgo, estado y una breve descripción.
Exploits probados
Cada hallazgo analizado en detalle, con las peticiones que lo explotan y las evidencias que devolvieron.
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 resumen ejecutivo empieza por su riesgo global: crítico.
Página 2 del informe - Resultados
57 hallazgos, ordenados por riesgo
42 vulnerabilidades confirmadas (21 críticas, 14 altas, 7 medias), además de 12 problemas potenciales que requieren más investigación y 3 medidas de refuerzo.
Página 4 del informe - Tabla de hallazgos
Listado y con seguimiento
La tabla de hallazgos muestra cada problema con su riesgo, estado y una breve descripción. Este es crítico y sigue abierto.
Página 7 del informe - Hallazgo
Crítico: firmas JWT sin verificar
El servidor aceptaba tokens de acceso sin comprobar su firma, así que cualquiera podía falsificar un token de administrador. Además, el secreto compartido, secret123, era fácil de adivinar.
Página 67 del informe - Causa raíz
Tokens decodificados, nunca verificados
El informe atribuye el fallo a una llamada a jwt.decode con la verificación de firma desactivada. El servidor confía entonces en todo lo que dice el token, incluido is_admin.
Página 68 del informe - Evidencia
Las peticiones que lo prueban
Sin token, /admin/create_admin responde 401. Con un token falsificado y una firma falsa, la misma petición crea una cuenta de administrador, y otra elimina la cuenta de un usuario.
Página 69 del informe - Validación
Cada intento en una tabla
Cada token probado, su firma y el resultado, uno al lado del otro. El campo deleted_by de la respuesta muestra el usuario del token falsificado: el servidor confió en él.
Página 69 del informe - Corrección
Cambiar el secreto y verificar cada token
Sustituir secret123 por un secreto aleatorio robusto, comprobar la firma y la caducidad en cada petición, y cargar el usuario desde la base de datos en lugar de confiar en el token.
Página 70 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 transacciones responde sin iniciar sesión?
GET /transactions/123456 devolvió 200 con el historial completo de transacciones de esa cuenta. La petición no llevaba token ni cookie.
Página 45 del informePaso 2
¿El endpoint es simplemente permisivo con los tokens?
Un token Bearer falso, una cookie de sesión falsa y una clave de API inventada recibieron el mismo 200. El endpoint ignora por completo la autenticación.
Página 46 del informePaso 3
¿Funciona con cualquier cuenta?
Sí. Todos los números de cuenta devolvieron datos, incluso las palabras admin y test. Solo la cuenta test devolvió 1.499 transacciones.
Página 46 del informePaso 4
¿Por qué ocurre?
La ruta lee el número de cuenta de la URL y consulta la base de datos con él. Nada comprueba que la cuenta pertenezca a quien hace la petición.
Página 46 del informePaso 5
Entonces, ¿es un riesgo?
Sí, crítico. Cualquiera en internet puede leer los importes, las fechas y las contrapartes de cualquier cliente, y recorrer los números de cuenta para obtenerlos todos.
Página 46 del informePaso 6
¿Qué lo corrige?
Exigir un inicio de sesión válido y devolver 401 sin él. Después, comprobar que la cuenta pertenece a quien hace la petición y devolver 403 si no es así. El informe incluye las peticiones que confirman la corrección.
Página 47 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.