La metodología de pentesting de aplicaciones web que aplicamos

El mejor fallo que encontré el trimestre pasado no estaba en el informe del escáner. Apareció en esa hora muerta, cuando el escaneo ya había terminado, en la cuarta pasada por un flujo de compra, al fijarme en que el order_id de una petición de confirmación era un simple entero que se iba incrementando. Réstale uno. Vuelve a enviarlo. Y me devolvió la dirección de envío de otra persona. Ese hueco – el que separa lo que una herramienta marca de lo que un atacante hace de verdad con ello – es toda la razón por la que nuestra metodología de pentesting de aplicaciones web está construida como está.

Lo que viene a continuación es el proceso que seguimos en proyectos reales, no una diapositiva de un argumentario comercial. El orden se adapta según la aplicación. La estructura se mantiene. Cada fase alimenta a la siguiente.

Puntos clave

• Una metodología de pentesting de aplicaciones web de verdad se apoya en el trabajo manual. Los escáneres cubren el terreno y generan ruido; las personas encuentran los fallos de control de acceso y de lógica de negocio que las herramientas, por su propio diseño, no pueden ver.
• Trabajamos por fases: alcance y reconocimiento, mapeo, autenticación y sesión, control de acceso, inyección, lógica de negocio y, por último, el informe y un retesteo para confirmar que las correcciones han surtido efecto de verdad.
• Los hallazgos de mayor impacto suelen ser el control de acceso roto (IDOR) y el abuso de lógica, no la corrupción de memoria exótica. Encajan en OWASP Top 10 A01 y siguen siendo las críticas más habituales que documentamos.
• Un hallazgo sin una prueba de concepto reproducible y una corrección concreta es medio hallazgo. El informe es el producto.
• El retesteo importa tanto como la prueba inicial. Un ticket marcado como “corregido” que nadie ha vuelto a revisar es una forma habitual de que una vulnerabilidad viva acabe en producción.

Qué es en realidad el pentesting de aplicaciones web

El pentesting de aplicaciones web es una simulación de ataque autorizada y orientada a objetivos contra una aplicación concreta, ejecutada por una persona con las mismas herramientas y la misma mentalidad que usaría un atacante real. El objetivo no es una lista de debilidades teóricas. El objetivo es demostrar cuáles se pueden explotar, hasta dónde llegan y qué podría conseguir de verdad un intruso decidido o un usuario malicioso ya autenticado.

Esa distinción condiciona todo lo demás. Un escaneo pregunta: ¿existe este patrón? Un pentest pregunta: ¿puedo convertir esto en acceso a datos o a dinero? La segunda pregunta es más difícil. No se automatiza bien. Y ahí es justo donde está el valor.

Fase 1: alcance, reglas de enfrentamiento y reconocimiento

Antes de que salga una sola petición, fijamos el alcance por escrito. Qué nombres de host y subdominios entran en juego. Qué entorno usamos – insistimos con fuerza en un espejo de staging antes que en datos reales de clientes. Qué roles nos dan, si probamos como un intruso sin autenticar, como un usuario de bajos privilegios o como ambos, y qué endpoints quedan fuera de límites. Las reglas de enfrentamiento no son papeleo. Conseguir cuentas de prueba con dos niveles de privilegio distintos suele ser el único factor que decide si podemos llegar a demostrar un fallo de control de acceso.

El reconocimiento mapea entonces la superficie de ataque. Enumeramos subdominios, descargamos los bundles de JavaScript y los analizamos en busca de rutas de API ocultas y claves incrustadas, leemos cualquier definición Swagger u OpenAPI y hacemos fingerprinting del stack. Una SPA moderna filtra sin pudor todo su contrato de backend en un fichero JS con source map. Leer ese fichero con calma le gana a adivinar siempre.

Fase 2: mapear la aplicación

Ahora manejamos la aplicación a mano con Burp Suite interceptándolo todo. Cada rol, cada flujo de trabajo, cada cambio de estado. Registrarse, iniciar sesión, restablecer una contraseña, subir un fichero, comprar algo, invitar a un compañero, cambiar un rol, borrar un objeto. El historial del proxy tras un recorrido a fondo se convierte en el mapa desde el que atacamos.

Para las rutas a las que la interfaz nunca enlaza, lanzamos ffuf y el crawler de Burp para descubrir contenido y parámetros. Paneles de administración viejos. Rutas de depuración. Un /api/v1 olvidado que nunca recibió las comprobaciones de autorización que alguien atornilló a v2. Esta última aparece constantemente.

