Falha nos protocolos OAuth 2.0 e OpenID? Entenda com exemplos

05 May 2014

Falha nos protocolos OAuth 2.0 e OpenID? Entenda com exemplos

Mystic

Ao redor do globo, estão circulando notícias a respeito de uma possível falha de "Covert Redirect" nos protocolos OAuth 2.0 e OpenID, que parece ser pior do que o Heartbleed. Para piorar, os provedores Google, Facebook e outros gigantes afirmam que não irão corrigir. Afinal, o que está acontecendo com este planeta?

Primeiro as coisas mais importantes!

1) Se você não conhece nada sobre OAuth, assista a estas duas apresentações:

2) Não se trata de uma falha na especificação desses protocolos. A própria especificação do OAuth 2.0 já mencionava que os redirecionamentos abertos (Open Redirects) poderiam ocorrer se a implementação não fosse eficiente.

Definição de Open Redirect:

Open Redirect é uma falha que permite que um site redirecione para qualquer outro. Por exemplo:
- http://site.com/redirect.aspx?redirect=http://site-escolhido-pelo-usuario.com
- site.com pode não validar para qual URL ele redirecionará o usuário com base no parâmetro redirect da URL, resultando em uma falha de Open Redirect.

Trecho da especificação do OAuth 2.0:

10.15.  Open Redirectors

   The authorization server, authorization endpoint, and client
   redirection endpoint can be improperly configured and operate as open
   redirectors.  An open redirector is an endpoint using a parameter to
   automatically redirect a user-agent to the location specified by the
   parameter value without any validation.

   Open redirectors can be used in phishing attacks, or by an attacker
   to get end-users to visit malicious sites by using the URI authority
   component of a familiar and trusted destination.  In addition, if the
   authorization server allows the client to register only part of the
   redirection URI, an attacker can use an open redirector operated by
   the client to construct a redirection URI that will pass the
   authorization server validation but will send the authorization code
   or access token to an endpoint under the control of the attacker.

Falha na implementação? Me conte mais.

Considere o seguinte cenário:

Usuário acessa exemplo.com/perfil
Exemplo.com identifica que o usuário não está logado e o redireciona para https://google.com/autorizar/?callback=http://exemplo.com
Usuário autoriza o compartilhamento de informações do Google com o Exemplo.com
O Google redireciona o usuário de volta para o Exemplo.com (URL de callback) fornecendo o token de acesso aos dados do usuário
O Exemplo.com utiliza o token de acesso no Google e obtém os dados do usuário
Usuário acessa exemplo.com/perfil
Usuário consegue ver seus dados, incrível :)

P: E se... a URL de callback for para um atacante?
R: Nesse caso, o atacante seria capaz de obter o token de acesso, que pode ser utilizado contra o provedor (no caso, o Google) para obter os dados do usuário.

P: E como o atacante altera a URL de callback?
R:

Ele pode copiar o mecanismo de autenticação, alterar a URL de callback e hospedá-lo em um site malicioso, enviando o link para as vítimas acessarem. No entanto, apenas alterar a URL de callback pode não funcionar.

Por quê? Porque dois controles de segurança devem ser contornados para que isso aconteça. Esses dois controles são:

1) O provedor (Google) deve aceitar apenas callbacks previamente registrados pelo cliente (Exemplo.com) 2) O Exemplo.com não deve aceitar redirecionamentos ou deve aceitar apenas redirecionamentos controlados por uma lista branca (whitelist)

Mesmo que o primeiro controle exista, se o Exemplo.com tiver alguma falha de Open Redirect, o atacante pode alterar a URL de callback para algo como exemplo.com/?redirect=http://malicioso.com.

Isso explica o motivo pelo qual os gigantes como o Google e o Facebook dizem que "não irão corrigir", pois se trata de uma falha de Open Redirect em terceiros e não nos próprios provedores, exceto pelo primeiro controle que mencionei. Em relação a esse primeiro controle, o LinkedIn já está tomando as providências necessárias: https://developer.linkedin.com/blog/register-your-oauth-2-redirect-urls

Bônus: infelizmente, o Open Redirect é incentivado pelos provedores de email marketing para realizar o rastreamento de links, como apontado por Egor Homakov (quem descobriu a atribuição em massa no Rails):

http://support.elasticemail.com/kb/general-faq/why-do-my-links-route-through-the-elasticemailcom-domain-and-then-get-redirected-to-the-destination-url (link quebrado)
http://elasticemail.com/post/what-is-a-custom-tracking-domain-and-why-is-it-important

P: Se a falha é "Covert Redirect", por que você está falando de "Open Redirect"?
R:

Covert Redirect: quando um aplicativo recebe um parâmetro e redireciona o usuário com validação insuficiente.

Open Redirect: quando um aplicativo recebe um parâmetro e redireciona o usuário sem validações, pura negligência.

No contexto do OAuth, seria Covert Redirect porque existe uma confiança entre o provedor e o cliente que não é verificada. No entanto, no fim das contas, trata-se de uma falha de Open Redirect, e devemos encará-la como tal.

Proteja-se!

Evite realizar redirecionamentos por meio de parâmetros fornecidos pelo usuário (reduza a superfície de ataque);
Caso precise realizar redirecionamentos, utilize uma lista branca (whitelist), ou seja, uma lista controlada de URLs para as quais sua aplicação pode redirecionar os usuários.

Referências:

Falha nos protocolos OAuth 2.0 e OpenID? Entenda com exemplos

Postagens Populares

Newsletter