Jump to content
  • Segurança de sistemas OAuth 2.0

       (2 reviews)

    vrechson

    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:

    fig1.png

    Na figura acima, é possível perceber a existência de três agentes no funcionamento desse protocolo:

    1. 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.
    2. O usuário que possui os dados (Resource Owner). Esse é você, que possui o poder de compartilhar ou não as suas informações.
    3. 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:

    breno2.thumb.png.e5622316a4e99c60ce790e59b02ef8db.png

    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:

    auth_mb.png

    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. 😉

     


    • Curtir 3

    User Feedback

    Join the conversation

    You can post now and register later. If you have an account, sign in now to post with your account.
    Note: Your post will require moderator approval before it will be visible.

    Guest

    • This will not be shown to other users.
    • Add a review...

      ×   Pasted as rich text.   Paste as plain text instead

        Only 75 emoji are allowed.

      ×   Your link has been automatically embedded.   Display as a link instead

      ×   Your previous content has been restored.   Clear editor

      ×   You cannot paste images directly. Upload or insert images from URL.


    nuno.sccp

      

    Olá, muito bom!

    Obrigado por compartilhar!!!

    Link to review
    Share on other sites

    welkson

       2 of 2 members found this review helpful 2 / 2 members

    Excelente artigo. Obrigado por compartilhar 👏

    Link to review
    Share on other sites


  • Similar Content

×
×
  • Create New...