Cómo usar IA y JavaScript para mejorar el Pentesting y Bug Bounty

bycreadpag -

Importante (legalidad y buenas prácticas): Esta guía es 100% educativa y está pensada para pentesting autorizado, laboratorios y programas oficiales de bug bounty. 


No realices pruebas en sistemas sin permiso. Además, respeta siempre el scope, límites de tasa (rate limits) y reglas del programa.

En esta entrada vas a aprender un método moderno para:

  • Extraer y analizar JavaScript (JS) del front-end
  • Mapear endpoints ocultos (API/AJAX/fetch/XHR/WebSocket)
  • Usar IA para acelerar el análisis y organizar hallazgos
  • Convertir llamadas del JS en requests listos para BurpSuite
  • Entender por qué a veces wget devuelve 503 y qué hacer en entornos permitidos

Ejemplo práctico: Usaremos un escenario tipo “ecommerce estilo Amazon” (sin atacar ni automatizar contra Amazon real). La idea es que puedas aplicar el proceso en tu objetivo autorizado.

1) ¿Por qué el JavaScript es oro en Bug Bounty?

En aplicaciones web modernas, gran parte de la lógica del cliente vive en JavaScript. Y si una funcionalidad existe, el front-end necesita saber:

  • Qué endpoint llamar
  • Qué parámetros enviar
  • Qué headers usar
  • Cómo manejar respuestas

Por eso, el JS suele “filtrar” información útil para investigación de seguridad, como rutas internas, APIs, endpoints legacy, toggles de features y flujos de cuenta (perfil, notificaciones, pedidos, etc.).

2) Método principal: Mapea endpoints ocultos desde el JS

La idea es buscar patrones típicos dentro de bundles y scripts:

  • fetch("/api/..."
  • $.ajax({ url: "/..."
  • XMLHttpRequest
  • axios.get/post
  • new WebSocket("wss://...")
  • Imports dinámicos: import("/chunks/...")

Resultado esperado: una lista de endpoints y sus parámetros. Luego podrás reconstruir requests para pruebas controladas en BurpSuite (solo dentro del scope).

3) Recolectar JavaScript (métodos que usan investigadores)

Hay varias formas de reunir JavaScript en un objetivo autorizado. Los expertos suelen combinar métodos para no depender de uno solo.

3.1) Método A: Desde el navegador (rápido y limpio)

  • Abre DevTools → pestaña Network → filtra por JS.
  • Recarga la página y guarda URLs de scripts (bundles, chunks, vendors).
  • Opcional: DevTools → Sources para ver y guardar el contenido.

3.2) Método B: Interceptando tráfico (BurpSuite / Proxy)

  • Configura el navegador con proxy (Burp/ZAP)
  • Navega las secciones importantes (cuenta, settings, checkout, etc.)
  • Identifica llamadas fetch/AJAX y los archivos JS que las generan

3.3) Método C: Descarga recursiva (solo si está permitido)

Algunos sitios bloquean automatización, y es normal. Si tu target permite crawling, puedes usar wget con cautela:

wget -e robots=off \
  --recursive --level=2 --no-parent \
  --wait=1 --random-wait \
  --user-agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64)" \
  https://target-autorizado.com/

Tip: Si tu objetivo devuelve 503, normalmente es protección anti-bot o rate limit (ver sección 8). No intentes “saltarte” protecciones. Si el programa no permite crawling, quédate con métodos pasivos (navegador, proxy, histórico público).

3.4) Método D: Recon pasivo (histórico público)

En objetivos autorizados, el recon pasivo ayuda a encontrar JS viejo/olvidado:

  • URLs históricas (archivos públicos antiguos)
  • Bundles antiguos que aún revelan rutas

4) IA como copiloto: cómo analizar JS sin morir en el intento

Los bundles modernos pueden tener miles o millones de caracteres. La IA ayuda a:

  • Extraer endpoints automáticamente
  • Agrupar por áreas: cuenta, pagos, pedidos, notificaciones
  • Detectar parámetros importantes (IDs, flags, estados)
  • Entender flujos (qué se llama antes y después)

Regla pro: La IA te guía, pero tú validas manualmente. En bug bounty, lo que cuenta es evidencia reproducible y dentro de reglas.

5) Prompts “pro” (los que se parecen al estilo de trabajo experto)

Copia y pega estos prompts junto con el JS o fragmentos relevantes. Están pensados para que la IA te devuelva información accionable, sin inventar vulnerabilidades.

5.1) Prompt: Extraer endpoints y parámetros desde JS

Actúa como investigador de seguridad (bug bounty) en un entorno autorizado.

Te paso uno o varios archivos JavaScript. Extrae TODOS los endpoints:
- fetch, XHR, $.ajax, axios, WebSocket, import dinámico.

Para cada endpoint devuelve:
1) Método HTTP
2) Ruta (path)
3) Parámetros/cuerpo (keys)
4) Headers relevantes si aparecen
5) Contexto: nombre de función/módulo donde se usa

Devuélvelo en tabla y NO inventes endpoints.

5.2) Prompt: Clasificar endpoints por prioridad

Te paso una lista de endpoints. Clasifícalos por prioridad para pruebas de seguridad dentro de bug bounty:

Alta: auth, account, settings sensibles, pagos, roles
Media: notificaciones, preferencias, historial
Baja: contenido público o estático

