Test de intrusión de aplicaciones web
Los escáneres automáticos encuentran las vulnerabilidades que encuentra cualquier escáner. Los fallos que de verdad se explotan - autorización rota, abusos encadenados de la lógica de negocio, elusiones sutiles de autenticación - necesitan a una persona que lea su aplicación como lo haría un atacante. Eso es lo que entrega este proyecto.
Qué incluye
- Cobertura del OWASP Top 10
- Pruebas de autenticación & de sesión
- Pruebas de autorización / IDOR en todos los roles
- Lógica de negocio & abuso de flujos
- Pruebas de API REST / GraphQL
- Pruebas de inyección, SSRF, XXE y subida de ficheros
Entregables
- Resumen ejecutivo para la dirección
- Informe técnico con hallazgos valorados con CVSS
- Pasos de reproducción & evidencias con capturas
- Hoja de ruta de corrección priorizada
- Sesión de repaso en directo con su equipo
- Carta de atestación para auditores y clientes, a petición
- Atestación de corrección tras la reprueba, como documento independiente
Calendario
3-5 días laborables, según el número de roles y la superficie de endpoints. El calendario exacto se confirma en su propuesta escrita antes de que empiecen las pruebas.
Donde acaban los escáneres y empieza el trabajo manual
Un escáner encontrará XSS reflejado y bibliotecas desactualizadas. No encontrará que un endpoint de borrar comentario comprueba el identificador del comentario pero no si pertenece al usuario que lo solicita, ni que cambiar un parámetro de rol a mitad del pago se salta un paso de validación. Esos son los hallazgos que realmente se explotan, y solo salen a la luz cuando alguien lee el comportamiento real de la aplicación en lugar de buscar coincidencias con firmas conocidas.
Las pruebas cubren como base todas las categorías del OWASP Top 10 y después profundizan en cómo está construida su aplicación concreta: sus roles y su modelo de permisos, sus flujos de varios pasos y sus contratos de API. Si su aplicación tiene un rol de administrador, un flujo de facturación o subida de ficheros, reciben atención dedicada: ahí suelen estar los hallazgos de mayor impacto.
Metodología
Pruebas autenticadas en todos los roles definidos en su aplicación, con Burp Suite para la interceptación y análisis manual para la lógica. La cobertura incluye clases de inyección (SQLi, inyección de comandos, SSTI), autenticación y gestión de sesiones, control de acceso tanto en la interfaz como en la capa de API, SSRF y XXE donde haya tratamiento de ficheros o URL, y abuso de subida de ficheros cuando proceda. Cada hallazgo se verifica manualmente antes de reportarse: ninguna salida de escáner sin confirmar llega a su informe. Mi referencia de explotación web y mi metodología de enumeración publicadas reflejan las mismas técnicas que se usan aquí.
Qué no hacen las pruebas
Sin pruebas de denegación de servicio, sin acciones destructivas sobre datos de producción y sin ingeniería social salvo que se incluya explícitamente en el alcance. Todo lo que ponga en riesgo la disponibilidad o la integridad de los datos se confirma antes con usted bajo las reglas de enfrentamiento firmadas.
Preguntas sobre pruebas de aplicaciones web
El OWASP Top 10 como base - inyección, control de acceso roto, fallos de autenticación, configuración insegura, SSRF, etcétera - más pruebas manuales de fallos de lógica de negocio que los escáneres automáticos no pueden encontrar: flujos rotos, huecos de autorización tipo IDOR, manipulación de precios o cantidades y abuso de procesos de varios pasos propios del funcionamiento real de su aplicación.
Sí. La mayoría de las aplicaciones modernas están dirigidas por API, y la superficie de API suele ser donde están los hallazgos interesantes: falta de autorización a nivel de objeto, asignación masiva, carencias en los límites de peticiones y problemas en el manejo de JWT. Si tiene una API REST o GraphQL, se prueba junto al frontend, no como algo secundario.
Pruebas manuales, usando herramientas automáticas (Burp Suite y otras) para acelerar la cobertura, no para sustituir el criterio. Los fallos de lógica de negocio, las elusiones de autorización y las vulnerabilidades encadenadas los encuentra una persona que lee el comportamiento real de la aplicación, no un escáner que compara firmas.
De 3 a 5 días laborables para una aplicación típica, según el número de roles, flujos y endpoints de API incluidos en el alcance. Las aplicaciones más grandes, con varios roles de usuario o modelos de permisos complejos, tardan más: el calendario exacto se confirma en su propuesta escrita.
Sí, y a menudo es preferible: preproducción evita cualquier riesgo para los datos reales de clientes y sigue probando la lógica real de la aplicación, siempre que sea un reflejo fiel de producción. Probar en producción también está bien dentro de una ventana acordada de reglas de enfrentamiento.
Las pruebas de aplicaciones web empiezan desde 500 $, en función del número de roles, flujos y endpoints de la aplicación. Recibe un precio cerrado por escrito antes de que empiecen las pruebas; consulte la página de precios para más detalle.
Descubra primero lo que encontraría un atacante real
Llamada de alcance gratuita, propuesta a precio cerrado en 24 horas.