Entra ID Redirect URI Hijacking: URLs de Resposta com Wildcard e o Implicit Flow

O Que É o Entra ID Redirect URI Hijacking

Um Entra ID Redirect URI — a documentação da Microsoft também chama de URL de resposta — é o endpoint para o qual a Microsoft Identity Platform envia um usuário, junto com um token ou um código de autorização, depois que ele se autentica e consente. Todo registro de aplicativo que usa o fluxo de código de autorização OAuth 2.0, o fluxo de implicit grant ou o OpenID Connect deve listar previamente seus redirect URIs exatos; o Entra ID se recusa a redirecionar para qualquer outro lugar e retorna AADSTS50011 se o valor na solicitação de login não corresponder a um valor já cadastrado.

Essa etapa de correspondência é toda a fronteira de segurança. Três escolhas de configuração em um único registro de aplicativo a enfraquecem o suficiente para permitir que um atacante saia com um token válido em vez do aplicativo legítimo:

• URLs de resposta com wildcard (APP_REPLY_URL_WILDCARD) — um padrão como https://*.contoso.com em vez de uma URL exata.
• URLs de resposta em HTTP (APP_REPLY_URL_HTTP) — um redirect URI que não está restrito a https.
• Implicit grant habilitado (APP_IMPLICIT_GRANT_ENABLED) — o registro de aplicativo ainda permite que o Entra ID devolva um token de acesso ou de ID diretamente no navegador, em vez de por meio de uma troca de token via back-channel.

Cada uma delas já é High severity isoladamente no catálogo da EtcSec. Combinadas no mesmo aplicativo, elas transformam um único link de phishing em um caminho funcional de exfiltração de token — e se somam a outros riscos de registro de aplicativo que a EtcSec rastreia, como registros de aplicativo com privilégios excessivos, credenciais obsoletas e permissões perigosas do Graph API.

Como Funciona

A correspondência exata é o ponto central, wildcards a anulam

O Entra ID exige que os redirect URIs comecem com https, com uma exceção restrita para localhost durante o desenvolvimento local — http://localhost/myapp é válido, http://contoso.com/callback não é. Wildcards são um relaxamento separado e opcional da regra de correspondência, não da regra de esquema: um registro de aplicativo restrito a contas corporativas ou de estudante pode, pelo editor de manifesto do aplicativo, registrar https://*.contoso.com e fazer o Entra ID tratar qualquer subdomínio correspondente como autorizado. A própria orientação da Microsoft sobre boas práticas e limitações de redirect URI é explícita ao dizer que isso deve ser evitado: segundo a RFC 6749 seção 3.1.2, um endpoint de redirecionamento deve ser uma URI absoluta, e quando uma entrada wildcard corresponde, o Entra remove a query string e o fragmento do redirect — que é justamente onde um token do implicit flow também estaria.

A RFC 9700, a Security Best Current Practice de OAuth 2.0 da IETF, vai além de "evitar": ela exige que servidores de autorização usem correspondência exata de string para redirect URIs, com a única exceção do número de porta em URIs localhost de aplicativos nativos. A justificativa é concreta — implementações ingênuas de wildcard já permitiram que atacantes registrassem algo como attacker.example/.somesite.example e passassem por uma correspondência de substring, e mesmo um tratamento correto de wildcard ainda deixa o takeover de subdomínio como um caminho real: qualquer subdomínio que um atacante consiga configurar — um CNAME abandonado, um host de desenvolvimento esquecido — se torna um destino de redirect válido no momento em que corresponde ao padrão.

O implicit grant entrega o token a quem estiver com a URL

O fluxo de código de autorização mantém a troca de token em um back-channel: o navegador só vê um código de curta duração, que o aplicativo depois troca por um token servidor a servidor. O implicit grant pula essa etapa — o Entra ID retorna o token de acesso ou de ID diretamente na resposta de /authorize, anexado ao fragmento do redirect URI. Esse comportamento é controlado por registro de aplicativo por meio de duas propriedades do Microsoft Graph no recurso web do aplicativo: implicitGrantSettings.enableIdTokenIssuance e implicitGrantSettings.enableAccessTokenIssuance. Se qualquer uma for true, o aplicativo pode solicitar um response_type token ou id_token e receber um token de volta sem nenhuma troca no lado do servidor.

A RFC 9700, seção 2.1.2, é direta sobre a consequência: os clientes "SHOULD NOT use the implicit grant … unless access token injection in the authorization response is prevented and the aforementioned token leakage vectors are mitigated." Os vetores de vazamento listados ali não são chamativos, mas são reais — um token em um fragmento de URL pode acabar no histórico do navegador, ser reanexado pelo user agent em redirecionamentos, ou vazar por um cabeçalho Referer para um site de terceiros para o qual a página que contém o token aponta. Além disso, um token do implicit flow não tem vínculo com o remetente (sender-constraining): nada o vincula ao cliente para o qual foi emitido, então uma cópia vale tanto quanto o original. A própria documentação da Microsoft sobre o fluxo implicit grant chegou à mesma conclusão por um caminho diferente — navegadores bloqueando cookies de terceiros quebraram a etapa de renovação silenciosa do fluxo — e hoje instrui desenvolvedores diretamente a não usá-lo, apontando para a RFC 9700 seção 2.1.2 e recomendando a migração para o fluxo de código de autorização.

