Las 7 vulnerabilidades
que ningún escáner encuentra.

Índice.

Cada vulnerabilidad incluye contexto técnico, por qué los escáneres la pasan por alto, cómo detectarla manualmente y la remediación específica al stack.

Lo que un escáner
nunca verá.

Un escáner automatizado opera bajo dos restricciones técnicas que limitan radicalmente su capacidad de detección: no entiende el dominio del negocio y no construye cadenas de explotación que requieran razonamiento contextual. Estas dos limitaciones son la razón por la que las vulnerabilidades de mayor impacto en plataformas financieras siguen apareciendo, año tras año, en cuentas que ya pasaron por escaneos automáticos sin un solo flag.

El catálogo de un escáner está poblado por firmas: patrones que reconoce y reporta. Una firma puede detectar un parámetro de tipo numérico que acepta una comilla (signo de SQL injection). No puede detectar que un endpoint de transferencia bancaria acepta montos negativos, porque no sabe qué es un monto, ni que debería ser positivo. Esa información vive en la cabeza del desarrollador y en los requirements del producto.

Las tres categorías que escapan a la automatización

Las vulnerabilidades que documentamos en este whitepaper caen en tres categorías que comparten un denominador: requieren entender qué hace la aplicación, no solo cómo responde.

1. Lógica de negocio. El escáner no sabe que un cupón solo debe redimirse una vez, ni que un crédito debe ser positivo, ni que una transferencia bancaria no debería procesarse dos veces si el cliente envía dos peticiones idénticas en rápida sucesión.
2. Authorization context-aware. Detectar IDOR exige enumerar recursos válidos en producción, sustituirlos en cada endpoint y validar si el servidor responde con datos que no le pertenecen al usuario autenticado. Un escáner enumera firmas, no objetos del dominio.
3. Cadenas multi-paso. Encontrar un secret en JavaScript es trivial. Convertir ese secret en account takeover requiere encadenar: lectura del JS, decodificación, generación de un token forged, llamada a un endpoint privilegiado, observación del resultado. Esa cadena la construye un humano con criterio, no un escáner.

Business Logic Bypass.

La aplicación procesa entradas que técnicamente cumplen el contrato del API (tipos correctos, autenticación válida, parámetros presentes) pero violan reglas implícitas del negocio. El servidor no las rechaza porque la regla nunca fue codificada en el backend; vivía solo en el frontend o en la cabeza del producto manager.

Patrón 1: Montos negativos en operaciones financieras

El frontend valida que el campo de monto sea positivo antes de enviar la petición. El backend asume que esa validación ya ocurrió y aplica la fórmula de balance directamente. Cuando un atacante intercepta la petición y modifica el valor a un negativo, el cálculo se invierte y el saldo aumenta en lugar de disminuir.

# Saldo final = Saldo inicial − Monto submitido
# Esperado:  277,943.54 − 24.44   = 277,919.10  ✓
# Inyectado: 277,943.54 − (−24.44) = 277,967.98  ✗
# El operador menos por menos da más.

En engagements reales hemos visto este patrón inflar saldos hasta +$900,000 USD en un solo request en entornos de staging. La operación es trivial: un proxy, un valor con guion. Cinco minutos.

Patrón 2: Race conditions en transferencias

Dos peticiones idénticas enviadas simultáneamente al endpoint de transferencia se procesan ambas porque la verificación de saldo ocurre antes que el lock transaccional. El cliente recibe dos confirmaciones; el saldo solo se descontó una vez.

Cómo lo detectamos

Burp Turbo Intruder con paquete de 20 peticiones idénticas disparadas en una ventana de 100ms. Si el endpoint procesa más de una transferencia con saldo insuficiente para ambas, la race condition existe.

Patrón 3: Status tampering

El cliente envía un campo status en la petición de actualización. El backend lo persiste sin validar si el cambio de estado es legítimo según la máquina de estados del negocio. Un pago marcado como aprobado puede revertirse a pendiente o cancelado mientras el bien o servicio ya fue entregado.

Patrón 4: Coupon / promo code replay

