Bug Bounty: así consiguen premium gratis en una app

Sí, hay apps de pago que pueden perder ingresos porque su servidor confía demasiado en lo que le envía el navegador. En el canal Gorka El Bochi Morillo | Hacking & Bug Bounty, dentro de nuestra lista «Lo mejor de Así de Fácil», Gorka muestra sobre una aplicación de pruebas cuatro fallos de lógica de negocio (Mass Assignment, manipulación de la respuesta, sobreexposición de datos por API y una Race Condition en cupones) capaces de convertir una cuenta gratuita en premium. Los cuatro están documentados como categorías reales del OWASP API Security Top 10 y han costado dinero de verdad a empresas como Instacart. Te explicamos cada uno, con ejemplos reales y el código exacto para blindarlos si tienes o desarrollas una app con planes de pago.

Cuatro formas en que una app de pago puede quedarse sin defensas

Todas las apps con un plan gratuito y otro premium comparten el mismo reto técnico: en algún punto, el servidor tiene que decidir si el usuario que hace la petición tiene o no derecho a esa función. Cuando esa comprobación falla o está mal colocada, aparecen fallos de lógica de negocio: no rompen la aplicación ni lanzan un error, son puertas que se quedan abiertas porque nadie pensó en cerrarlas con llave. Los cuatro que repasa Gorka en el vídeo, usando Burp Suite (una herramienta gratuita que intercepta el tráfico entre el navegador y el servidor) sobre una aplicación de pruebas, están recogidos como categorías propias en el OWASP API Security Top 10 de 2023, la lista de referencia mundial en seguridad de APIs.

1. Mass Assignment: cambiar un campo que no deberías poder tocar

Cuando guardas los datos de tu perfil, el navegador envía al servidor un paquete con varios campos: nombre, apellido, correo… El fallo de Mass Assignment aparece cuando la aplicación coge ese paquete entero y lo guarda tal cual, sin comprobar qué campos tiene permiso de tocar el usuario que lo envía. Si el servidor confía ciegamente en todo el paquete, añadir a mano un campo como "plan": "premium" puede bastar para que la cuenta quede marcada como premium, aunque la interfaz nunca haya mostrado esa opción.

No es una teoría: en 2012 el investigador Egor Homakov demostró exactamente este fallo contra GitHub, aprovechando que Ruby on Rails vinculaba automáticamente los parámetros de una petición a los atributos del modelo. Consiguió añadir su propia clave SSH pública al repositorio oficial de Rails sin tener permiso, simplemente añadiendo un parámetro de más a una petición legítima. El caso fue tan sonado que GitHub cambió cómo gestionaba los parámetros y el propio framework Rails publicó parches de seguridad (versiones 3.2.12, 3.1.11 y 2.3.17) poco después.

Cómo lo evita un desarrollador (con código real)

La solución de fondo, según la hoja de referencia de OWASP sobre Mass Assignment, es usar una lista blanca de campos editables (nunca una lista negra) o, mejor todavía, un objeto intermedio (DTO) que solo contenga los campos que el cliente puede tocar. Así se ve en tres frameworks habituales:

// Laravel: solo estos campos se pueden asignar en masa
protected $fillable = ['nombre', 'apellido', 'email'];
// 'plan' y 'rol' quedan fuera: nadie los puede tocar por Mass Assignment

// Node.js + Mongoose: filtra el body antes de guardar
const _ = require('lodash');
const datosSeguros = _.pick(req.body, ['nombre', 'apellido', 'email']);
await Usuario.findByIdAndUpdate(userId, datosSeguros);

// Spring MVC: bloquea explícitamente los campos sensibles
@InitBinder
public void initBinder(WebDataBinder binder) {
    binder.setDisallowedFields("plan", "rol", "esAdmin");
}

2. Manipulación de la respuesta: no fiarse de lo que dice el propio navegador

La segunda técnica trabaja al revés: en vez de tocar lo que se envía, se modifica sobre la marcha la respuesta que llega desde el servidor, usando la función «Match & Replace» de Burp Suite para sustituir automáticamente un valor (por ejemplo "plan": "free") por otro ("plan": "premium") antes de que llegue al navegador. Si la aplicación decide qué botones mostrar u ocultar basándose en ese dato, aparecen funciones premium en pantalla que en teoría no deberían estar disponibles.

El problema de fondo es confiar en el cliente: si el frontend es quien decide qué puedes hacer, cualquiera que controle su propio tráfico puede mentirle. La única validación que cuenta de verdad es la que hace el servidor en cada petición, no lo que la pantalla dé a entender. Un ejemplo real y ya corregido: en 2021 un investigador reportó a Stripe (informe público en HackerOne) que un código de promoción se podía usar más veces de las permitidas porque el límite solo se comprobaba en un punto del flujo, no en cada canje.

