Pentest de APIs REST y GraphQL: Checklist Tecnico para Bug Bounty Legal

Las APIs se convirtieron en el punto mas lucrativo de cualquier programa de bug bounty serio, y tambien el mas descuidado por pentesters que siguen obsesionados con XSS en el formulario de contacto. Un IDOR en /api/v3/users/{id}/invoices puede pagar entre tres y ocho mil dolares en HackerOne, mientras que un XSS reflejado en una pagina de marketing cierra en 250. El equipo Basilisk OffSec compilo en este checklist el flujo exacto que usamos en engagements autorizados y en programas publicos como GitLab, Shopify y Reddit. Antes de cualquier cosa: lee el alcance, confirma el brand domain y nunca toques endpoints fuera de la lista. Todo aqui presupone autorizacion escrita, y todo se enmarca en el OWASP API Security Top 10 (2023).

Autorizacion y alcance primero, siempre

Antes de que arranque cualquier herramienta, solo existe una pregunta: tengo permiso de tocar esto. Bug bounty sin confirmar alcance no es un pentest, es un incidente. Lee el documento de politica, anota los dominios en alcance, los endpoints excluidos explicitamente (a menudo /admin o flujos de pago) y las tecnicas prohibidas (casi siempre DoS e ingenieria social). Registra la fecha, la version del programa y tu cuenta de prueba. Esta disciplina no es burocracia, es la diferencia entre una bounty pagada y una denuncia. Bug bounty legal es disciplina antes que creatividad.

Mapea la superficie antes de disparar un payload

El punto de partida nunca es Burp abierto en la cara. Es el mapeo de superficie. Toma la app movil con apktool, extrae strings de URL y cargalas en Burp como sitemap manual. Usa ffuf con la wordlist api-endpoints-res.txt de SecLists contra paths como /api/, /v1/, /internal/, /graphql, /gql, /query. Wayback Machine via gau y waybackurls revela endpoints obsoletos que nadie parcheo. En un engagement reciente encontramos un /api/v1/admin/export heredado de 2019 que aceptaba token de usuario comun, similar a lo que describimos en Pentest Web desde Cero: Montando un Lab Seguro con DVWA, Juice Shop y Burp Suite. Documenta cada endpoint con metodo, content-type esperado y rol necesario antes de probar payloads.

IDOR/BOLA: el bug mas caro en REST

IDOR sigue siendo el bug numero uno en APIs REST por una razon simple: los devs confian en el ID del JWT pero leen el ID de la URL. Crea dos cuentas en la app objetivo, captura ambas sesiones en Burp y usa la extension Autorize o Auth Analyzer para reenviar cada request de la cuenta A con la cookie de la cuenta B. Presta atencion a respuestas 200 con cuerpo distinto, no solo a status codes. UUIDs no son proteccion: enumeralos via busqueda, exports CSV o notificaciones. Prueba tambien el lado de escritura: PUT y DELETE con ID ajeno, porque IDOR de lectura es info disclosure pero IDOR de escritura es account takeover.

La logica de inyeccion tambien aplica en APIs, como mostramos en SQL Injection en la Practica: Explotar, Detectar y Mitigar en Lab Controlado, sobre todo en filtros sort, order y search que terminan en concat SQL. Un ?sort=name)-- o un delay booleano en el cuerpo JSON suele revelar que el parametro entra sin proteccion en la query. Nunca reportes una SQLi sin una prueba reproducible y no destructiva (sin DROP, sin UPDATE), solo extraccion de un valor inofensivo como la version de la DB.

GraphQL cambia el juego

GraphQL cambia el juego. Empieza probando introspeccion en /graphql con la query {__schema{types{name fields{name}}}}. Si esta abierta en produccion, ya tienes media bounty escrita. Herramientas como InQL, GraphQL Voyager y clairvoyance reconstruyen schemas incluso con introspeccion deshabilitada via field stuffing. Busca mutations expuestas como adminUpdateUser, impersonate, exportAllData. Las batch queries permiten bypass de rate limit: envia 1000 mutations login en una sola request HTTP. El alias overloading rompe validadores ingenuos. A diferencia de lo cubierto en XSS Moderno: DOM, Stored y Reflected con Ejemplos Reales en Entorno de Pruebas, aqui el impacto es casi siempre logico, no inyeccion de script.

El bypass de auth va mas alla del none algorithm

El bypass de autenticacion en este contexto va mas alla del clasico none algorithm en JWT. Prueba jku y kid injection, cambio de RS256 a HS256 usando la publica como secreto, y refresh tokens que nunca expiran. Headers como X-Original-URL, X-Rewrite-URL, X-Forwarded-For y X-User-Id suelen bypassar middlewares de auth cuando la API esta detras de un gateway mal configurado. En GraphQL verifica que la directive @auth cubra todos los campos o si algun resolver anidado filtra datos sin chequeo. Prueba tambien la logica de expiracion: un token revocado que sigue aceptandose tras logout es un reporte limpio y bien pagado.