Para cada endpoint:
- Prioridad (Alta/Media/Baja)
- Tipo (lectura/escritura)
- Ideas de pruebas permitidas (CSRF, autorización, validación de entrada, lógica de negocio), sin explotar.

5.3) Prompt: Convertir JS a request para BurpSuite

Te doy fragmentos JS con llamadas (fetch/ajax). Conviértelos a requests HTTP crudos listos para BurpSuite Repeater:

Incluye:
- Método y path
- Host como: target-autorizado.com
- Content-Type correcto
- Cookie placeholder: SESSION=SESION_AQUI
- Body con parámetros
Marca parámetros interesantes (IDs, flags, status).

No inventes cookies reales.

5.4) Prompt: Redactar reporte bug bounty profesional

Actúa como triager. Te describo un hallazgo potencial y evidencia. Reescribe un reporte con:

- Título
- Resumen
- Impacto (claro y realista)
- Pasos para reproducir
- Evidencia (request/response)
- Recomendación técnica

Tono profesional, sin exageraciones.

6) Del JavaScript a BurpSuite: construir requests con parámetros

Cuando localizas llamadas como fetch, $.ajax, etc., normalmente verás:

  • URL / endpoint
  • Método (GET/POST...)
  • Parámetros (query, form o JSON)
  • Tokens (CSRF o similares)

Ejemplo (escenario tipo ecommerce “Amazon-like”): preferencia de notificaciones por email.

$.ajax({
  url: "/account/email-notifications/preference",
  method: "POST",
  data: {
    id: 8,
    emailPreferenceStatus: true,
    csrfToken: "TOKEN"
  }
});

Convertido a un request “Burp-friendly” (con placeholders):

POST /account/email-notifications/preference HTTP/1.1
Host: target-autorizado.com
Content-Type: application/x-www-form-urlencoded
Cookie: SESSION=SESION_AQUI

id=8&emailPreferenceStatus=true&csrfToken=TOKEN_AQUI

Otro ejemplo: endpoint de settings (pausar/activar una preferencia), típico en apps modernas:

POST /account/settings/pause HTTP/1.1
Host: target-autorizado.com
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Cookie: SESSION=SESION_AQUI

csrfToken=TOKEN_AQUI&isEnabled=true

¿Qué se prueba aquí (sin explotar)? En un bug bounty autorizado, se suelen revisar aspectos como:

  • ¿Valida correctamente el token CSRF?
  • ¿Requiere autenticación real?
  • ¿Los parámetros aceptan valores inesperados?
  • ¿La autorización corresponde al usuario correcto?

7) Qué buscar (enfoque seguro y compatible con AdSense)

En investigación ética, el objetivo es identificar fallos y reportarlos responsablemente. Ejemplos de áreas de análisis:

  • Autorización: ¿un usuario puede acceder a funciones que no le corresponden?
  • Validación: ¿se validan correctamente datos de entrada y estados?
  • CSRF: ¿los cambios sensibles exigen protección real?
  • Lógica de negocio: ¿hay estados inconsistentes (activar/desactivar) que rompen reglas?
  • Exposición innecesaria: endpoints antiguos/legacy aún accesibles

Importante: evita pruebas destructivas o fuera del alcance. Si algo es sensible (pagos, pedidos reales, datos personales), sigue estrictamente las reglas del programa.

8) El 503 con wget: por qué ocurre y qué hacer en targets permitidos

Si ejecutas un comando como:

sudo wget -r --level=2 --no-parent https://www.algun-sitio.com/

y recibes 503, lo más común es:

  • Protección anti-bot / anti-scraping
  • Rate limiting (demasiadas solicitudes en poco tiempo)
  • Necesidad de cookies/sesión generadas por JavaScript

Buenas prácticas (solo si el target lo permite):

  • Usa un User-Agent de navegador
  • Reduce velocidad con --wait y --random-wait
  • No intentes evadir protecciones del sitio

Ejemplo de comando “más amable” para targets autorizados:

wget -e robots=off \
  --recursive --level=2 --no-parent \
  --wait=1 --random-wait \
  --user-agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64)" \
  https://target-autorizado.com/

Si el sitio sigue devolviendo 503: asume que el crawling automatizado no está permitido o está bloqueado. En ese caso, usa métodos pasivos: navegador + proxy + análisis manual + histórico público.

9) Checklist rápido del flujo completo (para bug bounty real)

  1. Confirma scope del programa y reglas (muy importante).
  2. Recolecta JS con DevTools y/o proxy.
  3. Analiza con IA: endpoints + parámetros + clasificación.
  4. Reconstruye requests en BurpSuite Repeater.
  5. Realiza pruebas no destructivas y documenta evidencia.
  6. Redacta reporte claro y profesional (puedes usar IA para mejorarlo).

10) Conclusión

La combinación de IA + análisis de JavaScript se ha convertido en una de las estrategias más efectivas para investigación de seguridad moderna. Te permite entender el “mapa real” de una aplicación web y encontrar superficies de ataque que normalmente pasan desapercibidas.

Pero lo más importante es la ética: los mejores bug bounty hunters trabajan con permiso, respetan el scope y reportan responsablemente.

Tags:

You might like

Ver todo
Artículo Anterior Artículo Siguiente
Compartir en otras aplicaciones
Copiar Enlace de la entrada