El código de descuento se valida contra la base de datos en cada redención, pero el flag de "ya usado" se persiste solo después de procesar el pedido completo. Una ráfaga de peticiones simultáneas redime el cupón N veces antes de que el flag se actualice.

Remediación

• Validación dual. Cualquier validación que viva en el frontend debe duplicarse en el servidor con la misma lógica. El frontend valida UX; el servidor valida confianza.
• State machine explícita. Los cambios de estado deben pasar por una máquina formal con transiciones permitidas declaradas. Un pago aprobado no puede regresar a pendiente sin un proceso de reversa autenticado.
• Idempotency keys. Toda operación que mueve dinero debe aceptar una clave única por transacción. Peticiones duplicadas con la misma clave devuelven el resultado original sin reprocesar.
• Locks pesimistas o tokens transaccionales. Race conditions se previenen con bloqueos a nivel de fila o tokens de un solo uso emitidos al inicio de la operación.
• Auditoría persistente. Cada operación monetaria debe registrar quién, cuándo, monto, IP, headers de origen. Sin este log, las disputas con el banco se vuelven imposibles de rastrear.

BOLA con autorización
ciega por ID.

Broken Object Level Authorization es la vulnerabilidad más común en APIs modernas y la primera categoría del OWASP API Security Top 10 desde 2019. Es también la más fácilmente explotable y la que más impacto financiero produce en plataformas que manejan recursos de usuario (préstamos, transacciones, archivos, registros médicos).

El patrón ciego

El servidor recibe un identificador del recurso solicitado en el path o el body de la petición. Procede a recuperar el recurso de la base de datos y devolverlo sin verificar primero si el usuario autenticado tiene derecho a verlo. La autenticación está, la autorización no.

# Backend vulnerable
@app.get("/api/loans/{loan_id}")
def get_loan(loan_id: str, user = auth_required()):
    return db.loans.find(loan_id)  # ← sin filtro de owner

El atacante autenticado con su propio token sustituye el loan_id en el path por uno que infiere o enumera. El servidor responde con el recurso completo: monto, historial de pagos, datos personales del titular, scoring crediticio.

Variantes que un escáner sí pierde

1. BOLA con UUID. Si los IDs son UUIDs, el atacante no puede iterar trivialmente. Pero si la aplicación expone una lista paginada en otro endpoint, los UUIDs se pueden cosechar.
2. BOLA cross-tenant. En SaaS multi-tenant, el ID de tenant viaja en un header o claim del JWT. Si el backend no valida que los recursos solicitados pertenecen al tenant del JWT, un usuario de la organización A puede leer datos de la organización B.
3. BOLA via mass operations. El endpoint /bulk/delete?ids=[1,2,3,4] aplica filtro de ownership solo al primer ID. Los siguientes se procesan sin validación.

Cómo detectarlo manualmente

El método es directo y exige paciencia disciplinada. Para cada endpoint del API que recibe un identificador de recurso:

1. Crear dos cuentas de prueba en la plataforma (víctima y atacante).
2. Como víctima, generar recursos de prueba (préstamo, archivo, registro).
3. Capturar el id del recurso de la víctima.
4. Cambiar a la sesión del atacante. Repetir la petición original sustituyendo el ID por el de la víctima.
5. Observar la respuesta. Si retorna 200 con datos completos, BOLA confirmado.

Este proceso debe repetirse para cada endpoint con identificadores. En APIs de 50+ endpoints, son varias horas de trabajo metódico. Burp Suite con extensiones como AuthMatrix o Autorize automatiza la captura y comparación de respuestas, pero la decisión final de qué endpoint probar y con qué payload sigue siendo manual.

Remediación

• Filtro de ownership en cada query. Toda recuperación de recursos debe filtrar por el user_id del token, no aceptar el ID del cliente como única referencia.
• UUIDs en lugar de enteros. No es una fix por sí sola, pero hace la enumeración mucho más costosa cuando se combina con filtros server-side y rate limits.
• Tenant scoping a nivel de framework. En multi-tenant, usar middleware que automáticamente filtra todas las queries por el tenant del usuario. Eliminar la posibilidad de que un desarrollador "olvide" agregarlo.
• 403 explícito y logged. Cuando un usuario intenta acceder a un recurso que no le pertenece, devolver 403 (no 404) y registrar el evento. Un volumen anómalo de 403 en una cuenta es señal de explotación activa.

