Manual de Burp Suite Community Edition
Capítulo 6 · Registro, contacto y dirección
Serie: Burp Suite desde cero | unfantasmaenelsistema.com
El capítulo anterior analizó un login a fondo. La buena noticia es que el método no cambia de un formulario a otro: interceptas, miras la petición real, comparas cabeceras y cuerpo con lo que esperarías, y pruebas variaciones. Este capítulo recorre tres formularios más -registro de cuenta, dirección de envío y contacto- señalando qué es distinto y característico de cada uno.
Qué aprenderás en este capítulo
Qué campos extra aparecen en un registro de cuenta que no están en un login, y por qué importan · Por qué una dirección de envío es uno de los sitios más típicos para encontrar IDOR · Cómo un CAPTCHA meramente aritmético en el cliente no es ninguna protección real · La diferencia entre validación en el navegador y validación en el servidor, con un ejemplo de cada formulario
1. Registro de cuenta: más campos, más superficie
Formulario de registro de Juice Shop: email, contraseña repetida, y una pregunta de seguridad
Un registro genera un POST a /api/Users con una estructura similar a la del login -email y contraseña en JSON- pero con campos añadidos: la contraseña repetida, y la pregunta y respuesta de seguridad. Dos cosas merece la pena comprobar aquí con Burp:
- ¿Se valida la fortaleza de la contraseña en el servidor, o solo en el navegador? Es fácil de comprobar: rellena el formulario con una contraseña débil que el JavaScript del cliente rechace, e intercepta la petición justo antes de que el navegador la bloquee -si consigues que salga con un valor que el formulario nunca hubiera dejado enviar a mano, y el servidor la acepta igualmente, la validación del lado servidor no existe.
- ¿El mensaje de error revela si un email ya está registrado? Igual que en el login, si la respuesta a un email duplicado es distinta a la de un registro nuevo con éxito, tienes otro punto de enumeración de usuarios.
2. Dirección de envío: el candidato número uno a IDOR
Formulario de nueva dirección: país, nombre, teléfono, código postal, dirección, ciudad y estado
Guardar una dirección genera un POST a /api/Addresses, y cada dirección guardada recibe un identificador numérico propio. Ese identificador es exactamente el tipo de dato que hace falta vigilar: si más adelante ves una petición como `GET /api/Addresses/6`, la pregunta inmediata que hay que hacerse es ¿qué pasa si cambio ese 6 por un 5 o un 7? Si la aplicación te devuelve la dirección de otro usuario sin comprobar que te pertenece, es un IDOR (Insecure Direct Object Reference) -el capítulo 16 dedica un capítulo entero a esta clase de vulnerabilidad, y usa direcciones y pedidos como ejemplo principal precisamente porque es donde más se encuentra en aplicaciones reales.
Un patrón que se repite en toda la aplicación
Cualquier URL con un número al final -/api/Addresses/6, /rest/basket/6, /api/Feedbacks/12- es candidata a este mismo experimento. Merece la pena ir anotando en Burp (con Organizer, capítulo 10) cada una que encuentres mientras navegas, para probarlas todas de forma sistemática más adelante en vez de una por una según te acuerdas.
3. Contacto: CAPTCHA y validación en el cliente
Formulario de feedback con un CAPTCHA aritmético trivial ("What is 2-7-10?") calculado en el propio navegador
El formulario de contacto añade dos elementos interesantes que no aparecían en los anteriores: un límite de caracteres ("Max. 160 characters") y un CAPTCHA. El límite de caracteres es fácil de comprobar con Burp: basta con interceptar el envío y alargar el comentario en el cuerpo de la petición después de que el navegador ya no te dejaba escribir más -si el servidor lo acepta igualmente, el límite es cosmético.
El CAPTCHA de este formulario es aún más frágil: es una simple operación aritmética ("What is 2-7-10?") que Angular calcula en el propio navegador, sin ninguna llamada al servidor de por medio para generar el reto. Eso significa que la respuesta correcta está en algún sitio del JavaScript que ya se ha descargado el navegador antes de mostrar el formulario -no hace falta ni resolver la cuenta a mano, solo mirar qué valor construye la aplicación y usarlo, o directamente automatizar el envío sin pasar por la interfaz en absoluto, algo que veremos con Intruder en el capítulo 8.
Por qué esto es un fallo de diseño, no un detalle menor
Un CAPTCHA solo protege algo si el servidor es quien decide el reto y quien valida la respuesta, sin que el cliente pueda saber de antemano cuál es la solución correcta. Un CAPTCHA calculado en JavaScript en el navegador -como este- no impide absolutamente ningún envío automatizado; es una protección real solo en apariencia.
Conclusión
El registro, la dirección y el contacto comparten la misma anatomía que el login: una petición HTTP con un cuerpo estructurado, cabeceras, y una respuesta que hay que leer con atención. Lo único que cambia de un formulario a otro es qué hay que buscar específicamente -enumeración de usuarios en el registro, IDOR en la dirección, validación puramente cosmética en el contacto.
Con estos seis primeros capítulos ya tienes toda la base de Proxy. El bloque siguiente entra en las herramientas activas de Burp -Repeater, Intruder, Decoder, Comparer- que son las que convierten estas observaciones en pruebas concretas y repetibles.
unfantasmaenelsistema.com | Seguridad, sistemas y todo lo que no debería funcionar (pero funciona)