<summary><strong>Aprenda hacking AWS do zero ao herói com</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Se você deseja ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF** Confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Adquira o [**swag oficial PEASS & HackTricks**](https://peass.creator-spring.com)
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Junte-se ao** 💬 [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-nos** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Compartilhe seus truques de hacking enviando PRs para o** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repositórios do github.
O OAuth oferece várias versões, com informações fundamentais acessíveis na [documentação do OAuth 2.0](https://oauth.net/2/). Esta discussão se concentra principalmente no amplamente utilizado [tipo de concessão de código de autorização OAuth 2.0](https://oauth.net/2/grant-types/authorization-code/), fornecendo um **framework de autorização que permite que um aplicativo acesse ou execute ações na conta de um usuário em outro aplicativo** (o servidor de autorização).
Considere um site hipotético _**https://exemplo.com**_, projetado para **mostrar todas as suas postagens em redes sociais**, incluindo as privadas. Para alcançar isso, o OAuth 2.0 é empregado. _https://exemplo.com_ solicitará sua permissão para **acessar suas postagens em redes sociais**. Consequentemente, uma tela de consentimento aparecerá em _https://redesocial.com_, detalhando as **permissões solicitadas e o desenvolvedor fazendo a solicitação**. Após sua autorização, _https://exemplo.com_ ganha a capacidade de **acessar suas postagens em seu nome**.
- **dono do recurso**: Você, como **usuário/entidade**, autoriza o acesso ao seu recurso, como suas postagens em redes sociais.
- **servidor de recursos**: O **servidor que gerencia solicitações autenticadas** após o aplicativo ter obtido um `token de acesso` em nome do `dono do recurso`, por exemplo, **https://redesocial.com**.
- **aplicativo cliente**: O **aplicativo que busca autorização** do `dono do recurso`, como **https://exemplo.com**.
- **servidor de autorização**: O **servidor que emite `tokens de acesso`** para o `aplicativo cliente` após a autenticação bem-sucedida do `dono do recurso` e a obtenção de autorização, por exemplo, **https://redesocial.com**.
- **client\_id**: Um identificador público e único para o aplicativo.
- **client\_secret:** Uma chave confidencial, conhecida apenas pelo aplicativo e pelo servidor de autorização, usada para gerar `tokens de acesso`.
- **escopo**: O **nível de acesso** que o `aplicativo cliente` está solicitando do `dono do recurso`.
- **redirect\_uri**: A **URL para a qual o usuário é redirecionado após a autorização**. Isso geralmente deve estar alinhado com a URL de redirecionamento pré-registrada.
- **state**: Um parâmetro para **manter dados durante o redirecionamento do usuário para e do servidor de autorização**. Sua singularidade é crítica para servir como um **mecanismo de proteção CSRF**.
- **grant\_type**: Um parâmetro que indica **o tipo de concessão e o tipo de token a ser retornado**.
- **código**: O código de autorização do `servidor de autorização`, usado em conjunto com `client_id` e `client_secret` pelo aplicativo cliente para adquirir um `token de acesso`.
- **token de acesso**: O **token que o aplicativo cliente usa para solicitações de API** em nome do `dono do recurso`.
- **refresh\_token**: Permite que o aplicativo **obtenha um novo `token de acesso` sem solicitar novamente a permissão do usuário**.
1. Você navega até [https://exemplo.com](https://exemplo.com) e seleciona o botão "Integrar com Redes Sociais".
2. O site então envia uma solicitação para [https://redesocial.com](https://redesocial.com) pedindo sua autorização para permitir que o aplicativo de https://exemplo.com acesse suas postagens. A solicitação é estruturada da seguinte forma:
5. https://example.com utiliza este `código`, juntamente com seu `client_id` e `client_secret`, para fazer uma solicitação do lado do servidor para obter um `access_token` em seu nome, permitindo o acesso às permissões às quais você consentiu:
6. Finalmente, o processo é concluído quando https://example.com utiliza seu `access_token` para fazer uma chamada de API para as Redes Sociais para acessar
O `redirect_uri` é crucial para a segurança nas implementações de OAuth e OpenID, pois direciona para onde os dados sensíveis, como códigos de autorização, são enviados pós-autorização. Se mal configurado, poderia permitir que atacantes redirecionassem essas solicitações para servidores maliciosos, possibilitando a tomada de controle da conta.
As técnicas de exploração variam com base na lógica de validação do servidor de autorização. Podem variar desde a correspondência estrita de caminhos até a aceitação de qualquer URL dentro do domínio ou subdiretório especificado. Métodos comuns de exploração incluem redirecionamentos abertos, travessia de caminho, exploração de regex fracos e injeção de HTML para roubo de token.
Além do `redirect_uri`, outros parâmetros do OAuth e OpenID como `client_uri`, `policy_uri`, `tos_uri` e `initiate_login_uri` também são suscetíveis a ataques de redirecionamento. Esses parâmetros são opcionais e seu suporte varia entre os servidores.
Para aqueles visando um servidor OpenID, o ponto de descoberta (`**.well-known/openid-configuration**`) frequentemente lista detalhes valiosos de configuração como `registration_endpoint`, `request_uri_parameter_supported` e "`require_request_uri_registration`. Esses detalhes podem auxiliar na identificação do ponto de registro e outras especificidades de configuração do servidor.
Conforme mencionado neste relatório de recompensa por bugs [https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html](https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html), pode ser possível que a **URL de redirecionamento esteja sendo refletida na resposta** do servidor após o usuário se autenticar, sendo **vulnerável a XSS**. Payload possível para teste:
Nas implementações do OAuth, o uso indevido ou omissão do **parâmetro `state`** pode aumentar significativamente o risco de ataques de **Cross-Site Request Forgery (CSRF)**. Essa vulnerabilidade surge quando o parâmetro `state` não é usado, é usado como um valor estático ou não é validado corretamente, permitindo que os atacantes ignorem as proteções contra CSRF.
Os atacantes podem explorar isso interceptando o processo de autorização para vincular sua conta à conta de uma vítima, levando a possíveis **tomadas de controle de conta**. Isso é especialmente crítico em aplicações onde o OAuth é usado para **fins de autenticação**.
Exemplos do mundo real dessa vulnerabilidade foram documentados em vários desafios de **CTF** e **plataformas de hacking**, destacando suas implicações práticas. O problema também se estende a integrações com serviços de terceiros como **Slack**, **Stripe** e **PayPal**, onde os atacantes podem redirecionar notificações ou pagamentos para suas contas.
1.**Sem Verificação de Email na Criação de Conta**: Os atacantes podem criar antecipadamente uma conta usando o email da vítima. Se a vítima posteriormente usar um serviço de terceiros para fazer login, a aplicação pode inadvertidamente vincular essa conta de terceiros à conta pré-criada do atacante, resultando em acesso não autorizado.
2.**Explorando a Verificação de Email Laxa do OAuth**: Os atacantes podem explorar serviços OAuth que não verificam emails ao se registrar no serviço e, em seguida, alterar o email da conta para o da vítima. Esse método também apresenta riscos de acesso não autorizado à conta, semelhante ao primeiro cenário, mas por meio de um vetor de ataque diferente.
Identificar e proteger os parâmetros secretos do OAuth é crucial. Enquanto o **`client_id`** pode ser divulgado com segurança, revelar o **`client_secret`** apresenta riscos significativos. Se o `client_secret` for comprometido, os atacantes podem explorar a identidade e a confiança da aplicação para **roubar `access_tokens`** e informações privadas.
Uma vulnerabilidade comum surge quando as aplicações lidam erroneamente com a troca do `code` de autorização por um `access_token` no lado do cliente em vez do lado do servidor. Esse erro leva à exposição do `client_secret`, permitindo que os atacantes gerem `access_tokens` sob a aparência da aplicação. Além disso, por meio de engenharia social, os atacantes podem escalar privilégios adicionando escopos adicionais à autorização do OAuth, explorando ainda mais o status confiável da aplicação.
Uma vez que o cliente tenha o **código e estado**, se ele estiver **refletido dentro do cabeçalho Referer** ao navegar para uma página diferente, então está vulnerável.
**[Verifique este post](https://labs.detectify.com/writeups/account-hijacking-using-dirty-dancing-in-sign-in-oauth-flows/#gadget-2-xss-on-sandbox-third-party-domain-that-gets-the-url)**
Neste relatório de recompensa por bugs: [**https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/**](https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/) você pode ver que o **token** que o **AWS Cognito** devolve ao usuário pode ter **permissões suficientes para sobrescrever os dados do usuário**. Portanto, se você puder **alterar o e-mail do usuário por um e-mail de usuário diferente**, você pode **assumir** outras contas.
Como [**mencionado neste artigo**](https://salt.security/blog/oh-auth-abusing-oauth-to-take-over-millions-of-accounts), os fluxos do OAuth que esperam receber o **token** (e não um código) podem ser vulneráveis se não verificarem se o token pertence ao aplicativo.
Isso ocorre porque um **atacante** poderia criar um **aplicativo que suporta OAuth e fazer login com o Facebook** (por exemplo) em seu próprio aplicativo. Então, uma vez que uma vítima faz login com o Facebook no **aplicativo do atacante**, o atacante poderia obter o **token OAuth do usuário fornecido ao seu aplicativo e usá-lo para fazer login no aplicativo OAuth da vítima usando o token de usuário da vítima**.
Portanto, se o atacante conseguir fazer com que o usuário acesse seu próprio aplicativo OAuth, ele poderá assumir o controle da conta da vítima em aplicativos que esperam um token e não verificam se o token foi concedido ao ID de seu aplicativo.
De acordo com [**este artigo**](https://medium.com/@metnew/why-electron-apps-cant-store-your-secrets-confidentially-inspect-option-a49950d6d51f), era possível fazer com que uma vítima abrisse uma página com um **returnUrl** apontando para o host do atacante. Essas informações seriam **armazenadas em um cookie (RU)** e em uma **etapa posterior**, o **prompt** perguntaria ao **usuário** se ele deseja conceder acesso a esse host do atacante.
Para contornar esse prompt, era possível abrir uma guia para iniciar o **fluxo OAuth** que definiria esse cookie RU usando o **returnUrl**, fechar a guia antes que o prompt fosse exibido e abrir uma nova guia sem esse valor. Assim, o **prompt não informará sobre o host do atacante**, mas o cookie será definido para ele, então o **token será enviado para o host do atacante** na redireção.
O Registro Dinâmico de Clientes no OAuth serve 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 aplicativos clientes, incluindo URLs sensíveis que podem ser explorados.
- O **Registro Dinâmico de Clientes** geralmente é mapeado para `/register` e aceita detalhes como `client_name`, `client_secret`, `redirect_uris` e URLs para logotipos ou Conjuntos de Chaves Web JSON (JWKs) via solicitações POST.
- Este recurso segue as especificações estabelecidas em **RFC7591** e **OpenID Connect Registration 1.0**, que incluem parâmetros potencialmente vulneráveis ao SSRF.
- **`logo_uri`**: Um URL para o logotipo do aplicativo cliente que pode ser buscado pelo servidor, desencadeando SSRF ou levando a XSS se o URL for manipulado incorretamente.
- **`jwks_uri`**: Um URL para o documento JWK do cliente, que se for maliciosamente elaborado, pode fazer com que o servidor faça solicitações de saída para um servidor controlado pelo atacante.
- **`sector_identifier_uri`**: Faz referência a um array JSON de `redirect_uris`, que o servidor pode buscar, criando uma oportunidade de SSRF.
- **`request_uris`**: Lista URIs de solicitação permitidos para o cliente, que podem ser explorados se o servidor buscar esses URIs no início do processo de autorização.
- SSRF pode ser acionado registrando um novo cliente com URLs maliciosos em parâmetros como `logo_uri`, `jwks_uri` ou `sector_identifier_uri`.
- Embora a exploração direta via `request_uris` possa ser mitigada por controles de lista branca, fornecer um `request_uri` pré-registrado controlado pelo atacante pode facilitar o SSRF durante a fase de autorização.
