Mitigando ataques de clickjacking — do jeito DevSecOps!

Nas últimas semanas, recebemos alguns relatos (por meio do nosso programa de recompensa por bugs) de que alguns de nossos domínios internos estavam vulneráveis a ataques de clickjacking. É claro que nosso site principal estava protegido desde o início, mas alguns subdomínios menores não contavam com essa proteção. Corrigir o problema foi fácil, mas queríamos ir além e garantir que todos os nossos endpoints estivessem protegidos — para não precisarmos mais nos preocupar com isso. Veja como fizemos isso.

O que é clickjacking?

Veja a definição da OWASP:

"Clickjacking, também conhecido como “ataque de falsificação de interface”, ocorre quando um invasor usa várias camadas transparentes ou opacas para induzir uma pessoa a clicar em um botão ou link de outra página, quando a intenção era clicar na página em primeiro plano. Assim, o invasor “sequestra” cliques destinados à página exibida e os direciona para outra página, provavelmente pertencente a outro aplicativo, domínio ou ambos."

Esse é um ataque bastante sério. Um vetor de ataque comum consiste em criar outro site e incorporar o site-alvo em um iframe. Assim, o invasor consegue lançar facilmente um ataque de clickjacking e induzir pessoas desavisadas a clicar no site malicioso.

Como mitigar o clickjacking

Como vimos, o principal vetor de ataque é o uso de iframe. Então, basta informar ao navegador que nosso site não pode ser carregado em um iframe para mitigar completamente esse ataque! Felizmente, existe um cabeçalho que faz exatamente isso: x-frame-options. Basta definir esse cabeçalho e pronto!

Mas há um pequeno problema: como saber quais dos nossos endpoints têm esse cabeçalho e quais não têm? Na Snyk, temos muitos endpoints, e é muito difícil acompanhar todos eles. Precisamos de uma ferramenta que nos ajude com isso!

Conheça o OWASP AMASS

O OWASP AMASS é uma ferramenta da OWASP que oferece “mapeamento aprofundado da superfície de ataque e descoberta de ativos” — exatamente o que precisamos. Um dos recursos é a enumeração de DNS, que encontra todos os registros DNS de um domínio. É muito simples usar a ferramenta:

amass enum -d <domain> -o out.txt

Isso vai pesquisar todos os registros relevantes e gravá-los em out.txt. Agora, basta percorrer a lista e verificar se cada registro DNS tem o cabeçalho x-frame-options. Para isso, vamos usar uma ferramenta chamada, sem nenhuma surpresa, Security Headers Checkers.

Análise de cabeçalhos de segurança

O Security Headers Checker é um utilitário em Python que analisa uma URL em busca de vários problemas de segurança, incluindo a ausência de cabeçalhos de segurança, como x-frame-options. Ele tem vários recursos interessantes e, mais importante, o README documenta bem todos os problemas que pode encontrar e por que você deve se importar com eles. Mas o recurso mais relevante neste caso é a possibilidade de aceitar um arquivo com uma lista de URLs — como o arquivo gerado pelo AMASS. Então, basta fazer o seguinte:

python ./securityheaders/securityheaders.py out.txt --checkers HeaderMissingChecker --format json  --flatten --file ./result

Estamos usando a saída do amass e limitando a verificação a HeaderMissingChecker, pois é isso que nos interessa. O próximo argumento define o formato: escolhi JSON, mas há muitos outros formatos disponíveis.

Agora temos um arquivo com todas as URLs vulneráveis. Só precisamos de um truque rápido com JQ para filtrar apenas as URLs sem o cabeçalho x-frame-options, já que o Security Headers também informa sobre muitos outros cabeçalhos interessantes. É simples assim:

jq 'map(select(.header == "x-frame-options"))’ ./result/1.csv 

Sim, a extensão do arquivo de saída é csv — isso é um bug :)

Agora temos a lista e só falta o trabalho de verdade: revisar cada item e começar a corrigir todos esses endpoints vulneráveis. O próximo passo é executar esse processo diariamente para garantir que não surjam novos endpoints sem o cabeçalho x-frame-option. Outro desafio é confirmar que todas as URLs encontradas são mesmo sites — APIs não precisam de proteção contra clickjacking.

Para concluir

Este incidente mostra a importância de ter um programa de recompensa por bugs — uma forma de permitir que pesquisadores relatem problemas de segurança no seu sistema. Mas é ainda mais importante saber como lidar com esses relatos: corrigir o problema não basta. Sem adicionar um teste que reproduza o problema, não há como garantir que ele não vai acontecer de novo. Somos todos humanos e cometemos erros. Vamos garantir que usamos código que nos ajude a não repetir os mesmos erros!