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:
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:
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!
Referências:
You must be logged in to post a comment.