O que é clickjacking?
Clickjacking é um ataque baseado em interface no qual um usuário é levado a clicar em um conteúdo acionável em um site oculto, clicando em algum outro conteúdo em um site falso. Considere o seguinte exemplo:
Um usuário da web acessa um site chamariz (talvez seja um link fornecido por um e-mail) e clica em um botão para ganhar um prêmio. Sem saber, eles foram enganados por um invasor para pressionar um botão oculto alternativo e isso resulta no pagamento de uma conta em outro site. Este é um exemplo de ataque de clickjacking. A técnica depende da incorporação de uma página da Web invisível e acionável (ou várias páginas) contendo um botão ou link oculto, digamos, dentro de um iframe. O iframe é sobreposto sobre o conteúdo da página da web isca antecipada do usuário. Este ataque difere de um ataque CSRF porque o usuário é obrigado a executar uma ação, como um clique de botão, enquanto um ataque CSRF depende de forjar uma solicitação inteira sem o conhecimento ou entrada do usuário.
A proteção contra ataques CSRF geralmente é fornecida pelo uso de um token CSRF: um número de uso único específico da sessão ou nonce. Os ataques de clickjacking não são mitigados pelo token CSRF, pois uma sessão de destino é estabelecida com conteúdo carregado de um site autêntico e com todas as solicitações ocorrendo no domínio. Os tokens CSRF são colocados em solicitações e passados para o servidor como parte de uma sessão com comportamento normal. A diferença em relação a uma sessão de usuário normal é que o processo ocorre dentro de um iframe oculto.
Como construir um ataque básico de clickjacking
Ataques de clickjacking usam CSS para criar e manipular camadas. O invasor incorpora o site de destino como uma camada iframe sobreposta no site chamariz. Um exemplo usando a tag de estilo e os parâmetros é o seguinte:
<head>
<style>
#target_website {
position:relative;
width:128px;
height:128px;
opacity:0.00001;
z-index:2;
}
#decoy_website {
position:absolute;
width:300px;
height:400px;
z-index:1;
}
</style>
</head>
...
<body>
<div id="decoy_website">
...decoy web content here...
</div>
<iframe id="target_website" src="https://vulnerable-website.com">
</iframe>
</body>O iframe do site de destino é posicionado no navegador para que haja uma sobreposição precisa da ação de destino com o site isca usando valores de posição de largura e altura apropriados. Os valores de posição absoluta e relativa são usados para garantir que o site de destino se sobreponha com precisão ao chamariz, independentemente do tamanho da tela, tipo de navegador e plataforma. O z-index determina a ordem de empilhamento das camadas do iframe e do site. O valor de opacidade é definido como 0,0 (ou próximo de 0,0) para que o conteúdo do iframe seja transparente para o usuário. A proteção contra clickjacking do navegador pode aplicar detecção de transparência de iframe baseada em limite (por exemplo, a versão 76 do Chrome inclui esse comportamento, mas o Firefox não). O invasor seleciona valores de opacidade para que o efeito desejado seja alcançado sem acionar comportamentos de proteção.
Clickbandit
Embora você possa criar manualmente uma prova de conceito de clickjacking conforme descrito acima, isso pode ser bastante tedioso e demorado na prática. Quando você está testando o clickjacking na natureza, recomendamos usar a ferramenta Clickbandit da Burp. Isso permite que você use seu navegador para executar as ações desejadas na página emoldurada e, em seguida, cria um arquivo HTML contendo uma sobreposição de clickjacking adequada. Você pode usar isso para gerar uma prova de conceito interativa em questão de segundos, sem precisar escrever uma única linha de HTML ou CSS.
Clickjacking com entrada de formulário pré-preenchido
Alguns sites que exigem preenchimento e envio de formulário permitem o preenchimento prévio de entradas de formulário usando parâmetros GET antes do envio. Outros sites podem exigir texto antes do envio do formulário. Como os valores GET fazem parte do URL, o URL de destino pode ser modificado para incorporar valores escolhidos pelo invasor e o botão transparente “enviar” é sobreposto no site isca, como no exemplo básico de clickjacking.
Scripts de quebra de quadro (Frame busting scripts)
Ataques de clickjacking são possíveis sempre que os sites podem ser enquadrados. Portanto, as técnicas preventivas baseiam-se na restrição da capacidade de enquadramento dos sites. Uma proteção comum do lado do cliente executada por meio do navegador da Web é usar scripts de bloqueio de quadro ou quebra de quadro. Eles podem ser implementados por meio de complementos ou extensões JavaScript do navegador proprietário, como NoScript. Os scripts geralmente são criados para executar alguns ou todos os seguintes comportamentos:
- verificar e garantir que a janela atual do aplicativo seja a janela principal ou superior,
- tornar todos os quadros visíveis,
- evitar clicar em quadros invisíveis,
- interceptar e sinalizar possíveis ataques de clickjacking para o usuário.
As técnicas de eliminação de quadros geralmente são específicas do navegador e da plataforma e, devido à flexibilidade do HTML, elas geralmente podem ser contornadas pelos invasores. Como os destruidores de quadros são JavaScript, as configurações de segurança do navegador podem impedir sua operação ou, na verdade, o navegador pode nem suportar JavaScript. Uma solução eficaz para o invasor contra os destruidores de quadros é usar o atributo HTML5 iframe sandbox. Quando isso é definido com os valores allow-forms ou allow-scripts e o valor allow-top-navigation é omitido, o script frame buster pode ser neutralizado, pois o iframe não pode verificar se é ou não a janela superior:
<iframe id="victim_website" src="https://victim-website.com" sandbox="allow-forms"></iframe>
Ambos os valores allow-forms e allow-scripts permitem as ações especificadas dentro do iframe, mas a navegação de nível superior está desativada. Isso inibe os comportamentos de quebra de quadro enquanto permite a funcionalidade no site de destino.
Combinando clickjacking com um ataque DOM XSS
Até agora, vimos o clickjacking como um ataque independente. Historicamente, o clickjacking tem sido usado para realizar comportamentos como aumentar “curtidas” em uma página do Facebook. No entanto, a verdadeira potência do clickjacking é revelada quando ele é usado como portador de outro ataque, como um ataque DOM XSS. A implementação desse ataque combinado é relativamente simples, desde que o invasor tenha identificado primeiro o exploit XSS. A exploração XSS é então combinada com o URL de destino do iframe para que o usuário clique no botão ou link e, onsequentemente, execute o ataque DOM XSS.
Clickjacking em várias etapas
A manipulação do invasor de entradas para um site de destino pode exigir várias ações. Por exemplo, um invasor pode querer induzir um usuário a comprar algo em um site de varejo para que os itens precisem ser adicionados a uma cesta de compras antes que o pedido seja feito. Essas ações podem ser implementadas pelo invasor usando várias divisões ou iframes. Esses ataques exigem precisão e cuidado consideráveis da perspectiva do invasor para que sejam eficazes e furtivos.
Como evitar ataques de clickjacking
Discutimos um mecanismo de prevenção comumente encontrado no lado do navegador, ou seja, scripts de impedimento de quadro. No entanto, vimos que muitas vezes é fácil para um invasor burlar essas proteções. Consequentemente, foram desenvolvidos protocolos orientados ao servidor que restringem o uso de iframe do navegador e mitigam contra o clickjacking.
Clickjacking é um comportamento do lado do navegador e seu sucesso ou não depende da funcionalidade do navegador e da conformidade com os padrões e práticas recomendadas da Web vigentes. A proteção do lado do servidor contra clickjacking é fornecida pela definição e comunicação de restrições sobre o uso de componentes como iframes. No entanto, a implementação da proteção depende da conformidade do navegador e da aplicação dessas restrições. Dois mecanismos para proteção contra clickjacking do lado do servidor são X-Frame-Options e Content Security Policy.
X-Frame-Options
X-Frame-Options foi originalmente introduzido como um cabeçalho de resposta não oficial no Internet Explorer 8 e foi rapidamente adotado em outros navegadores. O cabeçalho fornece ao proprietário do site controle sobre o uso de iframes ou objetos para que a inclusão de uma página da Web em um quadro possa ser proibida com a diretiva de negação:
X-Frame-Options: deny
Como alternativa, o framing pode ser restrito à mesma origem do site usando a diretiva sameorigin
X-Frame-Options: sameoriginou para um site nomeado usando a diretiva allow-from:
X-Frame-Options: allow-from https://normal-website.comX-Frame-Options não é implementado de forma consistente em navegadores (a diretiva allow-from não é suportada no Chrome versão 76 ou Safari 12, por exemplo). No entanto, quando aplicado corretamente em conjunto com a Política de Segurança de Conteúdo como parte de uma estratégia de defesa multicamada, pode fornecer proteção eficaz contra ataques de clickjacking.
Política de segurança de conteúdo (CSP)
A política de segurança de conteúdo (CSP) é um mecanismo de detecção e prevenção que fornece mitigação contra ataques como XSS e clickjacking. CSP geralmente é implementado no servidor web como um cabeçalho de retorno do formulário:
Content-Security-Policy: policyonde política é uma sequência de diretivas de política separadas por ponto-e-vírgula. O CSP fornece ao navegador do cliente informações sobre fontes permitidas de recursos da Web que o navegador pode aplicar para a detecção e interceptação de comportamentos maliciosos.
A proteção recomendada contra clickjacking é incorporar a diretiva frame-ancestors na política de segurança de conteúdo do aplicativo. A diretiva frame-ancestors ‘none’ é semelhante em comportamento à diretiva X-Frame-Options deny. A diretiva frame-ancestors ‘self’ é amplamente equivalente à diretiva sameorigin do X-Frame-Options. O seguinte CSP lista quadros de permissão apenas para o mesmo domínio:
Content-Security-Policy: frame-ancestral 'self';Como alternativa, o enquadramento pode ser restrito a sites nomeados:
Content-Security-Policy: frame-ancestors normal-website.com;
Para serem eficazes contra clickjacking e XSS, os CSPs precisam de desenvolvimento, implementação e teste cuidadosos e devem ser usados como parte de uma estratégia de defesa multicamadas.
Referências
- Title: “Clickjacking: Attacks and Defenses” Authors: Zhi Jin, Jeffrey R. Bigham, and Xiang Cui Journal: IEEE Internet Computing Year: 2012 Link: https://ieeexplore.ieee.org/document/6232321
- Title: “Clickjacking: A comprehensive survey” Authors: Nidhi Gupta and Kamaljit I. Lakhtaria Journal: International Journal of Computer Science and Mobile Computing Year: 2014 Link: https://www.ijcsmc.com/docs/papers/August2014/V3I8201423.pdf
- Title: “Clickjacking: Client-Side Cross-Frame Scripting” Authors: Bryan Sullivan and Vincent Liu Conference: Black Hat Briefings Year: 2008 Link: https://www.blackhat.com/presentations/bh-dc-08/Sullivan/Liu/Whitepaper/bh-dc-08-sullivan-WP.pdf
- Title: “Clickjacking: What It Is and How to Prevent It” Author: Troy Hunt Website: Troy Hunt’s Blog Year: 2013 Link: https://www.troyhunt.com/clickjack-attack-hidden-threat-right-in/
- Title: “Clickjacking – Web Application Vulnerability” Authors: Rakesh Kumar and Kapil Kumar Journal: International Journal of Advanced Research in Computer and Communication Engineering Year: 2015 Link: https://www.ijarcce.com/upload/2015/june-15/IJARCCE%20133.pdf
Esses artigos oferecem uma visão abrangente sobre o clickjacking, abordando diferentes aspectos e estratégias de defesa contra esse tipo de ataque. Lembre-se de que a informação contida nesses artigos pode ter sido atualizada desde a minha data de corte em setembro de 2021.