Bug bounty en e-commerce: de IDOR y XSS a vulnerabilidades de IA

El bug bounty en e-commerce tiene un laboratorio perfecto: plataformas con millones de usuarios, decenas de features, APIs, bots de soporte y flujos logísticos que van del carrito hasta el courier. En la DragonJARCON 2026, Adrián Pedrazzoli comprimió en una charla cinco años de caza sobre un mismo objetivo —un e-commerce de la región— con más de un centenar de reportes que van de un XSS de los primeros años hasta tomar el WhatsApp de la empresa.

La charla "5 Years in 45 Minutes: Breaking E-Commerce, One Bug at a Time" recorre esa evolución temporada por temporada: Information Disclosure, IDORs en cadena, cookies de impersonación, SSRF hacia la nube, race conditions y la nueva superficie de los chatbots y los MCP Servers. Esta es la síntesis técnica con sus lecciones para cualquier bug hunter o equipo de AppSec.

Pentesting y bug bounty: vender riesgo, no trabajo

En un pentest, la empresa define un scope, se acuerda un paquete de horas y al final se cobra sí o sí: hasta un hallazgo informativo entra en el reporte, porque es parte del trabajo. En bug bounty el contrato es otro: "no nos pagan por el trabajo, nos pagan por el riesgo". El reporte debe superar el filtro del duplicado, el de validez y la calculadora de severidad (low, medium, high, critical), compitiendo contra los 100.000 o 150.000 usuarios activos que, según la charla, cazan en HackerOne.

Por eso los informativos duelen: reportes que uno cree válidos y que la empresa cierra argumentando que no generan riesgo. En pentesting se reportan igual; en bug bounty, no pagan.

2022: el primer crítico, acceso a PII sin autenticación

La temporada dejó 7 reportes válidos y 7 informativos, y el hallazgo destacado fue un Access to PII en el Brand Protection Program de la plataforma: un endpoint donde "vos ponías una letra y el tipo te devolvía todos los registros que contenían esa letra". Ese programa lo integraban marcas grandes, como Adidas, y el response hablaba de unos 25.700 registros: 25.000 empresas, no usuarios comunes.

El hallazgo nació de un fuzzing de parámetros con Arjun: un parámetro básico llamado name, y un response que revelaba paging, offset y limit. Al subir el limit a 60, el endpoint devolvió todo el bloque de una vez. Primer tip: "Hay que prestar atención al response." La falta de autenticación fue clave: probado en un navegador anónimo seguía funcionando, y en el CVSS eso empuja el riesgo hacia arriba.

El fix es el próximo bug

El hunter es el primero en enterarse de que su reporte fue corregido, así que hay que volver a revisar: a veces el cierre es administrativo y la falla sigue viva. Al volver a la URL, la respuesta seguía filtrando señales: con su usuario, una llave; con un valor inexistente, null. Sobre esa diferencia, y con la ayuda de un amigo, armó un script que reconstruía los datos carácter a carácter sin verlos: "No hace falta ver el dato para extraerlo." El bypass fue aceptado, aunque el triage lo bajó a medium: la complejidad del ataque también reduce el riesgo, porque exfiltrar todo exigía fuzzear de forma continua. Como resume el ponente: "Es el próximo bug el fix."

2023: comprar productos para desbloquear superficie nueva

El año cerró con 14 reportes, 10 informativos y 3 duplicados, pero con un cambio de método: si las funciones del programa de revendedores estaban bloqueadas, había que desbloquearlas como un usuario real. Comprando productos, la cuenta escaló de aprendiz a emprendedor y cada nivel habilitaba features nuevas en el panel. La frase que lo resume: "cada feature es superficie nueva".

El primer crítico fue un IDOR de manual: un endpoint devolvía nombre completo, teléfono, direcciones, código postal y geolocalización, con un ID secuencial recorrible hacia arriba y hacia abajo: millones de usuarios de toda la región. Más interesante fue el chain de tres fallas menores: generar un link de invitación del feature de grupos de revendedores, lograr que la víctima lo abriera con un clic y quedar asignado como líder de su grupo. Con ese rol, el panel mostraba la PII de todos los miembros que accedieran al link.

Y la lección amarga llegó con la academia interna de revendedores: links con contenido instructivo, de libre acceso, hosteados en el dominio principal del e-commerce, que cualquiera podía editar. Fueron cinco reportes y la empresa los consolidó en uno por Same Root Cause: permisos mal configurados, un único fix. Los rechazos también afectan la reputación: reportar, esperar el fix y recién ahí volver a atacar.

2024: leer los bundlers y la cookie para impersonarlos a todos

En 2024 los números hablan solos: 10 reportes (5 informativos, 2 duplicados) con 3 critical y 1 high: "menos reportes, más impacto". El cambio: dejar de mirar el front y leer el JavaScript de atrás. Los bundlers —el de esta plataforma es Webpack— empaquetan, minifican y versionan el código, y dejan rastros como los main.js con hash o los source maps. En palabras del ponente: "Eso es oro." Adentro hay endpoints no documentados, roles, comentarios de desarrolladores, PII, tokens y secrets.

