Secuestro de URI de Redirección Entra ID

Qué es el secuestro de URI de redirección Entra ID

Una URI de redirección de Entra ID —la documentación de Microsoft también la llama URL de respuesta (reply URL)— es el destino al que la plataforma de identidad de Microsoft envía a un usuario, junto con un token o un código de autorización, una vez que se ha autenticado y ha dado su consentimiento. Todo registro de aplicación que use el flujo de código de autorización de OAuth 2.0, el flujo de concesión implícita (implicit grant), o OpenID Connect debe declarar de antemano sus URIs de redirección exactas; Entra ID se niega a redirigir a cualquier otro sitio y devuelve AADSTS50011 si el valor de la solicitud de inicio de sesión no coincide con ninguno de los registrados.

Ese paso de coincidencia es, por sí solo, toda la frontera de seguridad. Tres decisiones de configuración en un único registro de aplicación bastan para debilitarla lo suficiente como para que un atacante se lleve un token válido en lugar de la aplicación legítima:

URLs de respuesta con wildcard (APP_REPLY_URL_WILDCARD) — un patrón como https://*.contoso.com en lugar de una URL exacta.
URLs de respuesta en HTTP (APP_REPLY_URL_HTTP) — una URI de redirección que no está restringida a https.
Concesión implícita habilitada (APP_IMPLICIT_GRANT_ENABLED) — el registro de aplicación sigue permitiendo que Entra ID devuelva directamente un token de acceso o un token de ID en el navegador, en lugar de pasar por un intercambio de token en el servidor.

Cada uno de estos puntos es de severidad Alta por sí solo en el catálogo de EtcSec. Combinados en la misma aplicación, convierten un simple enlace de phishing en una vía de exfiltración de tokens totalmente funcional — y se suman a otros riesgos de registro de aplicaciones que EtcSec monitoriza, como los registros de aplicaciones sobreprivilegiados, las credenciales obsoletas, y los permisos peligrosos de Graph API.

Cómo funciona

La coincidencia exacta es la clave, los wildcard la anulan

Entra ID exige que las URIs de redirección comiencen con https, con una excepción limitada para localhost en desarrollo local — http://localhost/myapp es válido, http://contoso.com/callback no lo es. Los wildcard son una relajación separada y opcional de la regla de coincidencia, no de la regla de esquema: un registro de aplicación limitado a cuentas laborales o educativas puede, mediante el editor del manifiesto de la aplicación, registrar https://*.contoso.com y hacer que Entra ID trate cualquier subdominio coincidente como autorizado. La guía oficial de Microsoft sobre buenas prácticas y limitaciones de las URI de redirección es explícita: esto debe evitarse; según la RFC 6749 sección 3.1.2, un endpoint de redirección debe ser una URI absoluta, y cuando una entrada wildcard coincide, Entra elimina la cadena de consulta y el fragmento de la redirección — que es justo donde viajaría un token del flujo implícito.

La RFC 9700, las mejores prácticas actuales de seguridad de la IETF para OAuth 2.0, va más allá de «evitar»: exige que los servidores de autorización usen coincidencia exacta de cadena para las URIs de redirección, con la única excepción del número de puerto en las URIs localhost de aplicaciones nativas. La justificación es concreta — implementaciones ingenuas de wildcard han permitido a atacantes registrar algo como atacante.ejemplo/.sitio.ejemplo y pasar una coincidencia de subcadena, e incluso un manejo correcto del wildcard deja abierta la toma de control de subdominios como vía real: cualquier subdominio que un atacante pueda levantar (un CNAME abandonado, un host de desarrollo olvidado) se convierte en un destino de redirección válido en cuanto coincide con el patrón.

La concesión implícita entrega el token a quien tenga la URL

El flujo de código de autorización mantiene el intercambio de tokens en un canal separado: el navegador solo ve un código de corta duración, que la aplicación intercambia después por un token de servidor a servidor. La concesión implícita se salta ese paso — Entra ID devuelve directamente el token de acceso o el token de ID en la respuesta /authorize, añadido al fragmento de la URI de redirección. Ese comportamiento se controla por registro de aplicación mediante dos propiedades de Microsoft Graph en el recurso web de la aplicación: implicitGrantSettings.enableIdTokenIssuance y implicitGrantSettings.enableAccessTokenIssuance. Si cualquiera de las dos es true, la aplicación puede solicitar un response type token o id_token y recibir un token sin ningún intercambio del lado del servidor.

La RFC 9700 sección 2.1.2 es directa sobre la consecuencia: los clientes «NO DEBERÍAN usar la concesión implícita … a menos que se impida la inyección de tokens de acceso en la respuesta de autorización y se mitiguen los vectores de fuga de tokens mencionados». Los vectores de fuga que enumera son poco vistosos pero reales — un token alojado en un fragmento de URL puede acabar en el historial del navegador, ser reenviado por el user agent durante redirecciones, o filtrarse mediante una cabecera Referer hacia un sitio de terceros al que la página portadora del token resulte enlazar. Además, un token del flujo implícito no tiene ninguna restricción de emisor (sender-constraining): nada lo vincula al cliente para el que fue emitido, así que una copia vale igual que el original. La documentación de Microsoft sobre el flujo de concesión implícita llegó a la misma conclusión desde un ángulo distinto — el abandono de las cookies de terceros por parte de los navegadores rompió el paso de renovación silenciosa del flujo — y ahora indica directamente a los desarrolladores que no lo usen, remitiendo a la RFC 9700 sección 2.1.2 y recomendando migrar al flujo de código de autorización.

La cadena de ataque

Paso 1 — Encontrar o secuestrar un destino de redirección que coincida