SSRF, mass assignment y business logic

SSRF tambien aparece en APIs que aceptan URL como parametro para webhooks o avatares, patron que detallamos en SSRF sin Complicaciones: Explotando Cloud Metadata en Lab AWS Local con exploits contra IMDS de AWS. Para mass assignment agrega campos como isAdmin:true, role:owner, verified:true en cualquier PATCH o PUT; frameworks como Rails y NestJS con whitelist incompleta sirven admin en bandeja. La business logic es la clase que los escaneres nunca encuentran: cantidades negativas, cambio de moneda entre el calculo de precio y el cobro, aplicacion doble de cupon. Estos bugs exigen que entiendas el flujo de negocio, no solo el protocolo.

Rate limiting y race conditions

El rate limiting, bien probado, rara vez es bounty por si solo, pero es el multiplicador de otros bugs: si falta en el endpoint de OTP o login, un codigo de 6 digitos se bruteforcea en minutos. Para race conditions en endpoints de cupon o retiro, usa Turbo Intruder con single packet attack de James Kettle, mandando 30 requests simultaneas; si un cupon de 50 dolares se canjea cinco veces, tienes reporte de impacto financiero. Combina race con business logic: el clasico doble retiro donde el chequeo de saldo y el debito no son atomicos.

Subida de archivos, deserializacion y parametros ocultos

Dos clases de bug suelen quedar sin probar en tests de API y pagan bien. Primero, subida de archivos: prueba cada endpoint de upload por content-type confusion (un payload PHP o SVG declarado como image/png), path traversal en el nombre (../../avatar.php), falta de validacion de tamano y MIME, y, cuando hay procesamiento de imagen del lado servidor, cadenas de ImageMagick o ffmpeg que llevan a RCE o SSRF. Segundo, deserializacion: APIs que aceptan objetos serializados en cookies, headers o cuerpos (Java, .NET, PHP, pickle de Python, Marshal de Ruby) son un camino directo a RCE si existe una gadget chain. Busca bloques base64 que empiezan con magic bytes conocidos (rO0 para Java, ac ed en hex). Suma parameter mining con Arjun o param-miner: muchas APIs procesan campos no documentados como debug=true, preview o internal que nunca aparecen en la doc oficial y saltan chequeos de autorizacion. Las tres clases exigen un PoC limpio y no destructivo, y solo caben en objetivos autorizados.

Reporting: por que se paga el impacto, no la tecnica

Documenta impacto con numero de registros expuestos, valor financiero estimado y PoC reproducible en curl. Los programas pagan por impacto demostrado, no por tecnica. Arma una plantilla de reporte con titulo CWE, pasos numerados, request crudo, response truncada y sugerencia de fix en una linea. Envia temprano, antes de los duplicados, pero nunca sin confirmar alcance. Un reporte limpio y conciso con impacto claro se paga mas rapido y mas alto que un muro de texto lleno de escenarios especulativos.

Checklist practico

(1) alcance y autorizacion confirmados por escrito. (2) superficie mapeada completa (movil, Wayback, ffuf). (3) IDOR/BOLA lectura y escritura con dos cuentas. (4) GraphQL introspeccion, batch, alias, mutations expuestas. (5) JWT: alg confusion, kid/jku, expiracion, revocacion tras logout. (6) mass assignment en cada endpoint de escritura. (7) SSRF en cada parametro URL. (8) rate limit en flujos de auth y race en flujos de dinero. (9) business logic contra el flujo real. (10) reporte con impacto, PoC y fix.

FAQ: Con que deberia empezar un principiante?

Con IDOR/BOLA. Es el bug mas comun, mas facil de probar y bien pagado, y solo necesita dos cuentas de prueba y Burp con Autorize. Construye intuicion primero en tu propio lab, como nuestro setup DVWA/Juice Shop, antes de tocar un programa real. Una vez que encuentras IDOR de forma confiable, expande hacia GraphQL y malas configuraciones de JWT, tecnicamente relacionadas y que suelen aparecer juntas en APIs modernas.

FAQ: Como evito romper el alcance sin querer?

Configura Burp con un target scope estricto y activa "Drop out-of-scope requests" para que ninguna herramienta golpee hosts ajenos por accidente. Evita escaneres activos automatizados si la politica no los permite, y nunca dispares ataques de alto volumen (pueden contar como DoS). Ante la duda, pregunta al programa por el canal oficial antes de probar. El error mas caro no es un bug perdido, sino un test fuera de la autorizacion.

Conclusion

Bug bounty legal es disciplina antes que creatividad, y en esa disciplina Basilisk construye reputacion en programas como Mercado Libre y Nubank. El flujo es reproducible: alcance, mapeo, pase sistematico por las clases de bug de API, reporte de impacto limpio. Quien interioriza este proceso encuentra mas y mejores bugs que quien lanza payloads a ciegas, y lo hace dentro de las reglas, que a largo plazo es el unico camino que paga.