Manual de Burp Suite Community Edition
Capítulo 5 · Analizar un formulario de login
Serie: Burp Suite desde cero | unfantasmaenelsistema.com
Con la interfaz y el navegador incorporado ya dominados, empieza el bloque práctico del manual: analizar, uno por uno, los flujos que vas a encontrar en cualquier aplicación real. Empezamos por el más común de todos -un formulario de login- porque es el sitio donde más a menudo se filtran detalles de implementación que el formulario nunca muestra.
Qué aprenderás en este capítulo
Qué contiene realmente la petición que genera un formulario de login · Por qué comparar la respuesta de una credencial válida y una inválida es la primera prueba que hay que hacer · Dónde viaja el token de sesión tras un login correcto y qué tipo de token es · Un aviso práctico sobre cómo Intercept puede agotar las conexiones del navegador si retienes demasiadas peticiones a la vez
1. El formulario, antes de tocar Burp
El formulario de login de Juice Shop es deliberadamente simple: campo de email, campo de contraseña, checkbox "Remember me" y un botón de envío. Nada de esto dice nada todavía sobre cómo se procesa por detrás -si la contraseña viaja en claro, si hay protección contra fuerza bruta, si la respuesta cambia según si el usuario existe o no. Todo eso solo se ve con Burp de por medio.
El formulario de login de Juice Shop, sin nada especial a la vista
2. La petición real que genera el envío
Al enviar el formulario con Intercept activo, la petición retenida es un POST a /rest/user/login con el email y la contraseña como un cuerpo JSON:
POST /rest/user/login retenido en Intercept: cabeceras completas de la petición real
Tres detalles saltan a la vista en cuanto se mira esta petición con calma:
- Content-Type: application/json -no es un formulario HTML clásico (application/x-www-form-urlencoded), es una API REST que el frontend de Angular llama por debajo. Esto es la norma en cualquier aplicación moderna, y es exactamente el tipo de llamada que solo se ve con un proxy delante.
- La contraseña viaja en texto plano dentro del cuerpo JSON -algo totalmente normal y esperado, porque va protegida por HTTPS en producción (en este laboratorio es HTTP porque es local); lo que sí hay que comprobar es que el servidor la compare contra un hash y nunca la devuelva de vuelta en ninguna respuesta.
- No hay cabecera de protección visible contra fuerza bruta (ni captcha, ni token anti-automatización) en esta petición concreta: es justo la pregunta que nos hacemos en el capítulo 8 con Intruder.
Aviso: Intercept puede agotar las conexiones del navegador
Si retienes muchas peticiones seguidas sin reenviarlas, el navegador puede quedarse sin conexiones libres hacia ese servidor -los navegadores limitan cuántas conexiones simultáneas abren contra el mismo origen- y una petición nueva, como este mismo login, se queda esperando en el propio navegador sin llegar siquiera a Burp hasta que reenvías (Forward) las anteriores. Si envías un formulario y no ves la petición aparecer en Intercept, antes de sospechar de un error, comprueba si tienes peticiones antiguas sin reenviar acumulándose.
3. Comparar una credencial válida y una inválida
La prueba más básica -y más reveladora- sobre cualquier login es enviarlo dos veces: una con un email que no existe, y otra con un email que sí existe pero una contraseña incorrecta. Si el mensaje de error es distinto en ambos casos ("usuario no encontrado" frente a "contraseña incorrecta"), la aplicación tiene un fallo de enumeración de usuarios: un atacante puede usar el formulario de login como oráculo para averiguar qué cuentas existen, sin necesidad de acertar ninguna contraseña.
Esta comparación se hace de forma mucho más cómoda con Repeater que reenviando a mano desde Intercept -el capítulo 7 retoma exactamente este ejemplo para mostrar cómo.
4. Qué llega en la respuesta tras un login correcto
Cuando las credenciales son correctas, la respuesta de /rest/user/login incluye un token JWT (JSON Web Token) que el frontend guarda y adjunta como cabecera `Authorization: Bearer ...` en cada petición posterior -es exactamente lo que vimos en el capítulo 2 sobre /rest/basket/6 y /rest/admin/application-configuration. Ese token, no una cookie de sesión clásica, es lo que demuestra que un usuario ha iniciado sesión en toda la duración de la visita.
Un adelanto: qué se puede hacer con ese token en Decoder
Un JWT no está cifrado, solo codificado en Base64: cualquiera que lo intercepte puede leer su contenido -típicamente el ID de usuario, el rol y la fecha de caducidad- sin necesidad de ninguna clave. El capítulo 9 usa exactamente este token de login para mostrar cómo se decodifica con la pestaña Decoder de Burp.
Conclusión
Un formulario de login, mirado a través de Burp, deja de ser una caja negra: se ve el formato exacto de las credenciales, se puede comparar el comportamiento ante una cuenta válida e inválida, y se puede seguir el rastro del token que la aplicación usa después para identificarte en cada petición.
En el próximo capítulo aplicamos exactamente el mismo tipo de análisis a un registro de cuenta nueva, y a los formularios de contacto y dirección -cada uno con su propia superficie de fallos característicos.
unfantasmaenelsistema.com | Seguridad, sistemas y todo lo que no debería funcionar (pero funciona)