La mayoría de las brechas que acaban en titulares empiezan en una aplicación web o en una API. No en un exploit exótico: en un control de autorización que se comprueba en el navegador y no en el servidor, o en un identificador que se puede cambiar a mano.
Lo que un escáner no encuentra
Las herramientas automatizadas detectan patrones. Los fallos que de verdad cuestan dinero están en la lógica de negocio, y esos hay que buscarlos entendiendo qué hace su aplicación:
Control de acceso roto: acceder a datos de otro usuario cambiando un identificador, o llegar a funciones de administración sin serlo.
Lógica de negocio: aplicar un descuento dos veces, saltarse un paso de un flujo de pago, cancelar algo que no debería poder cancelarse.
Autenticación y sesión: recuperación de contraseña débil, segundo factor que se puede omitir, sesiones que no caducan.
API: exposición excesiva de datos, falta de limitación de tasa y endpoints no documentados que siguen vivos.
Inyecciones y deserialización, cuando las hay, verificadas con prueba de concepto.
Alcance
Aplicaciones web, portales de cliente e intranets.
API REST, GraphQL y servicios web, con y sin documentación previa.
Aplicaciones móviles Android e iOS: análisis estático, dinámico y de su comunicación con el servidor.
Revisión de código asistida, cuando nos dan acceso al repositorio: encuentra más y más barato.
Referencia metodológica: OWASP Testing Guide y OWASP ASVS, más pruebas específicas para su lógica.
Cómo trabajamos
1
Entender la aplicación
Qué hace, quién la usa, qué roles existen y qué operaciones son críticas. Sin esto no se pueden probar los fallos de lógica.
2
Mapeo
Superficie completa: rutas, parámetros, endpoints y flujos, incluidos los que no aparecen en la documentación.
3
Pruebas manuales por rol
Probamos cada función desde cada perfil, incluido el anónimo. Es donde aparece el control de acceso roto.
4
Explotación y encadenado
Verificamos el impacto real: qué dato se alcanza, qué operación se ejecuta y quién podría hacerlo.
5
Informe
Con evidencia reproducible y la corrección concreta, no una recomendación genérica que su equipo de desarrollo no pueda aplicar.
6
Retest
Comprobamos las correcciones cuando su equipo las despliega. Incluido.
Qué recibe
Informe técnico con pasos de reproducción para cada hallazgo.
Corrección concreta, escrita para que la entienda quien programa.
Informe ejecutivo con el riesgo de negocio asociado.
Reunión con el equipo de desarrollo para resolver dudas de remediación.
Retest y certificado del estado final.
Quién lo ejecuta. El mismo equipo que audita, no un perfil comercial. En gobierno, riesgo y cumplimiento: CISSP, CISM, ISO 27001 Lead Auditor, ENS y Análisis de Riesgos (CCN), DPD/DPO certificado, CCSP y CDPP (ISMS Forum) y PMP (PMI). En la parte técnica: OSCP, CRTO II y eWPTX, con presencia en el Top 1 % de la plataforma Atenea del CCN-CERT.
Preguntas que nos hacen
¿Necesitan acceso al código?
No es imprescindible, pero ayuda mucho. Con acceso al repositorio encontramos más en menos tiempo y podemos señalar la línea exacta donde corregir. Sin él trabajamos en caja negra o gris.
¿Lo hacen en producción?
Preferimos preproducción con datos representativos. Si solo existe producción, pactamos ventana, usuarios de prueba y qué operaciones no se ejecutan.
Tenemos despliegue continuo. ¿Qué hacemos?
Auditoría completa periódica más revisiones acotadas en cada cambio relevante. Auditar una vez al año una aplicación que cambia cada semana da una falsa sensación de seguridad.
¿Revisan también las dependencias?
Sí. Buena parte del riesgo de una aplicación moderna está en las bibliotecas de terceros y en la cadena de suministro de software, y eso entra en el alcance.
Que no le encuentren el fallo desde fuera
Media hora con un auditor para acotar el alcance de la auditoría de su aplicación o de su API.
Teléfono: +34 686 250 244 (L-V, 9:00 a 18:00) · Email: info@jaymonsecurity.com
Respondemos en 2 horas dentro del horario laboral.