3. Una API que cuenta más de la cuenta

El tercer fallo aparece en la comunicación entre el frontend y el backend: una API que, al pedir los datos del usuario, devuelve más información de la que la pantalla necesita mostrar, incluidos campos internos como identificadores de plan, permisos o marcas de administrador. Aunque la interfaz no los pinte, esos datos llegan igualmente al navegador y quedan visibles para quien mire el tráfico con Burp Suite. OWASP agrupa este problema y el Mass Assignment bajo el mismo epígrafe, API3:2023 Broken Object Property Level Authorization, porque comparten la misma raíz: nadie decidió, campo a campo, quién puede leer o escribir cada uno.

Suele pasar cuando una API genérica sirve a la vez a la app del usuario normal y al panel interno de administración, con una única respuesta «para todos» en lugar de una respuesta recortada según el rol de quien pregunta.

4. Race Condition: colar dos peticiones a la vez

La cuarta, la que el propio Gorka señala como la más interesante, es una condición de carrera (Race Condition) sobre el canje de cupones. Cuando el servidor comprueba «¿este cupón ya se ha usado?» y solo después lo marca como gastado, existe una pequeña ventana de tiempo entre la comprobación y el marcado. Si se envían varias peticiones al mismo tiempo, el servidor puede procesarlas todas antes de que ninguna haya marcado el cupón como usado, y el mismo código se aplica varias veces.

Este fallo tiene ejemplos públicos y ya corregidos muy conocidos en el mundo del Bug Bounty: en un informe de HackerOne de 2016, un investigador consiguió canjear el mismo cupón de Instacart varias veces enviando peticiones simultáneas, y cuando la empresa aplicó un primer parche, descubrió que aún podía saltárselo combinando dos códigos promocionales distintos a la vez. Instacart pagó 200 $ por el reporte y corrigió el fallo de raíz.

Cómo lo evita un desarrollador

La única forma fiable de cerrar una Race Condition es que la comprobación y el marcado ocurran como una única operación indivisible en la base de datos, nunca como dos pasos separados en el código de la aplicación:

-- PostgreSQL/MySQL: comprobar y marcar en una sola sentencia atómica
UPDATE cupones
SET usado = true
WHERE codigo = 'DESCUENTO10' AND usado = false;
-- Si "usado" ya estaba a true, la sentencia no actualiza ninguna fila:
-- solo la primera petición que llega gana la carrera.

Ficha técnica del vídeo

Checklist: cómo revisar tu propia app si vendes suscripciones

Si tienes o gestionas una aplicación con planes de pago, esto no son curiosidades técnicas: son ingresos que se escapan y, en el caso de la sobreexposición de datos, también una fuga de información interna. Antes de dar por cerrado el tema, comprueba estos cuatro puntos:

• ¿Tu API de «actualizar perfil» usa una lista blanca de campos? Si guardas el objeto completo que llega del cliente, tienes un Mass Assignment esperando a que alguien añada el campo equivocado.
• ¿Cada función premium se comprueba también en el servidor? Ocultar un botón en la interfaz no es una medida de seguridad si el endpoint de detrás no vuelve a preguntar «¿esta cuenta tiene plan premium de verdad?».
• ¿La respuesta de tu API es la misma para el usuario normal y para el admin? Si es así, probablemente estés enviando de más. Diseña una respuesta recortada por rol.
• ¿El canje de un cupón o código está protegido con un bloqueo atómico en base de datos? Si la comprobación y el marcado son dos pasos separados en tu código, es vulnerable a Race Condition, lo pruebes o no.

¿Puedes hacer Bug Bounty tú mismo?

No hace falta ser un experto para empezar, pero sí conviene tener una base sólida. Esto es lo que te ayudará a dar tus primeros pasos:

• Nociones de HTTP y de cómo viaja una petición entre el navegador y el servidor, para entender qué es lo que se está interceptando con Burp Suite.
• Practicar siempre en plataformas legales como HackerOne, Bugcrowd o aplicaciones de pruebas propias, nunca en una app real sin permiso, aunque sea la tuya de uso diario.
• Aprender los fallos de lógica de negocio más comunes: Mass Assignment, IDOR, confianza excesiva en el frontend y Race Conditions, que forman parte del OWASP API Security Top 10.
• Paciencia: los programas de Bug Bounty suelen recibir muchos reportes duplicados antes de que uno tuyo sea el primero en llegar; el propio caso de Instacart tardó en corregirse del todo, con un segundo bypass tras el primer parche.

