Você acessa o portal mente binária e, ao invés de preencher aqueles formulários gigantescos de login apenas pressiona logar-se com a sua conta Google. Escolhe seu nome de usuário e, sem inserir nenhuma senha ou outra informação você está logado na plataforma. A tecnologia utilizada para essa integração geralmente é o padrão OAuth 2.0, que permite que uma aplicação tenha acesso a alguns dados de um usuário registrado em sistemas terceiros, como o Google, sem a necessidade de conhecer as credenciais desse usuário.
É justamente essa possibilidade de não compartilhar credenciais para obter acesso à informação que contribui para a popularização da tecnologia. Imagine ter acesso a todas as informações necessárias do usuário e deixar que plataformas muito mais consolidadas cuidem da autorização, parece um caminho muito mais seguro, né?
A resposta é: depende. Como tudo na área de tecnologia, é muito importante configurar as soluções a serem utilizadas de maneira correta para evitar problemas que coloquem em risco a segurança da aplicação. Para entender alguns dos problemas que podem resultar de uma configuração insegura deste protocolo, vamos dar um passo atrás e entender como essa tecnologia funciona. Caso queira dar mais um passo para trás e ler um pouco sobre autenticação primeiro, aqui mesmo na Mente Binária tem o artigo Autenticação e Ataques Relacionados, do @Andre Smaira.
Conhecendo o protocolo OAuth 2.0
OAuth 2.0 é um protocolo de autorização que permite não só o compartilhamento de dados com aplicações de terceiros mas também o controle de quais informações serão compartilhadas. Dessa forma, após o usuário conceder a uma aplicação (como o portal Mente Binária) algumas de suas informações (nesse caso, as disponíveis em sua conta Google), é possível interagir com o portal sem a necessidade de se autenticar na aplicação.
A figura a seguir demonstra uma visão geral de como esse processo acontece, conforme apresentada na RFC 6749:
Na figura acima, é possível perceber a existência de três agentes no funcionamento desse protocolo:
- O cliente (Client). Representado em cinza na figura, representa a Mente Binária ou a aplicação que estamos utilizando, e que deseja utilizar mais informações do usuário.
- O usuário que possui os dados (Resource Owner). Esse é você, que possui o poder de compartilhar ou não as suas informações.
- A aplicação que possui seus dados (Authorization Server e Resource Server). Embora em alguns casos a aplicação tenha um sistema de autenticação separado do servidor que possui esses dados (por isso a divisão na imagem), é essa aplicação que possui a informação que será compartilhada através do protocolo OAuth 2.0.
Embora essa imagem represente bem como essa comunicação ocorre de maneira geral, deixa um pouco a desejar em caráter mais técnico, visto que abstrai demais o funcionamento do protocolo. Inspirado no excelente artigo da Salt Labs sobre o tema, construí a seguinte imagem para auxiliar no entendimento do processo:
A primeira etapa ocorre quando o usuário Breno decide se cadastrar ou se autenticar no site (caso já esteja cadastrado). O site, no entanto, necessita de uma prova de que Breno é quem diz ser, e pede para que ele solicite ao Google um token aleatório que o identifique na aplicação OAuth 2.0. Isso ocorre no momento em que o usuário pressiona o botão, quando uma nova janela é aberta com uma URL análoga à seguinte:
https://accounts.google.com/o/oauth2/v2/auth/oauthchooseaccount?access_type=offline&client_id=152067940327-ma5q9tjenci55tfs3mck9fe7npphvek4.apps.googleusercontent.com&response_type=code&redirect_uri=https%3A%2F%2Fwww.mentebinaria.com.br%2Foauth%2Fcallback%2F&state=STATE&code_challenge=CODE_CHALLENGE&code_challenge_method=CODE_CHALLENGE_METHOD&scope=profile%20email&service=lso&o2v=2&flowName=GeneralOAuthFlow
Nessa URL, alguns valores são essenciais para o funcionamento do OAuth:
- client_id: Este parâmetro identifica o cliente que solicita a informação. Na URL compartilhada, esse valor corresponde ao identificador atrelado ao portal Mente Binária.
- response_type: Define o conteúdo que será retornado na resposta. Esse valor é relevante para sabermos quais problemas de segurança podem ocorrer na aplicação.
- redirect_uri: Após a autenticação, o token gerado será enviado por meio de um redirecionamento à página informada neste parâmetro. A forma como essa página é configurada também é relevante para a segurança da aplicação.
- state: Salva um estado da aplicação. Geralmente é usado como uma medida de segurança secundária. Dessa forma, se um token é devolvido à aplicação com um estado que não é conhecido por ela, ela pode considerar que algo de errado aconteceu e interromper o processo sem obter as informações do usuário.
- scope: Este campo especifica quais informações serão compartilhadas através do protocolo OAuth.
Após se autenticar e autorizar a aplicação a obter acesso a essa página, o usuário recebe um código complexo (etapas 3 e 4), identificado como authorization grant na primeira figura. Esse valor é então enviado diretamente à Google pela aplicação, que valida o usuário e as permissões aos quais esse token está atrelado, retornando esses dados a aplicação solicitante (etapas 6 e 7).
Após todo esse processo, a aplicação pode atrelar esse valores à sessão do usuário e até armazená-los no banco de dados, possibilitando a autenticação de um visitante na página sem a necessidade de digitar, ou até mesmo possuir, uma senha para a aplicação.
Problemas de segurança associados ao uso de OAuth 2.0
A ideia é muito boa, mas deve ser implementada com cuidado, visto que a utilização errada da aplicação pode levar a graves incidentes de segurança. A seguir, eu listo alguns problemas associado ao uso ou configuração insegura da tecnologia.
Pre-account Takeover
Embora a prática de se utilizar o OAuth para se autenticar nas aplicações tenha se difundido, ela raramente substitui por completo a existência de uma autenticação oferecida pela aplicação. Dessa forma, é preciso dobrar também a cautela durante a implementação. A imagem a seguir demonstra como o portal Mente Binária permite ambas as formas de se registrar:
O aumento na complexidade de uma aplicação também resulta em mais cuidados de segurança. Para este cenário, suponha que você se registrou no portal utilizando o e-mail de um conhecido, que ainda não se registrou no ambiente, usando uma senha de sua escolha. No entanto, como você não tem acesso ao conteúdo do endereço de e-mail, você é incapaz de confirmar a identidade (através do recurso de confirmação de e-mail) e começar a utilizar a plataforma. Caso a aplicação não tenha sido configurada de maneira correta, como demonstra esse report da HackerOne, se a vítima um dia decidir se autenticar no ambiente utilizando o OAuth como opção, o ambiente automaticamente irá validar o acesso criado usando o endereço de email, possibilitando que o atacante consiga acessar a conta da vítima através da senha que foi previamente configurada. Portanto, é necessário sempre ter atenção sobre as diferenças e implicações dos dois mecanismos paralelos de registro e autenticação na plataforma para garantir que o ambiente fique realmente seguro.
Open Redirects
Outro fator que pode levar a diversos problemas de segurança na aplicação é a configuração insegura das validações do parâmetro redirect_uri. Conforme comentado durante a explicação do protocolo, após se registrar com sucesso na aplicação, o usuário é redirecionado para a página presente neste parâmetro e, junto com esse redirecionamento, o token de acesso é enviado através do fragmento de hash presente na URL.
Se não houver validações suficientemente seguras desse parâmetro, um atacante pode enviar à vítima um link da página de login OAuth porém substituindo o conteúdo do parâmetro por um endereço controlado pelo atacante. Dessa forma, ao realizar o login, o token de authorization grant será enviado à uma página controlada pelo atacante e não à página que espera este parâmetro na aplicação. Este cenário pode ser observado nesse report. É preciso se atentar também ao fato de que, mesmo que haja validação do domínio da URL no parâmetro, o diretório para o qual essa URL aponta também deve ser validado, visto que se a página possuir um open redirect em algum outro diretório, um atacante poderá abusar desse comportamento para substituir o parâmetro para uma página em que ele é capaz de forçar um redirecionamento e, assim, obter também acesso ao conteúdo do token. O artigo da Salt Labs mencionando anteriormente demonstra de maneira muito bem explicada como esse ataque pôde ser realizado na aplicação do Booking. Já neste outro report da HackerOne, é possível visualizar que permitir o uso de outros subdomínios do site principal nesse parâmetro também pode facilitar que um atacante encontre e abuse de um open redirect para roubar tokens válidos no ambiente. Por fim, neste report super bem explicado, outro membro do ELT, @caioluders (twitter.com/caioluders), demonstra como é preciso estar atento a forma como essa validação é feita, para que o atacante não encontre uma forma de evadir esse mecanismo de segurança.
Leakando a URL
Mesmo que não haja possibilidade de se obter o token de acesso através do abuso do parâmetro redirect_uri, um atacante pode encontrar outras formas de obtê-lo diretamente através da URL. Neste report, por exemplo, o pesquisador utilizou do próprio design da aplicação para roubar tokens, visto que um usuário poderia criar uma página com seu próprio Google Analytics, que registra o conteúdo da página. Vale lembrar que, conforme descrito durante a explicação do protocolo, embora muitas vezes esse token tenha funcionamento único, o atacante pode utilizar um valor que não será aceito como parâmetro state. Dessa forma, ao receber o token, a aplicação tentará validar seu estado e o recusará devido ao valor inesperado. Assim, o atacante será capaz de, através do meio encontrado para vazar esse valor, utilizá-lo de maneira válida.
PostMessage
Versões mais recentes do OAuth 2.0 utilizam o método postMessage() como uma forma considerada segura de realizar o envio e recebimento dos tokens de uma aplicação. Neste report, um pesquisador demonstra que se deve tomar cuidado ao se designar a qual página será enviado o token obtido pelo OAuth. Ainda no mesmo report, o pesquisador percebe que o token é sempre enviado ao opener desse endereço e abusa desse comportamento genérico para tornar sua página o opener através da chamada windows.open() para o endereço vulnerável.
Além disso, Frans Rosén escreveu um excelente artigo sobre como alguns métodos postMessage() de bibliotecas de terceiros podem resultar no vazamento do token OAuth.
Cookie Bomb
Esta é uma vulnerabilidade que ocorre quando o atacante descobre uma forma de inserir cookies arbitrários no navegador de um usuário. Dessa forma, um atacante é capaz de inserir cookies muito grandes para um usuário, resultando em uma negação de serviço temporária deste usuário à aplicação devido ao envio de um conteúdo muito grande nas requisições. Nesta publicação, o pesquisador filedescriptor discute como essa vulnerabilidade pode ser abusada através de um XSS para impedir que a página presente no parâmetro redirect_uri de uma autenticação OAuth seja acessada e, dessa forma, o atacante possa obter acesso a esse token através do XSS, visto que o cookie bomb impediu o uso do token pela aplicação.
Para se aprofundar mais
Para ir além no assunto, veja esse artigo de um pesquisador contando como explorou o OAuth do facebook para conseguir roubar contas de usuários e confira também os write-ups de exploração de vulnerabilidades em OAuth neste repositório no GitHub. 😉
-
3
