Tabnabbing e clickjacking: os ataques de interface que nunca vês

O que o tabnabbing faz mesmo

Um separador consegue recarregar-se a si próprio mesmo quando está em segundo plano. Não é uma vulnerabilidade, é uma capacidade pensada de propósito no navegador. Se estás numa página à espera da notificação de um email, queres ser avisado ainda que o separador não esteja em primeiro plano. O tabnabbing aproveita-se precisamente disso.

O ataque funciona assim. Abres uma página com ar inofensivo, deixa-la aberta e passas para outro separador. O script da primeira página detecta a mudança (pela Page Visibility API ou por um handler do evento focus) e espera alguns minutos. Depois troca o título, o favicon e o HTML da página. O que era um artigo passa a parecer um ecrã de login do Google, da Microsoft ou do GitHub.

Quando voltas, dás de caras com um ecrã de login de aspecto familiar, num separador que foste tu a abrir. O URL na barra de endereços continua a ser o da página original, mas quase ninguém olha para lá. O formulário envia o que escreves para o atacante e logo a seguir redirecciona-te para o Google a sério. À segunda tentativa, assumes simplesmente que a primeira correu mal.

Clickjacking: um botão, duas identidades

O clickjacking é outro truque de interface. O atacante mete uma página legítima (por exemplo, uma página para mudar a palavra-passe ou um formulário de «enviar dinheiro») dentro de um iframe invisível e tapa-a com um engodo apetecível: «clica para ganhar um prémio». O utilizador julga estar a clicar no engodo, mas o clique cai mesmo no botão verdadeiro por baixo. Para o navegador é um clique autorizado, porque tecnicamente é-o.

O exemplo de manual é um botão de Gosto do Facebook colocado num iframe e tapado por um elemento de jogo. As vítimas dão Gosto, sem se aperceberem, a uma página que nunca viram. A coisa torna-se mais grave quando o botão por baixo é o «Confirm» de um ecrã de consentimento OAuth ou o «Send transaction» de uma app descentralizada. Os dois casos já foram explorados na prática mais do que uma vez.

Aqui quem tem de se defender são os responsáveis pelos sites. O header X-Frame-Options e a directiva frame-ancestors na Content-Security-Policy impedem que outros sites coloquem o site de confiança num iframe. As grandes plataformas têm isto bem tratado. Os sites que não definem o header continuam vulneráveis, e as plataformas Web3 mais recentes têm arrastado falhas precisamente nesta área.

Reverse tabnabbing via window.opener

Uma técnica próxima chama-se reverse tabnabbing. Um separador acabado de abrir tem, através de window.opener, acesso à página que o abriu. Se um atacante conseguir colocar o link dele no teu site, do separador novo pode redireccionar a página original. Voltas a ela mais tarde e acabas num clone de phishing do site em que estavas mesmo.

A defesa é rel="noopener" em todos os links externos, e os navegadores modernos já o aplicam automaticamente aos links que abrem em separadores novos. O vector clássico fecha-se assim, mas os fóruns e os sites com conteúdo gerado por utilizadores continuam vulneráveis sempre que renderizam esse conteúdo sem cuidado.

Porque é que estes ataques sobrevivem

Os ataques de interface têm três traços que os tornam duráveis. Primeiro, são quase sempre pequenas violações de convenções, não de regras técnicas. Reescrever um separador é uma capacidade legítima do navegador, incorporar um iframe também o é. Segundo, assentam em hábitos visuais e de contexto que os utilizadores não vigiam, porque nem sequer se apercebem de que estão a seguir convenções.

Terceiro, são baratos. Um tabnabber é um ficheiro HTML com umas dezenas de linhas de JavaScript. Os atacantes lançam dezenas de variantes em paralelo, juntam-nas a malvertising ou a abuso de SEO, e não perdem nada quando uma é apanhada.

O que podes fazer hoje

O grosso da mitigação fica do lado dos navegadores e dos responsáveis pelos sites. Do lado do utilizador, uns quantos hábitos chegam para tapar o resto.

1. 1

   Desconfia de ecrãs de login em separadores inesperados

   Se um separador te pedir de repente um login com que não contavas, fecha-o. Reabre o serviço a partir de um marcador.
2. 2

   Confirma o URL em cada formulário de login

   A barra de endereços sobrevive ao tabnabbing. Uma alegada página do Gmail num domínio desconhecido nota-se logo à primeira.
3. 3

   Mantém sessões curtas

   Quanto mais tempo os separadores ficam abertos, mais oportunidades têm de se reescrever. Para serviços sensíveis, separadores que ficam horas em segundo plano não são boa ideia.
4. 4

   Acções críticas numa sessão isolada só para isso

   Quando dás um consentimento OAuth, assinas transacções ou ligas contas, fá-lo numa sessão onde mais nada esteja a correr em paralelo. Isso neutraliza todos os truques de interface conhecidos, porque não há um segundo separador que alguém possa manipular ao lado.