ffuf -w wordlist.txt -u https://app.example.com/api/FUZZ \
  -H "Authorization: Bearer <low-priv-token>" \
  -mc 200,201,401,403 -o results.json

Fase 3: autenticación y gestión de sesiones

La autenticación tiene su propia línea de trabajo, porque equivocarse aquí es catastrófico y equivocarse de forma sutil está por todas partes. Probamos los flujos de restablecimiento de contraseña en busca de tokens predecibles y de envenenamiento de la cabecera Host. Comprobamos si las sesiones mueren de verdad al cerrar sesión y al cambiar la contraseña, o solo fingen hacerlo. Miramos con lupa el manejo de JWT: confusión de algoritmos, falta de verificación de la firma, alg: none, tokens que nunca caducan. Y sondeamos los flujos multifactor buscando el hueco clásico en el que el segundo factor se exige en la interfaz pero no en la llamada a la API que hay por debajo.

Algo que vemos en un número deprimente de aplicaciones: hay rate limiting en el formulario de login, pero ninguno en el endpoint JSON que tiene detrás. Si el front limita y la API se encoge de hombros, el credential stuffing entra tan tranquilo.

Fase 4: control de acceso – donde viven las críticas

El control de acceso roto es OWASP Top 10 A01, y es la categoría que produce la mayoría de nuestros hallazgos críticos. El clásico es IDOR (insecure direct object reference, CWE-639): un identificador de objeto en una petición en el que el servidor confía sin comprobar jamás si el usuario actual es dueño de ese objeto.

Por esto importan dos cuentas de prueba. Capturamos una petición como usuario A, la reproducimos como usuario B cambiando únicamente el ID del objeto o el token de sesión, y observamos si el usuario B se marcha con los datos del usuario A.

GET /api/v2/invoices/48213 HTTP/1.1
Host: app.example.com
Authorization: Bearer <user-B-token>

# Invoice 48213 belongs to user A.
# A 200 with A's data means IDOR.

También probamos la escalada vertical (¿puede un usuario estándar alcanzar una función reservada a administradores llamando directamente al endpoint?), el mass assignment (¿añadir "role":"admin" al cuerpo de una actualización de perfil se queda de verdad?) y la navegación forzada hacia funciones que el menú oculta pero que el servidor sigue sirviendo. Los escáneres se pierden casi todo esto. No tienen ni idea de quién se supone que es dueño de qué. Ese contexto vive en la cabeza de quien realiza la prueba.

Fase 5: inyección y fallos del lado del servidor

La inyección se entiende bien y no se ha ido a ninguna parte. Se ha desplazado. Seguimos buscando SQL injection con payloads manuales y automáticos, pero las horas se van ahora en las variantes que los frameworks no te resolvieron: server-side template injection, SSRF donde un parámetro de URL hace que el servidor solicite recursos internos (una línea recta hasta los endpoints de metadatos de la nube), procesamiento de entidades externas XML en cualquier cosa que todavía ingiera XML, y command injection escondida en el procesamiento de ficheros o en las funciones de exportación.

El cross-site scripting sigue estando por todas partes, sobre todo el XSS basado en DOM en las SPA, donde un valor fluye desde la URL hasta innerHTML o hasta un sink del framework sin ninguna sanitización. Confirmamos cada candidato a mano. Un valor reflejado en una respuesta no demuestra nada. La ejecución en un navegador sí lo demuestra.

Fase 6: lógica de negocio – lo que las herramientas no pueden hacer

La prueba de la lógica de negocio es donde la experiencia separa una evaluación real de un PDF de escanear y volcar. No hay ninguna firma para “el cupón se aplica dos veces”, ni para “puedes saltarte el paso del pago y aún así aterrizar en el plan de pago”, ni para “el campo de cantidad acepta un número negativo y te abona la cuenta”. Eso solo se convierte en hallazgo cuando una persona entiende qué se supone que debe hacer la aplicación y luego rompe a propósito la suposición que hay debajo.

En los proyectos encontramos de forma habitual race conditions en los flujos de canje y de retirada de fondos – lanza la misma petición veinte veces en paralelo y mira si una acción de un solo uso se dispara dos veces. Pasos del flujo que se pueden reordenar o saltar. Límites que solo se aplican en el cliente. Esta categoría rara vez aparece en la salida automatizada, y es a menudo donde se concentra el mayor daño en el mundo real.

Fase 7: informe y retesteo

El informe es el entregable, así que lo escribimos para dos lectores a la vez. La dirección recibe un resumen ordenado por riesgo y en términos de negocio. El equipo técnico recibe una ficha por cada hallazgo: severidad (la puntuamos con CVSS, pero siempre la matizamos frente a la explotabilidad real en tu contexto), reproducción paso a paso, la petición o el payload exactos y una corrección concreta. No un “sanea la entrada”. Qué comprobación añadir, y dónde.

Luego hacemos el retesteo. Cuando tu equipo despliega las correcciones, volvemos a ejecutar los ataques exactos que funcionaron y confirmamos que están muertos, y comprobamos que no hemos abierto un agujero al lado. No hay forma de esquivar un hallazgo con palabras; el payload se dispara o no se dispara. Una remediación que nadie verificó es la manera en la que una vulnerabilidad “cerrada” llega en silencio a producción.

Cómo ayuda CyberXplore

Esta metodología es exactamente lo que ejecutamos dentro de nuestro servicio de pentesting de aplicaciones web: testers senior, trabajo con base manual, un informe sobre el que tus ingenieros pueden actuar y un retesteo incluido, de modo que pagas por correcciones que aguantan, no por un PDF que acumula polvo. ¿Quieres ayuda con el alcance o una respuesta clara sobre el esfuerzo y los plazos para tu aplicación? Solicita un presupuesto y recorreremos tu superficie contigo antes de que te comprometas a nada.

Preguntas frecuentes

¿Cuánto dura un pentest de aplicaciones web?

Para una aplicación de tamaño medio típica, cuenta con aproximadamente una o dos semanas de pruebas activas más unos días para el informe. Escala con el número de roles, endpoints y flujos de trabajo que entren en el alcance. Las aplicaciones con mucha lógica de negocio o con muchos niveles de privilegio llevan más tiempo, porque esas son las partes que no puedes acelerar. Definir bien el alcance de la aplicación desde el principio es lo que mantiene honesta la estimación.

¿Cuál es la diferencia entre un escaneo y un test de intrusión?

Un escaneo de vulnerabilidades es una comparación automática de patrones que informa de firmas conocidas y genera un montón de falsos positivos. Un test de intrusión es una persona atacando la aplicación para demostrar un impacto real y explotable, incluidos los fallos de control de acceso y de lógica de negocio que los escáneres no pueden detectar. Usamos escáneres dentro de un pentest para tener cobertura. Son el inicio del trabajo, no todo el trabajo.

¿Hace falta acceso a producción o un entorno de staging?

Preferimos un entorno de staging o preproducción que replique el comportamiento de producción, idealmente poblado con datos de prueba en lugar de registros reales de clientes. Eso nos permite probar de forma agresiva sin poner en riesgo los datos en vivo ni la disponibilidad. Si solo hay producción disponible, ajustamos las reglas de enfrentamiento para probar de forma segura y evitar acciones destructivas.

¿Por qué pedís varias cuentas de usuario y roles?

Porque la mayoría de los hallazgos críticos son fallos de control de acceso, y no puedes demostrar uno sin dos perspectivas. Probar como usuario A y como usuario B confirma si el servidor comprueba de verdad la propiedad. Probar una cuenta de bajos privilegios contra funciones de administración deja al descubierto la escalada vertical. Sin esas cuentas podemos sospechar de estos fallos, pero no demostrarlos.

¿Se incluye un retesteo?

Sí. Después de que tu equipo remedie, volvemos a ejecutar los ataques que tuvieron éxito, confirmamos que las correcciones aguantan y actualizamos el estado en el informe. Un hallazgo no está realmente cerrado hasta que alguien ha verificado que la corrección funciona, y esa verificación forma parte del proyecto, no es un extra.

¿Cubre esta metodología las API y las single-page apps?

Sí. Una aplicación web moderna suele ser una SPA que habla con una API JSON o GraphQL, así que la API es donde se va buena parte de nuestro tiempo. Analizamos los bundles del front-end para mapear el contrato de backend y luego probamos los endpoints de la API directamente en busca de fallos de autorización, de inyección y de lógica, en lugar de fiarnos de lo que la interfaz decida exponer.