JWT signing key
en client-side.

La aplicación firma sus tokens JWT con un algoritmo simétrico (HS256) y, por descuido en el bundling del frontend, el secreto de firma queda embebido en un archivo JavaScript público accesible desde cualquier navegador. Una vez que el secreto está expuesto, un atacante puede generar tokens JWT válidos para cualquier usuario, incluyendo administradores.

El descubrimiento

El proceso típico empieza descargando el bundle JavaScript principal de la aplicación. Herramientas como jsluice, SecretFinder o regex grep contra patrones tipo SECRET_KEY, SIGNING_KEY, JWT_SECRET producen el match. En engagements reales hemos encontrado el secreto literalmente en una constante exportada:

// main.f2924b6f.js (línea 1247)
const REACT_APP_SECRET_KEY = "[REDACTED-32-char-hex]";
const REACT_APP_AES_KEY    = "[REDACTED]";

Las dos constantes salen del archivo .env del proyecto y son inyectadas en el build a través de variables de entorno con prefijo REACT_APP_*. El desarrollador asumió que las variables de entorno son privadas; el bundler de Create React App las expone públicamente por diseño cuando llevan ese prefijo.

El forge

Un script en Python decodifica un JWT propio del atacante, modifica el claim user_id al ID de un administrador conocido, y re-firma el token con el secreto exfiltrado. El servidor valida la firma criptográficamente, encuentra que es correcta, y emite la sesión privilegiada.

# Forge mínimo en Python
import jwt

original = "eyJhbGciOiJIUzI1NiIs..."
payload  = jwt.decode(original, options={"verify_signature": False})
payload["user_id"] = 1  # admin
forged = jwt.encode(payload, SECRET, algorithm="HS256")
# forged ahora es un token válido para user_id=1

De forge a account takeover

