Seguridad ofensiva: pentesting de aplicaciones y APIs

Qué incluye exactamente

Probamos aplicaciones web y APIs REST y GraphQL, y empezamos por la capa de identidad: autenticación, autorización y sesiones. Ahí buscamos IDOR, escalamiento de privilegios y manejo de tokens, porque todo lo que venga después depende de quién cree el sistema que eres. En GraphQL no hay rutas que enumerar, hay campos y relaciones, y el control de acceso suele quedar en el resolver. Es el mismo orden con el que revisamos NorteCampo, NortePrevent, Ollin y Nika antes de dejarlos en producción.

Con el acceso entendido vamos por la lógica de negocio explotable: el flujo que se salta un paso, la operación que se confirma sin validación del servidor. Ahí entran las condiciones de carrera, que solo aparecen cuando dos peticiones llegan en el mismo milisegundo y ningún escáner reporta. Si compartes el código fuente, revisamos las partes que las pruebas señalaron como frágiles: como escribimos y operamos software en producción, distinguimos un patrón feo de uno explotable. El modelo de amenazas de la arquitectura cierra el cuadro: qué componente confía en cuál y qué pasa si uno cae.

Cuando hay datos personales de por medio revisamos los controles frente a la LFPDPPP: qué se recolecta, quién puede leerlo, cómo se borra y qué queda en bitácoras y respaldos. No sustituye a un abogado: es la parte técnica que sostiene lo que promete el aviso de privacidad. La repetición de pruebas tras la remediación cierra el ciclo con el mismo método y los mismos hallazgos, porque hemos visto arreglos que cierran la ruta probada y dejan abierta la de al lado.

Qué se entrega

El entregable central es un reporte técnico: cada hallazgo con su evidencia, los pasos para reproducirlo, su severidad CVSS y la remediación. Lo escribimos con el detalle de los advisories que publicamos, para que un desarrollador reproduzca el fallo en su ambiente y sepa qué tocar. Encabezándolo va un resumen ejecutivo de una página para dirección, con el riesgo en términos de negocio y la decisión que toca tomar.

Leemos los dos con tu equipo técnico en una sesión, hallazgo por hallazgo, y ahí se resuelven las dudas de reproducción. Cuando el equipo termina de corregir, entregamos el reporte de verificación: por cada hallazgo, si quedó cerrado, si quedó parcial o si el arreglo abrió otra cosa. Ese documento es el que sirve cuando un cliente o un auditor pregunta por el estado de la aplicación.

Cómo trabajamos

Antes de tocar nada fijamos el alcance por escrito: qué sistemas entran, cuáles quedan fuera, las ventanas de prueba y la autorización de quien puede darla. Sin ese papel no empezamos. Con el alcance cerrado arrancan las pruebas: primero reconocimiento, después trabajo manual apoyado en herramientas propias como SecAgent, el motor con el que correlacionamos tráfico y eventos mientras probamos. La automatización cubre el terreno repetitivo. Encadenar dos fallos menores hasta volverlos uno grave lo hace una persona.

Cuando cierra la ventana de pruebas viene el reporte y la sesión de lectura con tu equipo. Ahí se acuerda el orden de la corrección, que casi nunca coincide con el de la severidad: pesa qué tan expuesto está cada sistema y cuánto cuesta cada arreglo. Después el equipo corrige a su ritmo. Al final hacemos la verificación: repetimos las pruebas sobre lo corregido y cerramos el reporte con el estado de cada hallazgo.

Para quién es

Empresas con aplicaciones o APIs en producción que manejan datos de clientes: salud, fintech, comercio electrónico y agroindustria. También equipos que van a lanzar y quieren probar antes.