Segurança da Informação

Ξ Deixe um comentário

Falha nos protocolos OAuth 2.0 e OpenID? Entenda com exemplos

publicado por Anderson Dadario

Falha nos protocolos OAuth 2.0 e OpenID? Entenda com exemplosPor 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.

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 controlada de urls que a sua aplicação pode redirecionar os usuários.

Referências:

  • http://tools.ietf.org/html/rfc6749
  • https://news.ycombinator.com/item?id=7685677
  • http://dannythorpe.com/2014/05/02/tech-analysis-of-serious-security-flaw-in-oauth-openid-discovered/
  • http://www.zdnet.com/covert-redirect-mostly-hype-and-certainly-no-heartbleed-7000029039/
  • http://www.cnet.com/news/serious-security-flaw-in-oauth-and-openid-discovered/
  • http://tetraph.com/covert_redirect/oauth2_openid_covert_redirect.html

Autor

Anderson Dadario é fundador do Gauntlet.io, serviço gratuito para execução de diversos scanners de segurança em aplicações web; Dadario possui larga experiência com testes de intrusão, análise de vulnerabilidades e integração de segurança no ciclo de desenvolvimento de software. Site: https://dadario.com.br

Anderson Dadario

Comentários

You must be logged in to post a comment.

Busca

Patrocínio

Publicidade



Siga-nos!

Newsletter: Inscreva-se

Para se inscrever em nossa newsletter preencha o formulário.

Artigos Recentes