Vulnerabilidades do OAuth e Padrões de Ataque

Os servidores de autorização OAuth devem validar rigorosamente o parâmetro redirect_uri. Se o servidor permitir correspondência por prefixo ou por curinga (por exemplo, aceitar qualquer URL que comece com "https://app.example.com"), um atacante poderá criar uma solicitação de autorização que redirecione para "https://app.example.com.attacker.com/steal" ou para um redirecionamento aberto no domínio legítimo, roubando o código de autorização.

Sem proteção contra CSRF, um atacante pode iniciar um fluxo OAuth e induzir o navegador da vítima a concluir a autorização. A vítima autoriza inadvertidamente o cliente do atacante. O parâmetro "state" (RFC 6749) impede isso: o cliente gera um state aleatório, inclui-o na solicitação e verifica se ele corresponde no retorno de chamada. Uma divergência interrompe o fluxo.

Em plataformas móveis, aplicativos maliciosos podem registrar o mesmo esquema de URI personalizado que um cliente OAuth legítimo e interceptar os códigos de autorização redirecionados após a autenticação do usuário. O PKCE é a defesa completa: o código interceptado é inútil sem o verificador de código que somente o aplicativo legítimo gerou no início do fluxo.

Quando um token de ID ou token de acesso é incluído em um fragmento ou parâmetro de consulta da URL, as navegações subsequentes a partir dessa página incluem a URL no cabeçalho Referer, podendo vazar o token para scripts de análise de terceiros ou provedores de CDN. Use sempre o fluxo de código de autorização com entrega de tokens pelo canal de retaguarda para evitar que tokens apareçam nas URLs.

Quando um cliente oferece suporte a vários provedores OAuth, ataques de confusão induzem o cliente a enviar ao ponto de acesso de tokens do Provedor B um código de autorização obtido do Provedor A. O cliente deve validar a declaração "iss" nos tokens de ID e associar o retorno de chamada ao provedor específico que iniciou o fluxo, usando o parâmetro state ou JARM (Modo de Resposta de Autorização Protegida por JWT).

Ataques de falsificação de solicitação do lado do servidor (SSRF) têm como alvo implementações OAuth que fazem solicitações HTTP do lado do servidor ao redirect_uri. Se o servidor de autorização buscar o redirect_uri para verificá-lo, um atacante poderá fornecer um endereço IP interno (por exemplo, http://169.254.169.254/latest/meta-data/) para acessar metadados da instância de nuvem ou serviços internos. A validação rigorosa de redirect_uri baseada em uma lista de permissões impede isso.

Muitos aplicativos usam a declaração de email de um token de ID do OIDC para associar contas entre provedores. Se um atacante controlar um endereço de email que corresponda à conta de uma vítima em outro provedor, poderá se registrar com um provedor diferente usando esse email e obter acesso à conta da vítima. Defesa: associe contas somente pela dupla (iss, sub), nunca somente pelo email.

Ataques de confusão de algoritmo JWT exploram implementações que confiam no cabeçalho "alg" para selecionar o algoritmo de verificação. O ataque consiste em alterar "alg" de "RS256" para "HS256" e assinar o token usando a chave pública do servidor como segredo HMAC (já que a chave pública é pública). Defesa: especifique sempre o algoritmo esperado explicitamente no código de verificação; nunca confie na declaração alg do cabeçalho do token.

Atacantes registram clientes OAuth maliciosos com nomes e logotipos que parecem legítimos e depois enviam links fraudulentos aos alvos. A vítima vê uma tela de consentimento OAuth genuína (hospedada por Google, Microsoft etc.) para um aplicativo malicioso e concede acesso. Defesa: verifique se client_id corresponde ao aplicativo esperado; Google e Microsoft oferecem programas de verificação de clientes para aplicativos legítimos.

A escalada de escopo ocorre quando um cliente obtém tokens com permissões mais amplas do que aquelas autorizadas pelo usuário. Falhas de implementação que ignoram a validação de escopo no ponto de acesso de tokens, armazenam em cache tokens com escopos combinados de solicitações diferentes ou não validam que o escopo no token emitido não exceda o escopo autorizado podem levar à escalação de privilégios por meio do OAuth.

Defenda as implementações OAuth usando: validação de redirect_uri por correspondência exata, exigência de PKCE para todos os clientes públicos, validação do parâmetro state para proteção contra CSRF, associação de tokens de ID pela dupla (iss, sub), não pelo email, especificação explícita dos algoritmos JWT esperados, solicitação de escopos mínimos, uso de tokens de acesso de curta duração com rotação de tokens de atualização e auditoria da aparência da tela de consentimento quanto ao risco de personificação da marca.

Um servidor de autorização OAuth aceita qualquer redirect_uri que comece com "https://app.example.com". Que ataque isso permite?

Principais ataques do OAuth: redirecionamento aberto por validação permissiva de redirect_uri (use correspondência exata), CSRF por ausência do parâmetro state, interceptação de código em dispositivos móveis (atenuada pelo PKCE), vazamento de tokens em URLs, confusão em configurações com vários provedores (valide iss), SSRF por redirect_uri buscado pelo servidor, colisão de declarações de email (use iss+sub), confusão de algoritmo JWT (fixe o alg esperado) e phishing por telas de consentimento falsas.