Já ouviu falar em Reverse Tabnabbing?

02-10-2020
#security #hacking

Já ouviu falar em Reverse Tabnabbing?

Talvez não seja uma vulnerabilidade muito comum, já que não é uma das listadas no TOP 10 do OWASP, mas isto não quer dizer que não mereça nossa atenção.

Trata-se de uma vulnerabilidade em que uma página aberta através de outra é capaz de redirecionar esta primeira para outro destino, possibilitando manipular e alterar o endereço de origem. Como o usuário estará navegando na nova página que foi aberta, é provável que não note que na aba original algo foi alterado, especialmente se for redirecionado a uma página clone fake com a mesma aparência da original. Ao utilizar esta nova página de phishing maliciosa, seus dados confidenciais poderão ser capturados.

Como funciona

Se ficou confuso, veja o fluxograma abaixo que ilustra a sequência.

Fluxograma de uma exploração

Isto é possível quando o site de origem realiza a abertura de links, seja por tags html ou por javascript, sem as devidas propriedades informadas que mitigam este controle.

Veja este exemplo de exploração, onde o site malicioso redireciona o usuário para uma página de login fake do Gmail.

Demonstração de uma exploração

É possível imaginar as variações de phishing que podem ser aplicadas. Até os usuários mais atentos podem ser enganados com este tipo de redirecionamento, que pode facilmente passar despercebido.

Códigos vulneráveis

Abaixo os principais métodos de como este comportamento pode ser explorado:

HTML:

1
<a href="site-a-ser-aberto.com" target="_blank">Link para o site mal intencionado</a>

JS:

1
window.open('https://site-a-ser-aberto.com');

O que o destino malicioso fará:

1
2
3
4
if (window.opener) {    
  //Aqui ele redireciona a aba de origem para qualquer site que escolher
  window.opener.location = "https://fake-gmail.com"; 
}

Mitigação

Para mitigar nos dois tipos de chamadas, basta adicionar as duas propriedades ‘noopener,noreferrer’ que impedirão que o destino tenha controle sobre o opener location.

Exemplos:
HTML:

1
<a href="site_malicioso.com" target="_blank" rel="noopener noreferrer">Link para site malicioso</a>

JS

1
2
//Note que aqui é o terceiro parâmetro
window.open('https://site_malicioso.com', '', 'noopener,noreferrer');

Isso não é comigo!

Será mesmo? Você pode pensar:

“Não permito na minha aplicação que os usuário informe endereços url em nenhum lugar”

Tudo bem, mas e se sua aplicação possuir uma vulnerabilidade XSS, onde é possível manipular a informação? Ou se possui uma outra vulnerabilidade de SQL Injection onde é possível manipular a url que é carregada a partir de um banco de dados?

E você pode ainda pensar:

“Garanto que meu sistema não terá nenhuma dessas vulnerabilidades, seja XSS ou SQL Injection”

OK, mas se a página que sua aplicação está abrindo possui uma vulnerabilidade de XSS e é possível executar códigos JS inseridos arbitrariamente? Você também garante a segurança da aplicação de um terceiro?

Conclusão

O que precisamos ter em mente é sempre o foco em reduzir a superfície de ataque, por mais que uma vulnerabilidade sozinha não cause muitos problemas, é a combinação entre elas que geralmente causam as maiores dores de cabeça.

Detalhes como este tornam sua aplicação muito mais segura e com diferencial competitivo no mercado.

Referências