PII Disclosure vía Improper Cookie Management

El hallazgo estrella llegó al doble clic: dentro del webpack había una referencia a impersonation. Con una cookie armada con el end user, el ID de usuario y el site ID del país, inyectada en la request de Burp Suite, el propio panel respondía con un cartel advirtiendo que se estaba impersonando. Permitía consultar la información de cualquier cliente de cualquier país: cross-country, millones de usuarios. Todo por "una cookie de management que dejaron olvidada en el bundler".

SSRF en el generador de PDFs: del beneficiario a las credenciales de AWS

Comprando un seguro de vida en la plataforma, el flujo termina generando el PDF de la póliza con los beneficiarios. El campo del nombre no validaba: una HTML Injection simple que, renderizada en el PDF, aceptó un iframe apuntando a la dirección interna de Amazon Web Services. Desde esa zona de confianza del backend se veían metadata, credenciales y clusters. Reportó de inmediato, le pagaron en el acto y el fix combinó input validation con la actualización del PDF Viewer. Su advertencia: "podés pasar un RCE y terminaste baneado del programa por hacerte canchero".

IDOR en el flujo de reparación: bloquear terminales ajenas

Los productos comprados tenían un flujo de reparación con números de serie consecutivos: otro IDOR. Recorriendo seriales se veían Customer ID, Shipment ID e historial, y se podía cambiar el estado del equipo y bloquearlo, lo que dispara una devolución con reemplazo a domicilio. Bloqueó el serial de una terminal ajena y el reemplazo llegó a su casa sin pagar nada; después avisó a la empresa. Seriales de Argentina, Brasil, México y otro país más. Mientras el identificador sea predecible, la seguridad por oscuridad no alcanza.

Secondary context: romper la URL para que el backend cuente

El secondary context —concepto que Adrián asocia a Sam Curry— describe lo que pasa detrás de una URL simple: el backend toma tu input y arma otro request con lo que saca de tu sesión. Forzando errores —el backend respondía que faltaba el customer ID, o el service order ID— reconstruyó la forma real del request interno. Con un %23 (el hashtag URL-encoded) para comentar el resto del path e inyectar su propio customer ID, veía el PDF de otra persona: hasta 3 millones de usuarios exfiltrables. El tip: estar atento a los errores; cada detalle revela cómo arma el request el backend.

2025: Open Graph, wiki interna y una race condition de 21 paquetes

La temporada dejó 22 bugs (6 informativos, 4 duplicados) manteniendo el nivel: 3 critical y 1 high.

Escalar un SSRF con Open Graph hasta la Wikipedia interna

La plataforma tenía su chat de soporte con IA. Mientras todos buscaban prompt injection, Adrián notó que renderizaba URLs usando los tags de Open Graph (og:title, og:image, og:description): los que generan la preview al compartir un link por WhatsApp. Con una página propia en ngrok y sus tags OG confirmó el render; escaneando, encontró la wiki interna de la empresa. No podía navegarla... hasta recordar el feature Special:Random de los wikis (el equivalente del "voy a tener suerte"): cada request traía una página distinta —onboarding, proyectos, data sensible—. Lo que iba a ser un SSRF medium de 500 dólares terminó en high.

Su conclusión: "Ahí no falló la AI. Estamos hablando de la API", de la confianza entre el backend y lo que el usuario pone adelante. Superficie nueva, fallas de siempre: "Prompt Injection, fuga de System Prompt, alucinaciones. No nos olvidemos de lo viejo."

Race condition: 21 devoluciones con el mismo número de serie

El bug más material nació de una pregunta casual de un amigo: si nunca había hackeado algo para conseguir productos gratis. Con el mate en la mesa y el Turbo Intruder de Burp Suite Pro, probó el endpoint de devoluciones: unas 10 líneas de Python con concurrencia y un range de 10 lanzaron 21 requests casi simultáneos con el mismo número de serie. El sistema procesó los 21: llegaron los 21 mails de "Tu pedido está en preparación" y el cartero apareció con los 21 dispositivos. Reportó de inmediato. La lección humana: "desconectar es método, así que téngalo en cuenta". A veces el mejor payload aparece en un descanso.

2026: la era de la IA y 51 bugs en tres meses

En 2026 el contador marca 51 bugs en tres meses: cross-country, superficie de IA, credenciales expuestas y su primera incursión en hardware. Tres casos destacan.

Account takeover de un POS físico vía su chat de IA

Un terminal de pago con un chat de IA integrado. Sin saber de hardware, Adrián le pidió que le armara en Markdown los links de navegación del perfil de la cuenta, y el bot los renderizó. Con un payload a medida pudo cerrar la sesión, salir del sandbox escaneando un QR con su celular y linkear su propia cuenta: account takeover. Su resumen: "los tipos se olvidaron de segurizar la AI" — y con ella, la API de atrás.

