Uma breve recapitulação da segurança OAuth

Introdução#

Há alguns dias, um artigo interessante sobre vulnerabilidade do OAuth nos atingiu. A-new-oauth-vulnerability-that-may-impact-hundreds-of-online-services do laboratório SALT. Este post específico destaca a vulnerabilidade descoberta no Expo, um framework amplamente utilizado para implementar OAuth e outras funcionalidades. Ele aborda especificamente uma vulnerabilidade na biblioteca expo-auth-session, que já foi designada e devidamente resolvida.

Se você se interessa por OAuth ou está trabalhando em um produto relacionado a CIAM como nós, recomendamos a leitura deste artigo. É bastante inspirador e fornece insights valiosos. Esses relatórios de white-hat servem como um lembrete de como até mesmo o recurso mais simples pode causar vulnerabilidades. Quando se trata de cibersegurança e autorização, nunca podemos ser demasiado cuidadosos em garantir a segurança e privacidade das informações do usuário. Se este artigo chamar sua atenção, acredito que você concordará fortemente conosco.

Isso me lembra do tempo em que começamos. Passamos muito tempo aprendendo e pesquisando os detalhes dos protocolos OAuth e OIDC. Foi doloroso e tedioso, mas os benefícios foram imensos. Embora talvez nem todo indivíduo em nossa equipe seja um especialista em OAuth, todos estão comprometidos em colocar um esforço contínuo em direção à segurança e meticulosidade. Com esses esforços dedicados, o produto Logto evoluiu para o que é hoje.

Graças a esta grande oportunidade, gostaríamos de refrescar nossa memória sobre alguns dos detalhes de segurança do OAuth aqui.

Uma espiada no Fluxo de Autorização OAuth#

OAuth 2.0 fornece vários fluxos de autorização atendendo a diferentes tipos de clientes e requisitos. Estes incluem o Fluxo Implícito, Fluxo de Credenciais de Cliente, Fluxo de Credenciais de Senha do Proprietário do Recurso, e Fluxo de Autorização de Dispositivo. No entanto, o Fluxo de Código de Autorização se destaca como o mais seguro e amplamente utilizado. Ao contrário de outros fluxos, ele separa a autenticação do usuário da aplicação cliente e envolve a troca de um Código de Autorização por tokens. Esta abordagem fornece uma camada adicional de segurança, já que os tokens sensíveis nunca são expostos ao cliente. Além disso, o Fluxo de Código de Autorização suporta a gestão de tokens do lado do servidor, tornando-o adequado para aplicações web que requerem robusta segurança e controle aprimorado sobre o acesso do usuário.

Aqui está um diagrama simples do Fluxo de Código de Autorização:

Vamos dar uma olhada nas duas solicitações mais cruciais feitas no fluxo de concessão de código de autorização e nos fragmentos aparentemente triviais dentro delas, mas que desempenham um papel crítico na proteção contra fraudes.

O ponto de extremidade de autorização:

O ponto de extremidade de troca de token:

Credenciais do Cliente#

No OAuth, Credenciais do Cliente se referem às credenciais usadas por uma aplicação cliente para se autenticar e se identificar para o servidor de autorização. Estas credenciais são obtidas durante o processo de registro do cliente e são usadas para validar a identidade do cliente ao fazer solicitações ao servidor de autorização. (Você pode encontrar sua credencial de cliente no console Admin do Logto quando registra sua aplicação pela primeira vez.)

As credenciais do cliente são tipicamente compostas por dois componentes:

1. ID do Cliente: Um identificador único atribuído à aplicação cliente pelo servidor de autorização. É um valor público que geralmente não é considerado sensível.
2. Segredo do Cliente: Um valor confidencial e armazenado de forma segura conhecido apenas pelo cliente e pelo servidor de autorização. Ele serve como uma forma de autenticação para a aplicação cliente e é utilizado para verificar a identidade do cliente ao fazer solicitações ao servidor de autorização.

Como você pode encontrar, a combinação de ID do Cliente e Segredo do Cliente é utilizada durante a solicitação de token para autenticar o cliente e obter Tokens de Acesso.

As credenciais do cliente desempenham um papel vital na garantia da segurança do fluxo OAuth. Elas ajudam o servidor de autorização a verificar a autenticidade das aplicações clientes e a controlar o acesso a recursos protegidos. É importante lidar com as credenciais do cliente de forma segura e protegê-las de acessos não autorizados. O Logto categoriza as aplicações clientes por dois diferentes níveis de segurança:

• Clientes confidenciais: Estes incluem aplicações web renderizadas no servidor e aplicações de máquina para máquina (M2M). No caso de clientes confidenciais, todas as credenciais relacionadas à autorização, incluindo as credenciais do cliente, são armazenadas de forma segura no lado do servidor. Além disso, todas as solicitações intermediárias de troca são criptografadas para garantir a confidencialidade dos dados. O risco de vazamento de credenciais do cliente para clientes confidenciais é muito baixo, tornando-os inerentemente mais seguros. Portanto, os clientes confidenciais são tratados com um nível de segurança mais alto por padrão. No fluxo de troca de tokens, a apresentação do Segredo do Cliente é OBRIGATÓRIA.
• Clientes públicos: Estes incluem aplicações web de página única (SPA) e aplicações nativas. Para clientes públicos, as credenciais do cliente são tipicamente codificadas no lado do cliente, como dentro de um pacote JavaScript ou um pacote de aplicação em uma plataforma nativa. O risco de vazamento de credenciais é maior em comparação com clientes confidenciais devido à exposição inerente de credenciais do cliente no código do lado do cliente. No fluxo de troca de tokens, a apresentação do Segredo do Cliente é OPCIONAL. Logto não confiará nessas credenciais de um cliente público por padrão.

State#

No fluxo OAuth, o parâmetro state é um valor gerado aleatoriamente que é incluído na solicitação de autorização enviada pelo cliente para o servidor de autorização. Seu propósito é manter o estado ou contexto da solicitação do cliente durante o processo de autorização.

O parâmetro state funciona como uma medida de segurança para prevenir ataques de falsificação de solicitação entre sites (CSRF). Quando o servidor de autorização redireciona o usuário de volta para a aplicação cliente após a autenticação e autorização, ele inclui o mesmo valor do estado na resposta. A aplicação cliente DEVE comparar este valor com o valor original do estado que enviou na solicitação de autorização.

Ao verificar o parâmetro do estado, o cliente pode garantir que a resposta recebida do servidor de autorização corresponde à solicitação inicial que fez. Isso ajuda a prevenir ataques onde um invasor tenta enganar o cliente a aceitar uma resposta destinada a outro usuário ou aplicação.

Considere o seguinte exemplo de ataque CSRF em um caso de uso ficcional:

Ataque CSRF: Fraude para vincular a conta social - problema

Com um mecanismo de validação de estado adequado, o cliente pode detectar o ataque e prevenir que o usuário seja redirecionado para o site do atacante:

Ataque CSRF: Fraude para vincular conta social - solução

PKCE#

Como mencionado anteriormente, clientes públicos como aplicativos web SPA e aplicações nativas estão com maior risco de vazamento de credenciais de autenticação, incluindo o Código de Autorização emitido pelo servidor de autorização.

PKCE significa Prova de Chave para Troca de Código. É uma extensão para o Fluxo de Código de Autorização OAuth 2.0 que aumenta a segurança de clientes públicos.

PKCE foi introduzido para mitigar o risco de um atacante interceptar o Código de Autorização e trocá-lo por um Token de Acesso sem o conhecimento do cliente. Este tipo de ataque, conhecido como interceptação de Código de Autorização, é mais prevalente em ambientes onde a aplicação cliente não pode armazenar de maneira segura um segredo do cliente.

Para implementar o PKCE, a aplicação cliente gera um Verificador de Código aleatório e deriva um Desafio de Código dele usando um algoritmo de hashing específico (geralmente SHA-256). O Desafio de Código é incluído na solicitação de autorização inicial enviada para o servidor de autorização.

Quando o servidor de autorização emite o Código de Autorização, a aplicação cliente inclui o Verificador de Código original na solicitação de token. O servidor verifica que o Verificador de Código corresponde ao Desafio de Código armazenado e somente então emite o Token de Acesso.

Usando o PKCE, a aplicação cliente garante que o Código de Autorização sozinho não é suficiente para obter um Token de Acesso. Este mecanismo adiciona uma camada extra de segurança ao fluxo de autorização, especialmente para clientes públicos onde o armazenamento de Segredos do Cliente é desafiador.

Logto usa PKCE como o ÚNICO fluxo de autorização para todas as aplicações do tipo cliente público. No entanto, PKCE pode ser omitido para aqueles clientes confidenciais.

URI de Redirecionamento#

Um Redirect URI(Uniform Resource Identifier) é um ponto de extremidade específico ou URL para o qual o servidor de autorização redireciona o usuário após o processo de autenticação e autorização no OAuth.

Durante o fluxo OAuth, a aplicação cliente inclui um Redirect URI como parte da solicitação de autorização inicial. Este URI serve como o URL de retorno de chamada para o qual o usuário será redirecionado após autenticar e conceder permissões ao cliente.