A Cadeia de Ataque

Passo 1 — Encontrar ou sequestrar um destino de redirect que corresponda

Se o registro de aplicativo alvo carrega APP_REPLY_URL_WILDCARD — digamos, https://*.contoso.com/auth —, o atacante não precisa comprometer o domínio principal. Qualquer subdomínio que resolva, incluindo um de um ambiente de desenvolvimento abandonado ou um registro DNS pendente deixado por um serviço desativado, corresponde ao padrão e se torna um destino de redirect com aparência legítima para o Entra ID.

Passo 2 — Solicitar um token em vez de um código

Com APP_IMPLICIT_GRANT_ENABLED configurado no aplicativo, o atacante monta uma URL de login contra o client_id real com response_type=token (ou id_token token) e redirect_uri apontando para o endpoint correspondente que controla, e a entrega como um link de phishing. A vítima se autentica na página real de login do Entra ID — não há formulário de login falso para identificar — e o Entra ID redireciona o navegador de volta para o endpoint do atacante com o token anexado.

Passo 3 — Capturar o token em texto claro

Quando APP_REPLY_URL_HTTP também está presente, ou quando o endpoint controlado pelo atacante simplesmente registra o que recebe, o token que viaja na URL pode ser capturado diretamente, registrado por um proxy, ou exposto por meio dos vetores de vazamento documentados na RFC 9700 — histórico do navegador, cabeçalhos Referer em links de saída da página de destino, ou reanexação durante um redirecionamento adicional.

Passo 4 — Reutilizar o token sem precisar de client secret

Como o implicit grant emite um bearer token sem vínculo com o remetente, o atacante o usa diretamente contra o Microsoft Graph ou qualquer recurso para o qual ele tinha escopo, como se fosse a vítima, enquanto ele permanecer válido. Não há refresh token nesse fluxo, então a janela é limitada pelo tempo de vida do access token — mas nada além disso fica entre a captura e a reutilização. Esse é um mecanismo diferente do phishing de consentimento OAuth, que induz um usuário a autorizar um aplicativo malicioso em vez de interceptar um token destinado a um aplicativo legítimo — mas ambos terminam com um atacante em posse de uma credencial válida para o seu tenant.

Detecção

A configuração de redirect URI e as configurações de implicit grant residem no objeto do aplicativo, não em logs de atividade de login — portanto, isso é uma verificação de inventário contra o Microsoft Graph, não uma consulta de SIEM:

No Microsoft Entra admin center, a mesma informação fica visível por aplicativo em Registros de aplicativo → [aplicativo] → Autenticação: a lista de redirect URI da plataforma Web e as caixas de seleção Implicit grant e fluxos híbridos para tokens de ID e de acesso.

Remediation

1. Substitua redirect URIs com wildcard por URIs exatos e absolutos. Liste cada endpoint de callback real individualmente, em vez de um padrão. Se o número de subdomínios tornar isso inviável, a Microsoft documenta uma alternativa com parâmetro state: um único redirect URI compartilhado e protegido contra CSRF, mais um valor state específico do aplicativo, em vez de uma correspondência wildcard.
2. Remova qualquer redirect URI http:// que não seja localhost. O Entra ID já rejeita novas entradas sem https fora de localhost, mas registros de aplicativo legados podem carregar uma entrada de antes dessa restrição ser aplicada; verifique web.redirectUris diretamente, em vez de supor que o admin center teria bloqueado isso na criação.
3. Desative o implicit grant. Defina tanto implicitGrantSettings.enableIdTokenIssuance quanto enableAccessTokenIssuance como false (ou desmarque as duas caixas no portal), a menos que uma integração legada dependa explicitamente delas.
4. Migre para o fluxo de código de autorização com PKCE. A RFC 9700, seção 2.1.1, exige PKCE para clientes públicos e recomenda para clientes confidenciais; as bibliotecas MSAL da Microsoft já implementam a troca de código e o desafio PKCE, então isso costuma ser uma troca de biblioteca, não um projeto de implementação de protocolo.
5. Reverifique a plataforma após a migração. Um single-page app que ainda precisa de um fluxo apenas no navegador deve migrar para o fluxo de código de autorização com PKCE na plataforma SPA, e não permanecer em Web com o implicit grant habilitado.

Como a EtcSec Detecta Isso

O audit de Azure da EtcSec lê, via Microsoft Graph, o web.redirectUris e o web.implicitGrantSettings de cada registro de aplicativo, e sinaliza APP_REPLY_URL_WILDCARD para qualquer entrada wildcard, APP_REPLY_URL_HTTP para qualquer entrada http:// que não seja localhost, e APP_IMPLICIT_GRANT_ENABLED quando qualquer uma das flags de implicit grant estiver true — todas as três restritas à plataforma Web, como observado acima. Esse grupo é parte de uma revisão mais ampla; veja nosso guia prático para auditar a segurança do Microsoft Entra ID para a lista completa além de registros de aplicativo.