Takeover del WhatsApp de la empresa

De la superficie de IA salió también el acceso a la API que manejaba los eventos del WhatsApp corporativo (los SSE): llegaban los mensajes de todas las comunicaciones. Analizando el JS minificado encontró templates en portugués con el user ID de una persona de soporte, y con eso, formas de inyectar: podía escribir desde el WhatsApp de la empresa a cualquier teléfono de cualquier país. La síntesis: "Si podés escribir un canal, el canal es tuyo."

SSRF en un MCP Server con parámetro no documentado

El último caso grande fue contra un MCP Server: leyó la documentación completa, encontró un parámetro no documentado asociado a simular webhooks (donde hay webhook, hay potencial SSRF) y chocó con el guardián: 127.0.0.1 devolvía 403. El bypass llegó con nip.io, que resuelve cualquier subdominio a la IP que quieras: esa suerte de DNS rebinding saltaba la regex floja de la blacklist, respondía 200 y desde ahí pudo hacer port scan interno. Encontró cinco puertos abiertos —entre ellos 5000, 8080, 15000 y 15600—, un envoy y debug bars en el 8080. Como requería autenticación, la severidad quedó contenida.

El rol real de la IA: contexto, no automatización

¿51 bugs en tres meses? "No automaticé el hunting", aclara. Le dio a la IA todo su contexto —qué no hacer para no chocar contra el WAF, qué buscar— porque esos cinco años también son un manual de errores que evitar: "no es hackeame esto, es yo te doy el contexto". Para los reportes: nada de 200 hojas; severidad, impacto y una PoC clara. Y en las preguntas advirtió que automatizar reportes con IA termina en baneos de plataforma.

Preguntas frecuentes

¿Qué diferencia hay entre pentesting en e-commerce y bug bounty en e-commerce?

En pentesting se cobra por tiempo y scope, y los informativos se reportan igual. En bug bounty se cobra por riesgo: el reporte debe demostrar impacto real, superar duplicados y la severidad del triage.

¿Qué es el Same Root Cause en bug bounty?

Es el criterio por el cual una empresa consolida varios reportes en uno cuando comparten la misma causa raíz —por ejemplo, permisos mal configurados—. En la charla, cinco reportes terminaron pagados como uno. Conviene reportar, esperar el fix y volver a atacar.

¿Por qué conviene leer los bundlers y los source maps?

Porque el código empaquetado expone endpoints no documentados, roles, comentarios, tokens y secrets. En la charla, leer el webpack reveló una cookie de impersonación olvidada que daba acceso a clientes de cualquier país.

¿Cómo se ataca un chatbot de IA sin quedarse en el prompt injection?

Mirando lo que hay detrás: APIs, requests internos y la confianza entre backend y front. El chat renderizaba URLs con tags de Open Graph; escalar ese fetch hacia la wiki interna con Special:Random convirtió un SSRF medium en high. Superficie nueva, fallas viejas.

¿Vale la pena automatizar el hunting o los reportes con IA?

No. El ponente dio contexto a la IA en lugar de automatizar la caza, y escribe reportes cortos con severidad, impacto y PoC clara. Automatizar reportes suele terminar en sanciones de las plataformas.

¿Cómo se maneja el estrés de discutir severidades con el triage?

Con paciencia y comunicación: al quedarse años en un programa, el hunter conoce cómo trabaja cada triager. Ante la tentación del mercado negro: "A pesar del estrés que tenemos, yo duermo tranquilo, reporto." Empezó a los 15 años y hoy valora el marco legal que le permite reportar, cobrar y ser reconocido.

Conclusiones

Cinco años sobre un solo objetivo dejaron un inventario único: PII de más de 150 millones de usuarios expuesta en reiteradas ocasiones, impersonación de usuarios y comercios, acceso a infraestructura interna, takeover del WhatsApp de la empresa, bypass del WAF, productos gratis por race condition y escape del sandbox de un POS físico. Tres certezas quedan. El método manda: comprar productos para desbloquear features, leer el response, romper URLs; el hallazgo casi nunca es suerte. Los bugs simples escalan: un parámetro name, una cookie olvidada, un campo de beneficiario; el impacto se construye encadenándolos. Y la IA no cambió el juego: lo ampliaron las APIs detrás, porque "hay que atacar al modelo, pero no se olvide de la API".

Para seguir aprendiendo sobre seguridad ofensiva a partir de casos reales, regístrate en https://www.dragonjarcon.org. Allí podrás acceder a charlas como la que acabas de leer y conocer más sobre DragonJARCON, el congreso anual que reúne en Colombia a profesionales e investigadores de la seguridad informática.

Y si tu organización necesita este mismo nivel de análisis y escrutinio, conoce los servicios de seguridad ofensiva de DragonJAR en https://www.dragonjar.org/servicios-de-seguridad-informatica.

Mira la Charla Completa Sobre cómo romper un e-commerce, un bug a la vez