Portuguese English German

Falha nos protocolos OAuth 2.0 e OpenID? Entenda com exemplos

Mystic

Por volta do globo estão sendo circuladas notícias a respeito de uma possível falha de “Covert Redirect” nos protocolos OAuth 2.0 e OpenID que parece ser pior que o Heartbleed. Para agravar, os provedores Google, Facebook e outros gigantes dizem que não irão arrumar. Afinal, o que está acontecendo com este planeta?

First things first!

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

2) Não se trata de uma falha na especificação destes protocolos. A própria especificação do OAuth 2.0 já dizia que Open Redirects poderiam acontecer 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 qual url ele redirecionará o usuário baseado 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? Conte-me mais.

Considere o seguinte cenário:

  • Usuário acessa exemplo.com/perfil
  • Exemplo.com entende que o usuário não está logado, e o redireciona o usuário para https://google.com/autorizar/?callback=http://exemplo.com
  • Usuário autoriza o compartilhamento de informações do Google para Exemplo.com
  • Google redireciona usuário para Exemplo.com (url de callback) informando o token de acesso aos dados do Usuário
  • 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, fantástico :)

Q: E se … a URL de callback for para um atacante?
A: Se for, o atacante conseguirá obter o token de acesso que pode ser utilizado contra o provedor (no caso Google) para obter os dados do usuário.

Q: E como o atacante altera a url de callback?
A:

Ele pode copiar o mecanismo de autenticação, alterar a URL de callback e hospedar em um site malicioso e enviar o link para as vítimas acessarem. Entretanto, só alterar a URL de callback pode não funcionar.

Por que não? Porque dois controles de segurança devem ser subvertidos para que isso aconteça. Os dois controles são:

1) O provider (Google) deve apenas aceitar callbacks previamente cadastrados pelo cliente (Exemplo.com) 2) Exemplo.com não deve aceitar redirects ou deve aceitar redirects controlados por uma white list

Mesmo que exista o primeiro controle, se 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.

Isto explica o motivo do “won’t fix” dos gigantes como Google e Facebook, porque se trata de uma falha de open redirect em terceiros e não nos provedores propriamente ditos, exceto pelo 1º controle que mencionei. A respeito deste 1º controle, o LinkedIn já está tomando as providências: 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 tracking de links, conforme Egor Homakov (quem descobriu o mass assignment no rails) aponta:

Q: Se a falha é “Covert Redirect”, por que você está falando de “Open Redirect”?
A:

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

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

No contexto do OAuth, seria Covert Redirect porque há uma confiança entre provedor/cliente que não é verificada. Embora no frigir dos ovos, trata-se de uma falha de open redirect e devemos encará-lo como tal.

Proteja-se!

  • Evite realizar redirects por parâmetros obtidos pelo usuário (reduza a superfície de ataque);
  • Caso precise realizar redirects, utilize uma whitelist, ou seja, lista controla de urls que a sua aplicação pode redirecionar os usuários.

Referências:

Share on Twitter Share on Facebook Share on Google Plus Share on LinkedIn Share on Hacker News

Postagens Populares

Newsletter


Twitter