Ventajas y desventajas del Bug Bounty

Dónde practicar Bug Bounty de forma legal

Si quieres dar el salto, la plataforma HackerOne reúne cientos de programas oficiales de empresas que pagan por encontrar fallos de seguridad, con normas claras sobre qué se puede y qué no se puede probar. Es el punto de partida más seguro y legal para aplicar lo que se ve en el vídeo, incluida la búsqueda de fallos de lógica de negocio como los de Mass Assignment o Race Condition.

Si además quieres montar tu propio laboratorio de pruebas en casa, en Así de Fácil también tenemos la guía cómo instalar Kali Linux en VirtualBox y VMware, el sistema operativo que usan la mayoría de hackers éticos para practicar. Y si lo tuyo es más entender cómo piensan los atacantes con ecommerce, tenemos también nuestro artículo sobre cómo hackean una tienda online (IDOR y manipulación del carrito). Puedes ver más contenido relacionado en nuestra categoría de Seguridad digital.

Preguntas frecuentes

¿Es ilegal usar estas técnicas para conseguir premium gratis en una app real?

Sí. Aunque el vídeo las explique con fines educativos sobre una aplicación de pruebas, usarlas contra un servicio real sin autorización es un acceso no autorizado a un sistema informático y un incumplimiento de los términos de servicio, con riesgo de cierre de cuenta y de consecuencias legales, aunque el «daño» parezca pequeño.

¿Qué es exactamente el Mass Assignment?

Es un fallo en el que el servidor guarda directamente todos los campos que le llegan en una petición, sin comprobar cuáles debería poder modificar el usuario. Si entre esos campos hay uno como el plan de suscripción o el rol de la cuenta, un atacante puede añadirlo a mano y cambiarlo. Es la misma técnica que Egor Homakov usó contra GitHub en 2012.

¿Por qué no basta con ocultar los botones premium en la app?

Porque ocultar algo en la interfaz no impide que alguien intercepte y modifique el tráfico con una herramienta como Burp Suite. Si el servidor no vuelve a comprobar los permisos en cada petición, esconder el botón es solo una barrera visual, no una barrera de seguridad real.

¿Cómo se evita una Race Condition en el canje de cupones?

Con un bloqueo o una transacción atómica en la base de datos que impida que dos peticiones simultáneas lean «cupón disponible» antes de que ninguna lo haya marcado como usado. Sin ese bloqueo, enviar varias peticiones a la vez puede colar el mismo cupón más de una vez, como le pasó a Instacart.

¿Qué es el OWASP API Security Top 10?

Es la lista de referencia mundial, elaborada por la fundación OWASP, con los diez fallos de seguridad más críticos y habituales en las APIs. Mass Assignment y la sobreexposición de datos aparecen unidos en la categoría API3:2023 «Broken Object Property Level Authorization».

¿Necesito ser programador para entender estos fallos?

No es obligatorio, pero ayuda mucho. Con nociones de cómo viaja una petición HTTP entre el navegador y el servidor puedes seguir la lógica de los cuatro casos; la parte de programación se aprende sobre la marcha si decides practicar Bug Bounty en serio.

¿Cómo sé si mi propia API tiene un fallo de Mass Assignment?

Revisa si el código que actualiza un registro guarda directamente el cuerpo completo de la petición o si, por el contrario, filtra explícitamente qué campos acepta (una lista blanca). Herramientas de análisis estático y una revisión manual del endpoint de «actualizar perfil» suelen bastar para detectarlo.

Conclusión

Los cuatro fallos que muestra Gorka tienen algo en común: ninguno es un agujero exótico, son errores de lógica de negocio que aparecen cuando el servidor confía en algo que no debería (el propio cliente, un campo suelto, el orden de llegada de las peticiones). GitHub, Stripe e Instacart ya han pasado por versiones reales de estos tres primeros y del cuarto, respectivamente. Para quien desarrolla o gestiona una app con planes de pago, la lección es clara: valida siempre en el servidor, en cada petición, y nunca solo en el frontend. Para quien solo quiere entender cómo funciona por dentro una aplicación que usa a diario, el vídeo es un buen punto de partida para pensar como un atacante y, de paso, saber qué preguntar la próxima vez que confíe sus datos a una app de suscripción.

¿Gestionas una aplicación con planes de pago? Cuéntanos en los comentarios si alguna vez os habéis encontrado con uno de estos cuatro fallos.