🦑Laboratorio: ID de usuario controlado por parámetro de solicitud con fuga de datos en redirección

En este caso podemos intentar acceder como wiener e intentar controlar o modificar el username que está como parametro con wiener como user by default y cambiarlo a carlos.

Y analizar la petición de redirección desde burp en busca de anomalías o la fuga de datos que mencionan.

Lo cambiamos por carlos y automaticamente nos manda a la pagina de inicio de sesión:

Con está pagina así, lo que debemos hacer, es poder lograr entender la fuga de datos o disclosure information que está en la petición de redirección, analicemosla con Burp:

burp repeater

Cambiando el parametro de Wiener a Carlos podemos darnos cuenta como la fuga de datos está presente, aunque redirige a la pagina de inicio de sesión, la pagina alcanza a dar un response 302 con la API Key del user carlos, que es diferente a la de wiener.

• Wiener: oc6Rpu630QEqIgc2Bs9xVuO1GqPbrP7Y

• Carlos: W0mj4cKh1nqRixXAJMz9iPOwoYST5OhA

En este lab entendimos el como la pagina intenta mantener un control de acceso "restringido" a todo aquel que quiera modificar el param username de la url sin embargo en ese intento de redireccionar hacía el inicio de sesión nuevamente se les escapa realmente un disclosure information que proxys inversos como burp puede atrapar/captar y ver la información que se retiene, en este caso así pudimos obtener la API Key de Carlos.