Checklist de OAuth: Técnicas de Ataque em OAuth 2.0 e OIDC para Pentest de Aplicações
Este artigo detalha um checklist abrangente de técnicas de ataque contra implementações de OAuth 2.0 e OpenID Connect (OIDC), focado em testes de penetração de aplicações web. Explora vulnerabilidades comuns e vetores de ataque para ajudar profissionais de segurança a identificar e mitigar riscos.
MundiX News·13 de maio de 2026·7 min de leitura·👁 4 views
Checklist de OAuth: Técnicas de Ataque em OAuth 2.0 e OIDC para Pentest de Aplicações
Os protocolos OAuth 2.0 e OIDC são amplamente utilizados hoje em dia. No entanto, os desenvolvedores podem interpretar as especificações desses protocolos de maneiras distintas ao implementá-los em aplicações. Se as questões de segurança não forem consideradas intencionalmente, as implementações podem apresentar configurações incorretas (misconfigurations) que levam a vulnerabilidades perigosas, como o sequestro de contas (Account Takeover - ATO).
Este artigo compila uma lista de técnicas de teste de segurança atuais para OAuth 2.0 e OIDC que podem ser utilizadas em testes de aplicações reais. Para cada técnica, descreveremos brevemente o que ela representa, quais sinais indicam que um ataque é possível e apresentaremos um vetor de ataque geral.
É importante notar que esta lista não é universal e pode não considerar alguns aspectos contextuais, falhas lógicas e outras deficiências de segurança que são difíceis de generalizar em um vetor comum. Em outras palavras, a lista inclui verificações necessárias, mas não necessariamente suficientes, nas implementações dos protocolos.
Além disso, o artigo não discutirá os conceitos básicos dos protocolos, focando principalmente em aplicações web (clientes privados) que frequentemente implementam o fluxo de código de autorização (authorization code flow).
Informações Adicionais:
Para saber mais sobre como OAuth 2.0 e OIDC são usados e como funcionam, leia os artigos "OAuth do zero. Explorando o protocolo e analisando ataques básicos ao OAuth" e "Após o OAuth. Analisando ataques ao OpenID Connect".
Por fim, um último aviso: o artigo abordará as técnicas de forma bastante superficial e sem todos os detalhes, pois o escopo e o volume de material não permitem isso. O foco principal será cobrir OAuth/OIDC com o máximo de técnicas disponíveis. Sempre que possível, deixaremos links para artigos e pesquisas onde o tema é abordado mais profundamente.
A tarefa do artigo é fornecer material prático, mostrar exatamente o que observar e quais sinais podem indicar deficiências na implementação do protocolo em aplicações web.
O formato das listas de sinais de reprodutibilidade é o seguinte: sinal de vulnerabilidade existente → o que pode ser feito com isso.
Abreviações utilizadas no artigo:
AS (Authorization Server): Servidor de autorização, onde o usuário se autentica diretamente.
IdP (Identity Provider): Outro nome para o servidor de autorização, o provedor.
OP (OpenID Provider): Provedor de autorização, mas no contexto do OIDC.
RP (Relying Party): Aplicação cliente.
XSS
Primeiro, vamos analisar todos os casos de XSS em uma aplicação que implementa login via OAuth/OIDC. Naturalmente, falaremos de situações em que a sessão não está acessível via JavaScript; caso contrário, seria um "game over" para o ATO (Account Takeover). Aqui, estamos falando da interceptação do código (code) com posterior troca por um token.
Se o Origin da aplicação cliente tiver XSS ou outra forma de executar JavaScript arbitrário, isso pode levar imediatamente a um ATO, mesmo que o PKCE (Proof Key for Code Exchange) esteja presente. Isso ocorre porque podemos iniciar o fluxo de autorização a partir da janela pai e teremos acesso à URL da janela filha (que pode conter o código de autorização).
Informação: O PKCE, em essência, faz uma coisa: permite garantir que o lado que completa o fluxo de código de autorização é o mesmo lado que o iniciou. Isso protege contra injeção/interceptação de código, pois apenas o valor do código não é suficiente para trocá-lo por um token; o code_verifier também é necessário. Se o pedido de autorização (authorization request) contém um code_challenge, significa que o PKCE está sendo utilizado.
Sinais de Vulnerabilidade em OAuth + OIDC
Existe vulnerabilidade com execução de JS em um Origin confiável.
Qualquer response_mode é utilizado (fragment, query, web message response mode), exceto form_post. O modo form_post não permite a leitura do código na parte cliente da aplicação; o código é enviado diretamente no corpo da requisição POST para o callback a partir da página do Servidor de Autorização.
O modo form_post é um método de resposta em OAuth 2.0 onde o servidor de autorização, em resposta a uma requisição de código de autorização (authorization code request), não retorna um 302 redirect com os parâmetros code/state e redirecionamento para redirect_url, mas sim um 200 OK com um formulário oculto em seu próprio Origin, que envia uma requisição POST para o backend do cliente com o code no corpo da requisição. Essa abordagem limita severamente o roubo de código, mas não o elimina.
Vetor de Ataque Geral com XSS
Se não houver PKCE:
Encontrar uma maneira de injetar JS na aplicação cliente.
Iniciar o fluxo OAuth/OIDC a partir do JS (em um frame ou nova janela).
Provocar a interrupção do fluxo OAuth no RP (veja a seção "Gadgets SSO. Ataque Dirty Dancing").
Obter o code/token da janela ou iframe usando JavaScript. Um Origin idêntico permite fazer isso.
Utilizar o código obtido para trocá-lo por um token ou sessão.
Se houver PKCE:(O conteúdo adicional sobre ataques com PKCE e outras técnicas está disponível apenas para membros da comunidade "Xakep.ru".)
O restante do conteúdo detalhado sobre as diversas técnicas de ataque, como manipulação de redirecionamento, CSRF, gadgets SSO, manipulação de acr_values, problemas de descoberta (discovery issues), PKCE downgrade, scope upgrade attack, condições de corrida (race conditions), 307 redirect exploit, vazamento de Referer header, ID spoofing, confusão de tipo de token (token type confusion), confusão de destinatário de token (token recipient confusion) e técnicas pre-ATO em SSO, não está disponível nesta prévia. Para acesso completo, é necessário tornar-se membro da comunidade "Xakep.ru".
Conclusão (Parcial)
Os protocolos OAuth 2.0 e OIDC são amplamente utilizados, mas os desenvolvedores podem interpretar as especificações de maneiras distintas ao implementá-los em aplicações. Se as questões de segurança não forem consideradas intencionalmente, as implementações podem apresentar configurações incorretas que levam a vulnerabilidades perigosas, como o sequestro de contas. Este artigo compila uma lista de técnicas de teste de segurança atuais para OAuth 2.0 e OIDC que podem ser utilizadas em testes de aplicações reais. Para cada técnica, descreveremos brevemente o que ela representa, quais sinais indicam que um ataque é possível e apresentaremos um vetor de ataque geral. É importante notar que esta lista não é universal e pode não considerar alguns aspectos contextuais, falhas lógicas e outras deficiências de segurança que são difíceis de generalizar em um vetor comum. Em outras palavras, a lista inclui verificações necessárias, mas não necessariamente suficientes, nas implementações dos protocolos. Além disso, o artigo não discutirá os conceitos básicos dos protocolos, focando principalmente em aplicações web (clientes privados) que frequentemente implementam o fluxo de código de autorização.
🛡️⚡
Pare de pesquisar. Comece a hackear.
O MundiX é seu copiloto de pentest com IA: comandos exatos, análise de outputs e próximo passo na kill chain — em segundos.
Sem cartão para começar · Planos a partir de R$49/mês
Checklist de OAuth: Técnicas de Ataque em OAuth 2.0 e OIDC para Pentest de Aplicações
Os protocolos OAuth 2.0 e OIDC são amplamente utilizados hoje em dia. No entanto, os desenvolvedores podem interpretar as especificações desses protocolos de maneiras distintas ao implementá-los em aplicações. Se as questões de segurança não forem consideradas intencionalmente, as implementações podem apresentar configurações incorretas (misconfigurations) que levam a vulnerabilidades perigosas, como o sequestro de contas (Account Takeover - ATO).
Este artigo compila uma lista de técnicas de teste de segurança atuais para OAuth 2.0 e OIDC que podem ser utilizadas em testes de aplicações reais. Para cada técnica, descreveremos brevemente o que ela representa, quais sinais indicam que um ataque é possível e apresentaremos um vetor de ataque geral.
É importante notar que esta lista não é universal e pode não considerar alguns aspectos contextuais, falhas lógicas e outras deficiências de segurança que são difíceis de generalizar em um vetor comum. Em outras palavras, a lista inclui verificações necessárias, mas não necessariamente suficientes, nas implementações dos protocolos.
Além disso, o artigo não discutirá os conceitos básicos dos protocolos, focando principalmente em aplicações web (clientes privados) que frequentemente implementam o fluxo de código de autorização (authorization code flow).
Informações Adicionais:
Para saber mais sobre como OAuth 2.0 e OIDC são usados e como funcionam, leia os artigos "OAuth do zero. Explorando o protocolo e analisando ataques básicos ao OAuth" e "Após o OAuth. Analisando ataques ao OpenID Connect".
Por fim, um último aviso: o artigo abordará as técnicas de forma bastante superficial e sem todos os detalhes, pois o escopo e o volume de material não permitem isso. O foco principal será cobrir OAuth/OIDC com o máximo de técnicas disponíveis. Sempre que possível, deixaremos links para artigos e pesquisas onde o tema é abordado mais profundamente.
A tarefa do artigo é fornecer material prático, mostrar exatamente o que observar e quais sinais podem indicar deficiências na implementação do protocolo em aplicações web.
O formato das listas de sinais de reprodutibilidade é o seguinte: sinal de vulnerabilidade existente → o que pode ser feito com isso.
Abreviações utilizadas no artigo:
AS (Authorization Server): Servidor de autorização, onde o usuário se autentica diretamente.
IdP (Identity Provider): Outro nome para o servidor de autorização, o provedor.
OP (OpenID Provider): Provedor de autorização, mas no contexto do OIDC.
RP (Relying Party): Aplicação cliente.
XSS
Primeiro, vamos analisar todos os casos de XSS em uma aplicação que implementa login via OAuth/OIDC. Naturalmente, falaremos de situações em que a sessão não está acessível via JavaScript; caso contrário, seria um "game over" para o ATO (Account Takeover). Aqui, estamos falando da interceptação do código (code) com posterior troca por um token.
Se o Origin da aplicação cliente tiver XSS ou outra forma de executar JavaScript arbitrário, isso pode levar imediatamente a um ATO, mesmo que o PKCE (Proof Key for Code Exchange) esteja presente. Isso ocorre porque podemos iniciar o fluxo de autorização a partir da janela pai e teremos acesso à URL da janela filha (que pode conter o código de autorização).
Informação: O PKCE, em essência, faz uma coisa: permite garantir que o lado que completa o fluxo de código de autorização é o mesmo lado que o iniciou. Isso protege contra injeção/interceptação de código, pois apenas o valor do código não é suficiente para trocá-lo por um token; o code_verifier também é necessário. Se o pedido de autorização (authorization request) contém um code_challenge, significa que o PKCE está sendo utilizado.
Sinais de Vulnerabilidade em OAuth + OIDC
Existe vulnerabilidade com execução de JS em um Origin confiável.
Qualquer response_mode é utilizado (fragment, query, web message response mode), exceto form_post. O modo form_post não permite a leitura do código na parte cliente da aplicação; o código é enviado diretamente no corpo da requisição POST para o callback a partir da página do Servidor de Autorização.
O modo form_post é um método de resposta em OAuth 2.0 onde o servidor de autorização, em resposta a uma requisição de código de autorização (authorization code request), não retorna um 302 redirect com os parâmetros code/state e redirecionamento para redirect_url, mas sim um 200 OK com um formulário oculto em seu próprio Origin, que envia uma requisição POST para o backend do cliente com o code no corpo da requisição. Essa abordagem limita severamente o roubo de código, mas não o elimina.
Vetor de Ataque Geral com XSS
Se não houver PKCE:
Encontrar uma maneira de injetar JS na aplicação cliente.
Iniciar o fluxo OAuth/OIDC a partir do JS (em um frame ou nova janela).
Provocar a interrupção do fluxo OAuth no RP (veja a seção "Gadgets SSO. Ataque Dirty Dancing").
Obter o code/token da janela ou iframe usando JavaScript. Um Origin idêntico permite fazer isso.
Utilizar o código obtido para trocá-lo por um token ou sessão.
Se houver PKCE:(O conteúdo adicional sobre ataques com PKCE e outras técnicas está disponível apenas para membros da comunidade "Xakep.ru".)
O restante do conteúdo detalhado sobre as diversas técnicas de ataque, como manipulação de redirecionamento, CSRF, gadgets SSO, manipulação de acr_values, problemas de descoberta (discovery issues), PKCE downgrade, scope upgrade attack, condições de corrida (race conditions), 307 redirect exploit, vazamento de Referer header, ID spoofing, confusão de tipo de token (token type confusion), confusão de destinatário de token (token recipient confusion) e técnicas pre-ATO em SSO, não está disponível nesta prévia. Para acesso completo, é necessário tornar-se membro da comunidade "Xakep.ru".
Conclusão (Parcial)
Os protocolos OAuth 2.0 e OIDC são amplamente utilizados, mas os desenvolvedores podem interpretar as especificações de maneiras distintas ao implementá-los em aplicações. Se as questões de segurança não forem consideradas intencionalmente, as implementações podem apresentar configurações incorretas que levam a vulnerabilidades perigosas, como o sequestro de contas. Este artigo compila uma lista de técnicas de teste de segurança atuais para OAuth 2.0 e OIDC que podem ser utilizadas em testes de aplicações reais. Para cada técnica, descreveremos brevemente o que ela representa, quais sinais indicam que um ataque é possível e apresentaremos um vetor de ataque geral. É importante notar que esta lista não é universal e pode não considerar alguns aspectos contextuais, falhas lógicas e outras deficiências de segurança que são difíceis de generalizar em um vetor comum. Em outras palavras, a lista inclui verificações necessárias, mas não necessariamente suficientes, nas implementações dos protocolos. Além disso, o artigo não discutirá os conceitos básicos dos protocolos, focando principalmente em aplicações web (clientes privados) que frequentemente implementam o fluxo de código de autorização.
📤 Compartilhar & Baixar
📩 Newsletter MundiX
Receba novidades de cibersegurança + um checklist de pentest grátis. Sem spam.
Ao assinar você concorda em receber e-mails. Cancele quando quiser.