Si el registro de aplicación objetivo tiene APP_REPLY_URL_WILDCARD — digamos https://*.contoso.com/auth — el atacante no necesita comprometer el dominio principal. Cualquier subdominio que resuelva, incluido uno de un entorno de desarrollo abandonado o un registro DNS huérfano dejado por un servicio dado de baja, coincide con el patrón y se convierte en un destino de redirección de apariencia legítima para Entra ID.

Paso 2 — Solicitar un token en lugar de un código

Con APP_IMPLICIT_GRANT_ENABLED activado en la aplicación, el atacante construye una URL de inicio de sesión contra el client_id real con response_type=token (o id_token token) y una redirect_uri apuntando a su endpoint coincidente, y la distribuye como enlace de phishing. La víctima se autentica contra la página de inicio de sesión genuina de Entra ID — no hay ningún formulario de login falso que detectar — y Entra ID redirige el navegador al endpoint del atacante con el token adjunto.

Paso 3 — Capturar el token en claro

Cuando APP_REPLY_URL_HTTP también está presente, o cuando el endpoint controlado por el atacante simplemente registra lo que recibe, el token que viaja en la URL puede capturarse directamente, quedar registrado por un proxy, o exponerse a través de los vectores de fuga documentados por la RFC 9700 — historial del navegador, cabeceras Referer en enlaces salientes de la página de destino, o reenvío durante una redirección posterior.

Paso 4 — Reutilizar el token sin necesitar ningún secreto de cliente

Como la concesión implícita emite un token bearer sin restricción de emisor, el atacante lo usa directamente contra Microsoft Graph o el recurso para el que estuviera delimitado, haciéndose pasar por la víctima, mientras siga siendo válido. Este flujo no incluye refresh token, así que la ventana está acotada por el tiempo de vida del token de acceso — pero nada más se interpone entre la captura y la reutilización. Este es un mecanismo distinto del phishing de consentimiento OAuth, que engaña a un usuario para que autorice una aplicación maliciosa en lugar de interceptar un token destinado a una legítima — pero ambos terminan con un atacante en posesión de una credencial válida hacia su tenant.

Detección

La configuración de las URIs de redirección y los ajustes de concesión implícita residen en el objeto de la aplicación, no en los registros de actividad de inicio de sesión, así que se trata de un control de inventario contra Microsoft Graph más que de una consulta SIEM:

Indicador	Dónde verificar	Qué significa
Una entrada `web.redirectUris` que contiene `*`	`GET /applications/{id}` — `web.redirectUris`	URL de respuesta con wildcard — `APP_REPLY_URL_WILDCARD`
Una entrada `web.redirectUris` que comienza con `http://` y no es `localhost`	El mismo array `web.redirectUris`	URL de respuesta en texto plano — `APP_REPLY_URL_HTTP`
`web.implicitGrantSettings.enableIdTokenIssuance` o `enableAccessTokenIssuance` en `true`	`GET /applications/{id}` — `web.implicitGrantSettings`	Flujo implícito o híbrido aún permitido — `APP_IMPLICIT_GRANT_ENABLED`

En el centro de administración de Microsoft Entra, la misma información es visible por aplicación en Registros de aplicaciones → [app] → Autenticación: la lista de URIs de redirección de la plataforma Web, y las casillas de Concesión implícita y flujos híbridos para tokens de ID y tokens de acceso.

Corrección (Remediation)

Sustituir las URIs de redirección con wildcard por URIs exactas y absolutas. Liste cada endpoint de retorno real de forma individual en lugar de un patrón. Si el número de subdominios lo hace inmanejable, Microsoft documenta una alternativa con parámetro state: una única URI de redirección compartida, protegida contra CSRF, más un valor state específico de la aplicación, en lugar de una coincidencia wildcard.
Eliminar cualquier URI de redirección http:// que no sea localhost. Entra ID ya rechaza las entradas nuevas sin https fuera de localhost, pero los registros de aplicación heredados pueden conservar una de antes de que se aplicara esa restricción; verifique web.redirectUris directamente en lugar de asumir que el centro de administración la habría bloqueado en la creación.
Deshabilitar la concesión implícita. Ponga implicitGrantSettings.enableIdTokenIssuance y enableAccessTokenIssuance en false (o desmarque las dos casillas en el portal), salvo que una integración heredada dependa explícitamente de ellas.
Migrar al flujo de código de autorización con PKCE. La RFC 9700 sección 2.1.1 exige PKCE para clientes públicos y lo recomienda para clientes confidenciales; las bibliotecas MSAL de Microsoft implementan el intercambio de código y el challenge PKCE por usted, así que suele ser un cambio de biblioteca y no un proyecto de reimplementación de protocolo.
Revisar la plataforma tras la migración. Una single-page application que aún necesite un flujo limitado al navegador debe migrar al flujo de código de autorización con PKCE en la plataforma SPA, y no quedarse en Web con la concesión implícita habilitada.

Cómo lo detecta EtcSec

La auditoría de Azure de EtcSec lee web.redirectUris y web.implicitGrantSettings de cada registro de aplicación a través de Microsoft Graph, y genera APP_REPLY_URL_WILDCARD para cualquier entrada wildcard, APP_REPLY_URL_HTTP para cualquier entrada http:// no-localhost, y APP_IMPLICIT_GRANT_ENABLED cuando cualquiera de los indicadores de emisión de concesión implícita es true — los tres limitados a la plataforma Web, como se indicó antes. Este clúster es solo una parte de una revisión más amplia; consulte nuestra guía práctica para auditar la seguridad de Microsoft Entra ID para la checklist completa más allá de los registros de aplicaciones.