Aprenda e pratique Hacking AWS:<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">\
Aprenda e pratique Hacking GCP: <imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">](https://training.hacktricks.xyz/courses/grte)
* Confira os [**planos de assinatura**](https://github.com/sponsors/carlospolop)!
* **Junte-se ao** 💬 [**grupo do Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo do telegram**](https://t.me/peass) ou **siga**-nos no **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Compartilhe 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.
OAuth oferece várias versões, com insights fundamentais acessíveis na [documentação do OAuth 2.0](https://oauth.net/2/). Esta discussão centra-se principalmente no amplamente utilizado [tipo de concessão de código de autorização do OAuth 2.0](https://oauth.net/2/grant-types/authorization-code/), fornecendo um **quadro 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://example.com**_, projetado para **exibir todas as suas postagens em redes sociais**, incluindo as privadas. Para alcançar isso, o OAuth 2.0 é empregado. _https://example.com_ solicitará sua permissão para **acessar suas postagens em redes sociais**. Consequentemente, uma tela de consentimento aparecerá em _https://socialmedia.com_, delineando as **permissões solicitadas e o desenvolvedor que faz a solicitação**. Após sua autorização, _https://example.com_ ganha a capacidade de **acessar suas postagens em seu nome**.
* **proprietário do recurso**: Você, como o **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 `access token` em nome do `proprietário do recurso`, por exemplo, **https://socialmedia.com**.
* **aplicativo cliente**: O **aplicativo que busca autorização** do `proprietário do recurso`, como **https://example.com**.
* **servidor de autorização**: O **servidor que emite `access tokens`** para o `aplicativo cliente` após a autenticação bem-sucedida do `proprietário do recurso` e a obtenção de autorização, por exemplo, **https://socialmedia.com**.
* **response\_type**: Um valor que especifica **o tipo de token solicitado**, como `code`.
* **scope**: O **nível de acesso** que o `aplicativo cliente` está solicitando do `proprietário 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 a redireção 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**.
* **code**: 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 `access_token`.
* **access\_token**: O **token que o aplicativo cliente usa para solicitações de API** em nome do `proprietário do recurso`.
2. O site então envia uma solicitação para [https://socialmedia.com](https://socialmedia.com) pedindo sua autorização para permitir que o aplicativo de https://example.com acesse suas postagens. A solicitação é estruturada como:
5. https://example.com utiliza este `code`, 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 que você consentiu:
6. Finalmente, o processo conclui-se quando https://example.com utiliza seu `access_token` para fazer uma chamada de API para a Mídia Social para acessar
O `redirect_uri` é crucial para a segurança em implementações de OAuth e OpenID, pois direciona para onde dados sensíveis, como códigos de autorização, são enviados após a autorização. Se mal configurado, pode permitir que atacantes redirecionem essas solicitações para servidores maliciosos, possibilitando a tomada de conta.
As técnicas de exploração variam com base na lógica de validação do servidor de autorização. Elas podem variar desde correspondência estrita de caminho até aceitar 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 fracas e injeção de HTML para roubo de token.
Além do `redirect_uri`, outros parâmetros de 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 que visam um servidor OpenID, o endpoint de descoberta (`**.well-known/openid-configuration**`) frequentemente lista detalhes de configuração valiosos, como `registration_endpoint`, `request_uri_parameter_supported` e "`require_request_uri_registration`. Esses detalhes podem ajudar a identificar o endpoint de registro e outras especificidades de configuração do servidor.
Como mencionado neste relatório de bug bounty [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 testar:
Em implementações de OAuth, o uso indevido ou a omissão do **`state` parameter** pode aumentar significativamente o risco de ataques de **Cross-Site Request Forgery (CSRF)**. Essa vulnerabilidade surge quando o parâmetro `state` é **não utilizado, utilizado como um valor estático ou não validado corretamente**, permitindo que atacantes contornem 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 **account takeovers**. 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 **CTF challenges** e **hacking platforms**, 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 da Conta**: Os atacantes podem criar proativamente uma conta usando o email da vítima. Se a vítima usar posteriormente um serviço de terceiros para login, a aplicação pode inadvertidamente vincular essa conta de terceiros à conta pré-criada do atacante, levando ao acesso não autorizado.
2.**Explorando a Verificação de Email Lax do OAuth**: Os atacantes podem explorar serviços de OAuth que não verificam emails registrando-se com seu serviço e, em seguida, alterando o email da conta para o da vítima. Esse método também arrisca o acesso não autorizado à conta, semelhante ao primeiro cenário, mas através de um vetor de ataque diferente.
Identificar e proteger 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` de usuários** e informações privadas.
Uma vulnerabilidade comum surge quando as aplicações manipulam erroneamente 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 poderiam escalar privilégios adicionando escopos adicionais à autorização do OAuth, explorando ainda mais o status de confiança da aplicação.
Uma vez que o cliente tenha o **code and state**, se estiver **refletido dentro do cabeçalho Referer** quando ele navega para uma página diferente, então está vulnerável.
[**Check this 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 bug bounty: [**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 **AWS Cognito** devolve ao usuário pode ter **permissões suficientes para sobrescrever os dados do usuário**. Portanto, se você puder **mudar o email do usuário para um email de usuário diferente**, pode ser capaz de **assumir** outras contas.
Como [**mencionado neste artigo**](https://salt.security/blog/oh-auth-abusing-oauth-to-take-over-millions-of-accounts), fluxos de 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 login com Facebook** (por exemplo) em seu próprio aplicativo. Então, uma vez que uma vítima faça login com Facebook no **aplicativo do atacante**, o atacante poderia obter o **token OAuth do usuário dado ao seu aplicativo e usá-lo para fazer login no aplicativo OAuth da vítima usando o token do 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 a conta da vítima em aplicativos que esperam um token e não estão verificando se o token foi concedido ao ID do 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. Essa informação seria **armazenada em um cookie (RU)** e em um **passo 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 aba para iniciar o **fluxo OAuth** que configuraria esse cookie RU usando o **returnUrl**, fechar a aba antes que o prompt fosse exibido e abrir uma nova aba sem esse valor. Assim, o **prompt não informará sobre o host do atacante**, mas o cookie seria configurado para ele, então o **token será enviado para o host do atacante** na redireção.
Como explicado em [**este vídeo**](https://www.youtube.com/watch?v=n9x7\_J\_a\_7Q), algumas implementações de OAuth permitem indicar o parâmetro **`prompt`** GET como None (**`&prompt=none`**) para **evitar que os usuários sejam solicitados a confirmar** o acesso concedido em um prompt na web se já estiverem logados na plataforma.
Como [**explicado neste vídeo**](https://www.youtube.com/watch?v=n9x7\_J\_a\_7Q), pode ser possível indicar o parâmetro **`response_mode`** para indicar onde você deseja que o código 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 parâmetro de fragmento da URL `#code=2397rf3gu93f`
*`response_mode=form_post` -> O código é fornecido dentro de um formulário POST com um input chamado `code` e o valor
*`response_mode=web_message` -> O código é enviado em uma mensagem post: `window.opener.postMessage({"code": "asdasdasd...`
O Registro Dinâmico de Clientes em 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 exploradas.
* **Registro Dinâmico de Clientes** é frequentemente 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 requisições POST.
* Este recurso adere às especificações estabelecidas em **RFC7591** e **OpenID Connect Registration 1.0**, que incluem parâmetros potencialmente vulneráveis a SSRF.
* **`logo_uri`**: Uma URL para o logotipo do aplicativo cliente que pode ser buscada pelo servidor, acionando SSRF ou levando a XSS se a URL for mal manipulada.
* **`jwks_uri`**: Uma URL para o documento JWK do cliente, que se for maliciosamente elaborado, pode fazer com que o servidor faça requisições externas 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 as URIs de solicitação permitidas para o cliente, que podem ser exploradas se o servidor buscar essas URIs no início do processo de autorização.
* SSRF pode ser acionado registrando um novo cliente com URLs maliciosas 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 e controlado pelo atacante pode facilitar SSRF durante a fase de autorização.
Aprenda e pratique Hacking AWS:<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">\
Aprenda e pratique Hacking GCP: <imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">](https://training.hacktricks.xyz/courses/grte)
* Verifique os [**planos de assinatura**](https://github.com/sponsors/carlospolop)!
* **Junte-se ao** 💬 [**grupo do Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo do telegram**](https://t.me/peass) ou **siga-nos** no **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Compartilhe 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.