Tener un token administrativo válido no es la explotación final; es el habilitador. Con el token forged, el atacante ejecuta acciones que el endpoint /api/admin/* permite. En el caso documentado, eso incluyó:

1. Listar todos los usuarios de la plataforma.
2. Invitar un nuevo usuario administrativo con email controlado por el atacante.
3. Recibir el email de invitación, completar el registro, login normal.
4. Tener acceso administrativo permanente sin haber comprometido a ningún usuario legítimo.

El registro del nuevo administrador se ve idéntico a un onboarding normal en los logs, dificultando la detección post-incidente.

Remediación

• Migrar a algoritmo asimétrico (RS256, ES256). El servidor mantiene la clave privada; la pública (que se puede exponer sin riesgo) se distribuye para verificación. Forjar tokens requiere comprometer el servidor, no leer el frontend.
• Auditar el bundle del frontend. Búsqueda regular con herramientas como trufflehog, gitleaks, o reglas custom de regex en CI/CD. Cualquier match en la rama main bloquea el merge.
• Variables de entorno seguras. Frameworks modernos (Next.js, Nuxt) distinguen entre variables de servidor y de cliente con prefijos. El secreto JWT nunca debe llevar el prefijo público.
• Rotación inmediata si hubo exposición. Una vez que el secreto fue público (aunque sea por un commit), debe rotarse. Todos los tokens emitidos previamente quedan invalidados.
• Validación de claims contextuales. Aún si la firma es válida, el servidor debe verificar el contexto del usuario (IP, dispositivo, comportamiento reciente). Un token administrativo emitido desde un origen anómalo debería disparar challenge adicional.

Detección preventiva en CI/CD

El control más efectivo contra esta clase de vulnerabilidad es la detección automática en el pipeline antes de que el código llegue a producción. Una regla de pre-commit hook combinada con un scan de secretos en el pull request elimina la mayoría de los casos.

# Pre-commit hook con trufflehog
trufflehog filesystem ./src \
  --exclude-paths .trufflehog-ignore \
  --fail \
  --json | jq '.SourceMetadata.Data.Filesystem.file'

Este patrón ataca el problema en el origen: el secreto nunca llega al bundle público porque el commit que lo introdujo se rechaza antes del merge. Combinado con escaneo periódico del frontend en producción (en caso de que un secreto se cuele por otra vía), proporciona defensa en profundidad.

Métricas de exposición real

En auditorías a 47 plataformas en producción durante 2024 y 2025, encontramos secretos accionables embebidos en frontend en el 23% de los casos. De esos, el 40% eran claves de firma JWT o secretos de cifrado simétrico que permitían escalación de privilegios directa. La media de tiempo de descubrimiento fue de 18 minutos por proyecto, prácticamente la primera hora de cualquier engagement.

Origin header injection
en magic links.

El servidor que despacha correos de login con magic link construye la URL del link concatenando el header Origin de la petición HTTP entrante con el token. Sin validación de que el origin pertenece a un dominio confiable, un atacante puede inyectar un dominio bajo su control y recibir el token de autenticación cuando la víctima haga click.

La cadena completa

1. El atacante levanta un servidor HTTP de captura (Burp Collaborator, oastify, listener propio).
2. Envía una petición POST al endpoint de "enviar magic link" con el email de la víctima en el body y el dominio de captura en el header Origin.
3. El servidor envía el correo a la víctima con el link apuntando al dominio del atacante.
4. La víctima recibe el correo del dominio legítimo de la aplicación, con el formato esperado, con el remitente esperado.
5. La víctima hace click. El navegador navega al dominio del atacante. El listener captura el token completo en la URL.
6. El atacante reconstruye el link sustituyendo el dominio por el legítimo, lo abre en su browser, queda autenticado como la víctima.

Petición vulnerable

POST /api/auth/send-magic-link HTTP/1.1
Host: api.app-redacted.xyz
Origin: https://[ATTACKER-COLLABORATOR].oastify.com
Content-Type: application/json

{ "email": "[email protected]" }

Correo recibido por la víctima

From: [email protected]
Subject: Click here to login

Click the following link to access your account:
https://[ATTACKER-COLLABORATOR].oastify.com/?u=yFDJ...&t=[ONE-TIME-TOKEN]

Por qué es peor que phishing tradicional

En un phishing convencional el atacante necesita comprar un dominio parecido al legítimo y diseñar una página falsa que copie el login. La víctima entrenada para inspeccionar URLs puede detectar la diferencia. Aquí no aplica: el correo proviene del dominio legítimo, con el remitente real, y el único elemento sospechoso es la URL del link, que la mayoría de usuarios no inspecciona antes de hacer click.

Adicionalmente, el atacante nunca necesita acceso al inbox de la víctima. El token de autenticación se transmite por la propia acción de hacer click. La víctima cree que está iniciando sesión normalmente; el atacante ya tiene la sesión.

Remediación

• Allowlist server-side de orígenes válidos. El servidor mantiene una lista explícita de dominios confiables y rechaza la petición si Origin no coincide con ninguno.
• Mejor: ignorar el header Origin para URLs en correos. La URL base debe leerse de configuración del servidor (variable de entorno APP_URL), no del cliente. Eliminar la dependencia del header elimina la clase de vulnerabilidad.
• Validación adicional del Referer. Defensa en profundidad: aceptar la petición solo si Referer también coincide con un origen confiable. No es defensa primaria (Referer puede ser stripped) pero detecta intentos.
• Single-use tokens con validación de IP. El token de magic link es válido solo si se redime desde la misma IP que solicitó el envío (cuando aplica). Reduce ventana de explotación a sesiones donde atacante y víctima compartan red.
• Logs de redención sospechosa. Cuando el token se redime desde un User-Agent o IP distinta a la que originó la solicitud, requerir verificación adicional (MFA challenge, confirmación por email separado).

Detección manual paso a paso

El proceso para detectar esta vulnerabilidad es mecánico y rápido. Para cada endpoint que dispara un correo:

1. Capturar la petición original con Burp Suite.
2. Modificar el header Origin a un dominio bajo control del tester (Collaborator funciona sin infraestructura).
3. Reenviar la petición.
4. Inspeccionar el correo recibido en la cuenta de prueba.
5. Si la URL del link refleja el dominio del header inyectado, la vulnerabilidad existe.

El test completo toma menos de cinco minutos por endpoint. Una API con cinco endpoints que envían correos puede auditarse en quince minutos. La probabilidad de encontrar al menos uno vulnerable en una primera auditoría es estadísticamente alta: en nuestros datos, aproximadamente el 30% de los servicios web evaluados tenía al menos un endpoint con esta clase de problema.

Variantes relacionadas

El mismo patrón aplica a otros headers HTTP que el cliente puede manipular y que el servidor incorpora en respuestas o emails sin validar:

• Host header injection. El servidor usa Host para construir URLs absolutas en respuestas o templates de correo.
• X-Forwarded-Host abuse. Detrás de proxies o CDNs, el header forwarded puede ser manipulado por el cliente.
• Referer-based validation. Sistemas que confían en Referer para autorización (CSRF defense, redirección post-auth) son vulnerables a stripping y manipulación.

Multi-step flow:
OTP cosmético.

El flujo transaccional valida el código OTP en una petición intermedia, pero la petición final que ejecuta la operación crítica no requiere ni el código ni un identificador de transacción que confirme la validación previa. El frontend siempre envía las dos peticiones en secuencia, así que el desarrollador asume que llegar al paso final implica haber pasado el OTP. Un proxy demuestra que esa asunción es falsa.

El flujo típico vulnerable

1. POST /api/transaction/init. El cliente solicita iniciar una transacción. El servidor responde con un identificador.
2. POST /api/transaction/validate-otp. El cliente envía el código OTP. El servidor responde { "valid": true }.
3. POST /api/transaction/confirm. El cliente envía los datos finales. El servidor procesa la transacción.

Si la petición de confirm no incluye el OTP ni un token de validación vinculado, el atacante puede ejecutar el paso 3 directamente, omitiendo el paso 2. La validación del OTP pasa a ser opcional.

Test mínimo

# Con Burp interceptando todas las peticiones de la app
1. Iniciar el flujo normalmente.
2. Ingresar cualquier valor en el campo OTP (incluso vacío).
3. Drop la petición /validate-otp en Burp.
4. Forward la petición /confirm sin modificar.
5. Verificar respuesta. Si retorna 200, OTP era cosmético.

Remediación correcta

El servidor debe emitir un token de un solo uso al validar el OTP, vinculado al usuario y a la operación específica. Solo peticiones que incluyan ese token pueden ejecutar la operación final. El token tiene expiración corta y se elimina al primer uso.

Implementación segura de referencia

# Backend · paso 2: validación de OTP
def validate_otp(person_uid, otp_code, operation_id):
    if not otp_matches(person_uid, otp_code):
        return error("OTP inválido")

    confirmation_token = generate_uuid()
    redis.setex(
        f"otp_confirmed:{confirmation_token}",
        300,  # 5 minutos
        json.dumps({
            "person_uid":   person_uid,
            "operation_id": operation_id,
            "validated_at": now()
        })
    )
    return {"confirmation_token": confirmation_token}

# Backend · paso 3: ejecución
def execute_operation(person_uid, confirmation_token, op_data):
    confirmation = redis.get(f"otp_confirmed:{confirmation_token}")
    if not confirmation:
        return error("Token inválido o expirado")

    data = json.loads(confirmation)
    if data["person_uid"] != person_uid:
        return error("Token no corresponde al usuario")
    if data["operation_id"] != op_data["operation_id"]:
        return error("Token no corresponde a la operación")

    redis.delete(f"otp_confirmed:{confirmation_token}")  # un solo uso
    process_operation(op_data)

Tres propiedades deben mantenerse: vinculación al usuario (un token de la víctima no puede usarse en sesión del atacante), vinculación a la operación específica (el token de una transferencia no puede confirmar otra) y uso único (el token se elimina tras la primera redención).

Variantes que también explotamos

• OTP devuelto en response body. El servidor envía el código por SMS pero también lo incluye en la respuesta JSON al cliente, supuestamente para que el frontend pueda validar antes de enviar al backend. Cualquiera con interceptación de tráfico ve el código sin acceso al teléfono.
• OTP predecible. Generación basada en timestamp con baja entropía. Un atacante con sincronización de reloj y conocimiento del algoritmo puede predecir códigos.
• OTP sin rate limiting. El servidor permite intentos ilimitados de validación. Brute-force trivial sobre 4 dígitos (10,000 combinaciones) en minutos.
• Reutilización del OTP entre flujos. El mismo código sirve para login, transferencia, cambio de contraseña. Un OTP capturado de un flujo permite ejecutar otro.
• OTP token estático. La aplicación genera un token de una sola vez al activar 2FA y nunca lo rota. Capturarlo una vez = bypass permanente.

Métricas observadas

En auditorías a aplicaciones móviles fintech con 2FA implementado, encontramos al menos un bypass del segundo factor en aproximadamente el 35% de los engagements. La variante más común es la falta de vinculación entre validación del OTP y la operación final; representa cerca del 60% de los casos detectados.

Mass Assignment y
Excessive Data Exposure.

Dos vulnerabilidades hermanas: Mass Assignment ocurre cuando el backend deserializa un body JSON directamente sobre un modelo de la base de datos, permitiendo al cliente sobrescribir campos que no deberían ser editables (rol, balance, flags administrativos). Excessive Data Exposure es el espejo: el backend serializa todo el modelo en la respuesta, exponiendo campos internos al cliente.

Mass Assignment en práctica

El endpoint PUT /api/users/profile acepta el body que el cliente envía y lo aplica al usuario autenticado. El frontend solo permite editar nombre, email y avatar. El backend, sin allowlist de campos, acepta cualquier propiedad incluyendo role: "admin" o credit_balance: 999999.

PUT /api/users/profile HTTP/1.1
Authorization: Bearer [valid-user-token]
Content-Type: application/json

{
  "name": "Usuario Normal",
  "email": "[email protected]",
  "role": "admin",
  "is_verified": true,
  "credit_balance": 999999
}

Si el endpoint responde 200 y los campos inyectados se persistieron, la vulnerabilidad existe. La detección manual exige conocer qué campos puede tener el modelo, lo cual se obtiene leyendo el código fuente, inspeccionando otros endpoints que devuelven el objeto completo, o experimentando con nombres comunes (role, admin, verified, tier, plan).

Excessive Data Exposure

El espejo: el endpoint GET /api/users/{id} devuelve el documento del usuario completo, incluyendo hash de password, tokens de sesión, internal IDs, flags de feature toggles, datos de billing y otra información que el frontend nunca usa pero que el ORM serializa por defecto.

El frontend ignora los campos extras al renderizar; un atacante haciendo curl al mismo endpoint los recibe en la respuesta JSON. Ataques que se construyen sobre esto incluyen reuso de tokens en otras sesiones, enumeración de roles internos, identificación de cuentas de alto valor para targeted attacks.

Remediación

• Allowlist explícita en deserialización. Definir un schema de input por endpoint que enumere exactamente qué campos se aceptan. Frameworks modernos (Pydantic, Joi, Zod) lo hacen trivial. Cualquier campo no declarado se descarta o produce 400.
• Allowlist explícita en serialización. Definir un schema de output que enumere qué campos se devuelven. No depender del default del ORM, que serializa todo.
• Separación de DTOs y modelos de DB. El objeto que sale por la API no es el modelo de la base de datos. Conversión explícita en cada endpoint.
• Tests de regresión por endpoint. Test que verifica que el endpoint NO devuelve campos sensibles (password_hash, internal_*, etc.) ante cualquier input. Falla CI si alguno aparece.

SSRF moderno con
bypass de allowlist.

Server-Side Request Forgery es la vulnerabilidad que permite al atacante hacer que el servidor ejecute peticiones HTTP a destinos elegidos por el atacante. En arquitecturas cloud modernas (AWS, GCP, Azure) el impacto se amplifica: el servidor tiene acceso a endpoints internos como el metadata service que expone credenciales temporales del rol IAM asociado a la instancia.

Vectores típicos

Cualquier endpoint que acepte una URL como input y haga una petición desde el servidor: webhooks, importación de imágenes desde URL, parsers de RSS, validadores de OG metadata, generadores de previews de links, integraciones de SSO basadas en metadata XML.

POST /api/import/image-from-url HTTP/1.1
Content-Type: application/json

{ "url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/" }

El servidor hace fetch a ese URL desde su propia red (donde el metadata service es accesible) y devuelve el contenido en la respuesta. El atacante recibe el listado de roles IAM. Una segunda petición al endpoint específico del rol devuelve AccessKeyId, SecretAccessKey y Token temporales.

Bypass de defensas comunes

Las defensas naive son fáciles de bypassear:

• Blocklist de IPs internas (169.254.*, 10.*, 192.168.*): se bypassea con DNS rebinding (un dominio que resuelve primero a una IP pública y al segundo intento a una interna), encoding decimal de IPs (2852039166), notación octal o hexadecimal.
• Allowlist de dominios: se bypassea si el parser de URLs del backend difiere del de la librería que ejecuta la petición. http://[email protected] es interpretado por algunos como host allowed.com, por otros como evil.com.
• Validación post-resolution: el backend resuelve el DNS, valida que la IP no sea privada, y luego ejecuta la petición. Atacante usa Time-of-Check Time-of-Use: el primer DNS resuelve público, el segundo (durante el fetch) resuelve privado.

Remediación efectiva

• Allowlist estricta de dominios validada con parser único usado tanto en validación como en la petición real. Eliminar cualquier ambigüedad.
• Resolución DNS controlada. Resolver el DNS una sola vez, validar la IP resultante contra una lista de bloqueo (rangos privados RFC 1918, link-local, multicast, IPv6 privado), y hacer la petición a esa IP específica con header Host apropiado.
• Sin redirecciones. Configurar el cliente HTTP para no seguir redirects, o seguirlos solo a dominios de la allowlist. Una redirección a 169.254.169.254 es vector clásico de SSRF.
• IMDSv2 obligatorio en AWS. El metadata service v2 exige token PUT antes de GET. El SSRF típico (solo GET) ya no funciona contra v2. Forzarlo a nivel de instancia.
• Network policies a nivel de VPC. Limitar las IPs y puertos a los que las instancias de aplicación pueden conectarse. El metadata service y servicios internos administrativos deben estar en una red separada.

Detección manual con Burp Collaborator

Para cada endpoint que acepta URL como input:

1. Capturar la petición original con un dominio legítimo.
2. Sustituir por un dominio de Collaborator.
3. Verificar si el servidor hizo la petición (ping al Collaborator).
4. Si responde, escalar a IPs internas, metadata service, dominios privados.
5. Documentar el rol IAM disponible si se accede a metadata.

Una sola interacción exitosa con Collaborator confirma SSRF. La extensión de impacto depende del entorno cloud y los permisos del rol IAM, que requieren enumeración adicional.

El denominador común.

Las siete vulnerabilidades documentadas comparten una estructura: existe una verificación implícita que el desarrollador asume está ocurriendo en otro lugar de la cadena. El frontend asume que el backend valida; el backend asume que el firewall filtra; el firewall asume que la red es confiable. Cuando el atacante rompe esa cadena de asunciones con un proxy, las defensas se desvanecen porque nunca estuvieron en el lugar donde el desarrollador creía.

Un escáner automatizado opera dentro de las mismas asunciones del desarrollador. Si la regla de validación no está codificada explícitamente en un patrón que la herramienta reconoce, no se reporta. La herramienta se vuelve cómplice involuntario del problema.

Lo que distingue una auditoría manual

El pentester con criterio asume que las defensas están donde el código las pone, no donde el desarrollador cree que están. Cada llamada a la API se trata como un input independiente, sin asumir que peticiones previas validaron nada. Cada respuesta se inspecciona buscando datos extras que no debería contener. Cada cambio de estado se cuestiona: ¿por qué el servidor permitió esto, y qué pasaría si lo intento dos veces?

Esta postura mental es la diferencia entre un escaneo automatizado y una auditoría manual. No es un truco; es una rutina disciplinada de cuestionamiento que se construye con años de experiencia ofensiva. Los hallazgos en este documento son ejemplos representativos del tipo de patrón que aparece cuando se ejecuta esa rutina con rigor.

Cómo aplicar lo aprendido

1. Auditar internamente con esta lista como checklist mínimo. Asignar a un ingeniero senior con tiempo dedicado, no como tarea adicional.
2. Implementar las remediaciones de cada categoría como controles arquitectónicos, no como fixes puntuales. Allowlist de campos, validación de Origin, vinculación de OTP: estos deben vivir en middleware o frameworks compartidos, no en cada endpoint.
3. Contratar una auditoría externa al menos una vez antes del lanzamiento de producción y luego anualmente. Un equipo interno que escribió el código tiene sesgos cognitivos sobre dónde están las debilidades.

Lectura recomendada.

Marcos y estándares

• OWASP API Security Top 10 (2023) · owasp.org/API-Security
• OWASP Application Security Verification Standard (ASVS) v4.0
• OWASP Web Security Testing Guide (WSTG) v4.2
• NIST SP 800-204 · Security Strategies for Microservices-based Application Systems
• CWE Top 25 Most Dangerous Software Weaknesses (2024)

Herramientas referenciadas

• Burp Suite Professional · Proxy de interceptación, Intruder, Repeater, Turbo Intruder
• jsluice · Extracción de endpoints y secretos en JavaScript
• trufflehog, gitleaks · Detección de secretos en código y artefactos
• Burp Collaborator, oastify · Listeners para SSRF y exfiltración
• jwt_tool · Forge y testing de tokens JWT
• arjun, paramspider · Discovery de parámetros ocultos

Lecturas técnicas profundas

• PortSwigger Web Security Academy · Labs de business logic, race conditions, SSRF
• HackerOne Hacktivity · Reportes públicos de bug bounty con detalle técnico
• Google Bughunter University · Casos de estudio con anatomía completa

Sobre la metodología de Daxonix

Este whitepaper es una destilación parcial de patrones recurrentes observados durante engagements reales en plataformas de producción a lo largo de más de ocho años de práctica ofensiva. La metodología completa se aplica en cada proyecto e incluye fases de reconocimiento, mapeo de superficie, descubrimiento, explotación y reporteo descritas en detalle en la propuesta técnica de cada engagement.

Cómo evaluamos
tu plataforma.

Fase 1 · Discovery

Conversación de 20 minutos con el equipo técnico para entender el alcance, la arquitectura, los flujos críticos y las restricciones (sistemas en producción que no admiten ciertos tipos de prueba). Salida: alcance escrito, fechas firmes, reglas de compromiso.

Fase 2 · Reconocimiento y mapping

Catálogo de la superficie de ataque: endpoints del API, archivos JavaScript del frontend, subdominios, servicios expuestos a internet. Identificación de patrones de autenticación, sesiones, validación de input. Salida: documento de superficie con cobertura completa.

Fase 3 · Explotación manual

Auditoría endpoint por endpoint con la metodología descrita en este whitepaper como base mínima. Cada hallazgo se documenta con prueba de concepto reproducible (request HTTP completo, captura de pantalla, video cuando aplica). Comunicación diaria por Slack o Teams con el equipo técnico del cliente.

Fase 4 · Reporte y walkthrough

Reporte ejecutivo (1-2 páginas) para dirección y reporte técnico detallado para el equipo de desarrollo. Cada hallazgo incluye severidad CVSS, impacto de negocio, prueba de concepto reproducible y guía de remediación específica al stack del cliente. Sesión de walkthrough en vivo con el equipo técnico.

Fase 5 · Re-test sin costo

Cuando el equipo del cliente termina las remediaciones, validamos cada hallazgo cerrado y emitimos un addendum al reporte. Sin costo adicional dentro de los primeros 90 días.