Problema de segurança que muitos usuários de sites que permitem criação de links estão expostos (atinge Facebook, Twitter, por exemplo)

Como desenvolvedor, você é constantemente lembrado sobre ameaças de segurança: Cross-site scripting, injeções de SQL, plugins ou bibliotecas sendo exploradas, etc. Muitas das ameaças podem ser difíceis de controlar e ao contrário, podem ser muito simples de serem implementadas. Iremos citar uma muito simples que afeta vários sites famosos, exceto o Instagram.

A linha abaixo é um exemplo. A técnica é extremamente simples de fazer.

<a href="http://phishing.me" target="_blank">Clique aqui</a>

Mas o que torna isto assustador é que nos testes feitos há algumas semanas anteriores a escrita deste artigo, nenhum dos navegadores populares protegem seus usuários. Até entendo que os navegadores estão completamente certos no comportamento. O que é preocupante, são os programadores destes grandes sites que permitem a inserção de links em suas páginas, sistemas e estruturas, não estarem atentos ao comportamento que isto gera e que possibilita facilmente ser explorado.

Para exemplificar o problema, grandes empresas e grandes sites são vulneráveis. Sites como Facebook, Twitter e o Medium. É bem provável que vários outros sites que você usa também não conseguem protegê-lo contra a vulnerabilidade de phishing que aqui é descrita.

Se você já usou o HTML, você saberá que, quando quiser que um link seja aberto em uma nova guia, você poderia fazer algo como o código acima, e o target=”_blank” é que é responsável por abrir o link justamente em uma nova aba.:

Tudo parece bem normal na linha de código HTML acima. Bem, a má notícia é que se um site exibir conteúdo gerado pelo usuário que permite que os links sejam postados (como o Facebook, por exemplo) e os abre usando _target = “em branco”, isto expõe a aba que abriu o link a uma vulnerabilidade de ataque de phishing muito simples.

Como isso pode ser explorado então?
Infelizmente, é fácil. Digamos que o link acima foi postado em um site aleatório, como o Facebook. Então você está no Facebook e você abre uma nova guia que é o site phishing.me. Agora, no site phishing.me você tem estas poucas linhas de código:

if (window.opener) {
    opener.location = 'https://facebok.co/login';
}

Isso faz com que a aba anterior, da qual você originalmente clicou no link, mude para https://facebok.co/login. Este domínio é real, pertence a uma empresa que não é o Facebook, mas alertamos que este exemplo é apenas FICTÍCIO. Não estamos acusando ou apontando que esta empresa dona deste domínio parecido com o do Facebook faz isto. Mas o exemplo é para demonstrar o perigo e o problema.
Isto pode ser feito com diversos outros sites e certamente que deseja fazer isto, irá trabalhar o golpe de maneira a garantir a máxima taxa de sucesso na obtenção de dados ou do que procura furtar do usuário vítima do gole.

Agora imagine que você é levado para uma página de login idêntica ao site em que você estava antes e não percebe uma sutil mudança no URL ou é feito uso de mais alguma técnica de ocultação do golpe mais elaborado? As suas informações se redigitas poderão ser roubadas, assim como os dados do sistema real ao qual ‘acabou de dar acesso aos golpistas’.

Tenha em mente que o domínio pode ser algo muito mais parecido com o site em que você estava.

Há tantas maneiras que alguém poderia usar essa vulnerabilidade para roubar suas informações. Felizmente, o sites de bancos, pagamentos, como o Paypal e demais do gênero tendem a não permitir publicação de conteúdo gerado pelo usuário ou terceiros em suas plataformas e sites, então eles estão mais ou menos seguros – mas você poderia facilmente contornar isso enviando um email para alguém e, em seguida, altere a primeira guia para ser uma página de login para seu provedor de e-mail e, em seguida, obter acesso a cargas de suas contas, como Paypal, como numa recuperação de senha. Lembrando que o opener tem acesso a qual é a url da aba que o abriu e muitas outras informações, o que dá para ampliar muito a gama de ataques bem elaborados.

Claro que o ataque como acima descrito, são muito mais elaborados.

Tudo o que foi preciso para realizar uma demonstração da vulnerabilidade foi de 1 linha de código para criar todo o problema, e no site vistado, um lógica simples.

Como programador, como posso proteger meu site que permite a publicação de conteúdo pelas usuários

Foi simples criar o ataque e é igualmente simples se proteger dele. Mas dos testes que fizemos ou tomamos conhecimentos, poucos sites realmente se protegem. Instagram é o único dos grandes site que permitem exposição de links feitos por usuários que parece ter a proteção).

Mantendo o mesmo exemplo do link anteriormente mostrado, a correção seria:

<a href="http://phishing.me" target="_blank" rel="noopener noreferrer">Clique aqui</a>

Sim, basta adicionar o atributo rel (que existe para dizer o relacionamento com o site em que você está e o site que você está prestes a abrir) e adicionar noopener (para todos os navegadores, exceto o Firefox) e noreferrer (para o Firefox).

É importante notar que de acordo com a especificação HTML, este é o comportamento esperado, e várias funcionalidades que eu já programei no passado dependeram disto. É muito útil este relacionamento entre o pai que abriu a nova página e a nova página. O que os programadores devem estar atento é justamente conhecer os riscos e tomar as providências para evitá-los. Não haveria problema numa página sua mandando para uma página sua ou de sua confiança este comportamento oriundo deste relacionamento entre o opener e a nova aba. No entanto, quando o link a ser colocado não é definido por algum dos responsáveis pelo site ou sistema, é imperativo estar atento a esta vulnerabilidade.

Para quem deseja mais detalhes, este documento é muito interessante e contém mais exemplos: https://mathiasbynens.github.io/rel-noopener/

E reforçando. É muito fácil esquecer isto e cometer o erro. Por isto, atenção redobrada.

Gostou? Tire um minutinho e dê sua contribuição para Drall Dev Community no Patreon!

Artigos relacionados: