Manual de Burp Suite Community Edition
Capítulo 20 · Fallos de lógica de negocio
Serie: Burp Suite desde cero | unfantasmaenelsistema.com
Todo lo anterior tenía un síntoma reconocible -una comilla que rompe una consulta, un id que no debería ser tuyo, una respuesta que llega más rápido de lo que debería. Un fallo de lógica de negocio no tiene ningún síntoma técnico: cada petición es sintácticamente perfecta, pasa la autenticación, pasa la autorización, no inyecta nada en ningún sitio. El fallo está en que nadie codificó la regla de negocio que esa secuencia de peticiones perfectamente válidas acaba de romper. Por eso ningún escáner automático los encuentra -no hay nada "mal formado" que detectar.
Qué aprenderás en este capítulo
Qué es un fallo de lógica de negocio y por qué es invisible para cualquier escáner automático · Cómo el monedero con saldo autoimpuesto del capítulo 15 se convierte en una membresía premium real y gratuita · Cómo el fallo de cantidad negativa del capítulo 11 termina, esta vez sí, en un pedido real completado · Por qué encadenar hallazgos pequeños hasta un impacto final es la habilidad que de verdad distingue una auditoría útil
1. Cuando cada petición por separado es intachable
Los dos casos de este capítulo comparten una estructura: ninguno de sus pasos individuales dispara ninguna alarma. Cada uno ya se vio, por separado, en un capítulo anterior -aquí se trata de completar el recorrido hasta el final, algo que en su momento se dejó a medias a propósito.
2. Dinero falso que compra un estatus real
El capítulo 15 encontró `PUT /rest/wallet/balance` -un endpoint que fija el saldo del monedero al valor exacto que mande el cliente, sin ninguna pasarela de pago real detrás. En su momento quedó como una curiosidad -"puedes ponerte el saldo que quieras"- sin preguntarse qué se puede comprar con él. La tienda vende una membresía Deluxe por 49€:
Una cuenta recién creada: saldo del monedero en 0, confirmado con su propio GET
Intentar la mejora sin saldo suficiente sí está comprobado -la aplicación no es descuidada en todos los sitios a la vez:
POST /rest/deluxe-membership con saldo 0: 400 Bad Request, "Insuffienct funds in Wallet" (el typo es de la propia aplicación)
El control existe -el problema es de dónde saca el dato
La comprobación de saldo suficiente es real y funciona. Lo que falla es la fuente de ese saldo: el mismo endpoint que la comprobación consulta es el que el capítulo 15 demostró que cualquiera puede rellenar a mano, sin que haya pasado nunca dinero real por ningún sitio.
Basta con rellenarlo justo hasta el precio de la membresía, con el mismo endpoint de siempre:
PUT /rest/wallet/balance con balance:49 -el saldo "correcto" para pagar la membresía, puesto por el propio cliente
POST /rest/deluxe-membership con ese saldo: 200 OK, "Congratulations! You are now a deluxe member!" -con un JWT nuevo que ya lleva el estatus premium
El hallazgo suelto del capítulo 15 nunca fue solo una curiosidad
Nada en el capítulo 15 gritaba "vulnerabilidad crítica" -era un endpoint que aceptaba un número. Encadenado con la lógica de negocio de la membresía, ese número se convierte en una cuenta premium real y gratuita, con todos los beneficios -precios con descuento en cada producto de la tienda- que un cliente de pago legítimo obtiene pagando de verdad.
3. Cerrando el círculo: un pedido real de -11.244,50€
El capítulo 11 encontró que `PUT /api/BasketItems/{id}` acepta una cantidad negativa sin ninguna comprobación, y se quedó ahí -corrigiendo la cantidad antes de que llegara a afectar a una compra real. Esta vez se deja llegar hasta el final: un artículo de 22,49€, con cantidad -500, y un checkout completo con dirección y método de pago reales.
El pedido queda confirmado de verdad: totalPrice -11244.5, quantity -500, bonus -1000 -un pedido real y completado, no una simulación en Repeater
La diferencia entre "encontrar un fallo" y "medir su impacto"
El capítulo 11 ya sabía que esto era posible. Lo que faltaba -y es la pregunta que cualquier informe serio tiene que responder- es qué pasa si se deja completar el flujo entero: en una tienda conectada a una pasarela de pago real, un pedido con un total negativo de cinco cifras no se queda en un número raro en una base de datos de pruebas. Se traduce, en el mejor de los casos, en un error de la pasarela; en el peor, en una devolución real de más de once mil euros a la tarjeta de quien hizo el pedido.
Conclusión
Ninguno de estos dos ataques usó una técnica nueva -el monedero salió en el capítulo 15, la cantidad negativa en el capítulo 11. Lo único que cambió fue completar el recorrido hasta el final en vez de detenerse en el primer síntoma. Esa es, en el fondo, la habilidad que separa una lista de hallazgos sueltos de una auditoría que de verdad mide impacto: no basta con encontrar que algo "parece raro", hace falta seguir el hilo hasta donde lleva de verdad.
El capítulo final de este manual deja de buscar fallos nuevos y se ocupa de lo último que hace falta saber: cómo organizar todo lo encontrado en un informe que alguien pueda leer y actuar, y un apéndice con la configuración y la chuleta de referencia rápida para seguir usando Burp mucho después de haber cerrado estas páginas.
unfantasmaenelsistema.com | Seguridad, sistemas y todo lo que no debería funcionar (pero funciona)