Uma vez que o usuário completa o processo de autenticação, o servidor de autorização gera uma resposta que inclui um Código de Autorização, e redireciona o usuário de volta para o Redirect URI especificado.

A validação do Redirect URI é uma etapa essencial para garantir a segurança e integridade do fluxo OAuth. Envolve a verificação de que o Redirect URI usado na solicitação de autorização e redirecionamentos subsequentes é válido e de confiança.

Vamos voltar e dar uma olhada no original relatório de vulnerabilidade do OAuth. (A seguinte seção é referenciada do original post)

Quando o usuário clica em "login com facebook" usando o APP Móvel no Expo Go, ele redireciona o usuário para o seguinte link:

https://auth.expo.io/@moreisless3/me321/start?authUrl=https://www.facebook.com/v6.0/dialog/oauth?code_challenge=...&display=popup&auth_nonce=...&code_challenge_method=S256&redirect_uri=https://auth.expo.io/@moreisless3/me321&client_id=3287341734837076&response_type=code,token&state=gBpzi0quEg&scope=public_profile,email&returnUrl=exp://192.168.14.41:19000/--/expo-auth-session

Na resposta, auth.expo.io define o seguinte cookie: ru=exp://192.168.14.41:19000/--/expo-auth-session. O valor RU será usado mais tarde como um Return Url na etapa 5. Ele então mostra ao usuário uma mensagem de confirmação, e se o usuário aprova - ele o redireciona para o login do Facebook para continuar o fluxo de autenticação

…

Esta página lê o parâmetro de consulta "returnUrl" e define o cookie de acordo.

Vamos mudar o returnUrl para hTTps://attacker.com (https não é permitido, então eu tentei inserir letras maiúsculas e funcionou), que define o RU (Return Url)no cookie para https://attacker.com.

…

No caso acima, desconsiderar os parâmetros originais redirect_uri, Expo introduziu um novo parâmetro chamado returnUrl sem validação adequada. Essa supervisão ofereceu uma oportunidade para os atacantes obterem acesso ao Código de Autorização retornado pelo Facebook. Para mais detalhes, por favor, consulte a postagem original post.

A validação de Redirecionamento URI serve para várias finalidades importantes:

1. Evitando ataques de phishing: Ao validar o Redirecionamento URI, o servidor de autorização garante que o usuário é redirecionado de volta para um endpoint confiável e autorizado. Isso ajuda a prevenir que atacantes redirecionem usuários para locais maliciosos ou não autorizados.
2. Protegendo contra redirecionamentos abertos: Redirecionamentos abertos são vulnerabilidades que podem ser exploradas para redirecionar usuários para sites maliciosos. Ao validar o Redirecionamento URI, o servidor de autorização pode garantir que o redirecionamento permaneça dentro dos limites do domínio autorizado ou conjunto de domínios confiáveis.
3. Garantindo o encaminhamento correto das respostas de autorização: Validar o Redirecionamento URI ajuda a garantir que o servidor de autorização redirecione o usuário de volta para a aplicação cliente pretendida. Isso garante que a resposta, como um Código de Autorização ou Token de Acesso, seja entregue ao destino correto.

No Logto, o registro redirect_uri é obrigatório para todos os tipos de aplicações. Comparamos e combinamos o valor recebido com os registrados no servidor Logto. Isso inclui quaisquer parâmetros de busca personalizados. Se uma solicitação de autorização falha na validação devido a um valor de redirect_uri faltante, inválido ou incompatível, um erro de URI de redirecionamento inválido será retornado para o redirect_uri registrado no arquivo.

Resumo#

Devido à sua natureza intrincada e sutil, é compreensível que esses detalhes sejam frequentemente negligenciados. Alguns são apenas uma string aleatória como o state.

No entanto, é importante notar que estas medidas de segurança adicionam camadas de proteção à autorização do usuário, mitigando riscos como ataques CSRF, interceptação de Código de Autorização e redirecionamentos não autorizados.

Estes são apenas um pequeno pedaço dos recursos de segurança abrangentes oferecidos pelo protocolo OAuth. OAuth fornece uma estrutura robusta para autenticação e autorização segura. Ele também oferece pontos de extremidade abertos e flexíveis para atender aos diversos requisitos em aplicações de produto do mundo real.

Como desenvolvedores e provedores de serviço, é imperativo priorizar continuamente a segurança do fluxo de autorização do usuário. Permanecer vigilante, aderir às melhores práticas, e manter-se atualizado com os últimos desenvolvimentos no ecossistema OAuth são essenciais para garantir a integridade e proteção das identidades dos usuários e dados sensíveis. Nós permaneceremos comprometidos em manter os mais altos padrões de segurança na implementação do OAuth e salvaguardar a privacidade e confiança de nossos usuários.