clickjacking: definição, impactos, mecanismo e prevenção

2 weeks ago 20

BOOK THIS SPACE FOR AD

ARTICLE AD

Quer saber como hackers consegue roubar dinheiro(não tão comum hoje em dia), conseguir fazer com que o usuário compartilhe e dão likes em posts não desejados, e entre outros? Então, isso tudo são impactos potenciais da falha chamada clickjacking, veremos a definição o impacto que ela causa, como funciona e como prevenir.

Quando falamos de clickjacking pensamos em um ataque que tem o intuito de fazer com que um indivíduo clique em um botão em um site duvidoso e quando ele realiza esse feito neste botão, faz uma ação maliciosa, causando um impacto potencial para um usuário.

mas quais seriam os impactos potenciais? Existem diversos e os mais comuns são: fazer alguma mudança de dados na conta do usuário, como compartilhar posts aleatórios na conta do usuário sem ele ter dado um consentimento legitimo, curtir posts de perfis de outros usuários e até mais grave excluir conta do usuário naquele site vulnerável a essa falha, e o menos comum hoje em dia que é fazer transação financeira de uma conta da vítima para a conta de um hacker malicioso, sem o consentimento da vítima.

o procedimento do ataque é dado da seguinte maneira: um hacker cria um site malicioso e neste é colocado informações e um botão que cause um certo interesse em clicar no mesmo, então persuadindo a vítima a clicar no botão faz com que ela realiza uma solicitação maliciosa a um site que ela esta logada e essas solicitações geram impactos potenciais mencionados anteriormente.

Mas como o hacker consegue fazer um botão que faça fazer uma solicitação a uma página especifica de um site e cause uma ação maliciosa? Para isso temos o iframe, que nada mais do que é um elemento que permite colocar uma página html dentro de outra página html, então basicamente o atacante cria um iframe de uma página de um site que esta vulnerável a falha em seu site malicioso e faz com que o botão que realiza a ação (que causa prejuízo na vítima) fica em cima ao botão fake do hacker, um exemplo do html da página seria algo assim:

<html>
<head>
<style>
#site-vuln {
width:100%;
height:100%;
z-index:1;

}
#lata {
position:absolute; 
width:500px;
height:500px;
margin-left: 110px; 
z-index:-1;

}
</style>
</head>
<body>
<div id="lata">
<h1>Bem vindo ao meu site</h1>
<p>clique no botao para continuar</p>
<br><br><br>
<button>Clique aqui!</button>
</div>
<iframe id="site-vuln" src="http(s):ip ou dominio do site da vitima/pagina que possui a ação maliciosa" width="500" height="500" ></iframe>
</body>
</html>

É claro que os valores do píxel e o elemento <br> variam conforme aonde o botão da página vulnerável se encontra para colocar o botão fake em cima desse botão (do site vulnerável!).

Para deixar um pouco mais prático eu gravei um vídeo de como seria um ataque de clickjacking:

Como sabemos todas as vulnerabilidades podem ser consertadas e por isso que não fica de fora o clickjacking. Assim, para se proteger do clickjacking, existe 4 maneiras, são elas: o cabeçalho de resposta X-Frame-Options, a CSP (Content-Security-Policy) com a diretiva frame-ancestors ‘none’; ou frame-ancestors ‘self’; , SameSite=lax e SameSite=strict e por ultimo a tecnica frame-busting.

X-Frame-Options

O X-Frame-Options é um cabeçalho de resposta, sendo uma das proteção contra clickjacking, os valores desse cabeçalho para a proteção sao: DENY e SAMEORIGIN. Com o valor DENY, temos que nao podemos atribuir iframes em páginas web, ja com o valor SAMEORIGIN podemos atribuir iframes, mas só em páginas que possui o mesmo host, protocolo e porta, ou seja, essas paginas devem esta no mesmo domínio.

CSP (Content-Security-Policy)

outra camada de proteção é a CSP, ela é muito conhecida para prevenir ataques de XSS, mas é utilizada também no clickjacking, com a diretiva frame-ancestors podemos ter o ‘none’, que não permite aplicar aquela pagina como iframe em qualquer site, e o ‘self’ que permite aplicar iframe somente no mesmo domínio

SameSite

Essa camada de proteção é conhecida por ser o valor do cabeçalho cookie, quando esse cabeçalho é enviado o site entende as preferências do usuário naquele site. Assim, quando temos SameSite=lax o cookie não é enviado quando a requisição é feita de um site que não pertence o mesmo servidor do site de origem e o SameSite=strict que não permite que o cookie vai na solicitação ao servidor

frame-busting+bypass

Essa técnica é usada para impedir que paginas sejam carregadas em um iframe, mas infelizmente pode ser contornada, assim tornando-se obsoleta, pois na logica da aplicação é permitido o iframe quando o top frame(quadro que contem outros quadros)= a origem(mesmo domínio), um exemplo de código da proteção seria:

if (top.location == self.location){
// Permitir o iframe.
}
else{
// Impedir o iframe.
}

Para Contornar a proteção acima, podemos achar uma funcionalidade no site alvo(que possui a vulnerabilidade) que permite adicionar iframe, assim podemos colocar no site alvo o site malicioso como iframe e dentro do site malicioso tiver o iframe para o botão que causa ação malicioso, ou seja, ficaria algo assim:

Em que o site mais interno possui a ação maliciosa e o site mais externo é a pagina que permite adicionar iframe, voltando ao código acima podemos ver que entra na condição como verdadeiro e, portanto, ira permitir o iframe(o mais interno, ou seja, o que possui o botão da ação maliciosa).

Vickie Li.2021.BUG BOUNTY BOOTCAMP.no starch press

Read Entire Article