Este artigo explora os ataques CSRF, como funciona e as medidas que voc\u00ea pode tomar para se preparar para um ataque CSRF.<\/p>\n
Confira nosso guia em v\u00eddeo para entender tudo sobre os ataques CSRF<\/a><\/strong><\/p>\n Um ataque Cross-Site Request Forgery, tamb\u00e9m conhecido como ataque CSRF, engana um usu\u00e1rio autenticado a realizar a\u00e7\u00f5es n\u00e3o intencionais, enviando solicita\u00e7\u00f5es maliciosas sem que o usu\u00e1rio perceba.<\/p>\n Normalmente, um ataque CSRF envolve solicita\u00e7\u00f5es que alteram o estado do sistema, pois o atacante n\u00e3o recebe uma resposta. Exemplos de tais solicita\u00e7\u00f5es incluem excluir um registro, alterar uma senha<\/a>, comprar um produto ou enviar uma mensagem. Todas essas a\u00e7\u00f5es podem ocorrer sem o conhecimento do usu\u00e1rio.<\/p>\n O atacante malicioso geralmente usa a engenharia social para enviar a um usu\u00e1rio desprevenido um link atrav\u00e9s de chat ou e-mail.<\/p>\n Quando o usu\u00e1rio clica no link, ele executa os comandos definidos pelo atacante.<\/p>\n Por exemplo, clicar em um link pode transferir fundos da conta de um usu\u00e1rio. Ou, pode alterar o endere\u00e7o de e-mail do usu\u00e1rio, impedindo que ele recupere o acesso \u00e0 conta.<\/p>\n Fazer com que o usu\u00e1rio inicie uma solicita\u00e7\u00e3o que altera o estado do sistema enquanto est\u00e1 logado \u00e9 o primeiro e mais crucial passo em um ataque CSRF. Com ataques CSRF, o atacante tem como objetivo fazer com que um usu\u00e1rio autenticado envie, sem saber, uma solicita\u00e7\u00e3o web maliciosa para um site ou aplicativo da web. Essas solicita\u00e7\u00f5es podem conter cookies, par\u00e2metros de URL<\/a> e outros tipos de dados que parecem normais para o usu\u00e1rio.<\/p>\n Para que um ataque CSRF seja bem-sucedido, as seguintes condi\u00e7\u00f5es devem ocorrer:<\/p>\n O m\u00e9todo mais comum para realizar ataques CSRF \u00e9 usar cookies em aplicativos com uma pol\u00edtica de cookies SameSite fraca. Os navegadores da web incluem cookies automaticamente<\/a> e frequentemente anonimamente, e eles salvam cookies usados por um dom\u00ednio em qualquer solicita\u00e7\u00e3o web enviada pelo usu\u00e1rio para esse dom\u00ednio.<\/p>\n A pol\u00edtica de cookies SameSite define como o navegador, em contextos de navega\u00e7\u00e3o entre sites, trata o cookie. Se definido como “strict”, o cookie n\u00e3o \u00e9 compartilhado em contextos de navega\u00e7\u00e3o entre sites, prevenindo ataques CSRF. Se definido como “none”, o navegador inclui o cookie em todos os contextos de navega\u00e7\u00e3o entre sites, deixando o aplicativo vulner\u00e1vel a ataques CSRF.<\/p>\n Quando um usu\u00e1rio envia, sem saber, uma solicita\u00e7\u00e3o maliciosa atrav\u00e9s de um navegador web, os cookies salvos fazem com que a solicita\u00e7\u00e3o pare\u00e7a leg\u00edtima para o servidor. O servidor, ent\u00e3o, responde \u00e0 solicita\u00e7\u00e3o alterando a conta do usu\u00e1rio, modificando o estado da sess\u00e3o ou retornando os dados solicitados.<\/p>\n Vamos examinar mais de perto dois exemplos de poss\u00edveis ataques CSRF, um com uma solicita\u00e7\u00e3o GET e outro com uma solicita\u00e7\u00e3o POST.<\/p>\n Primeiro, considere uma solicita\u00e7\u00e3o GET<\/a> utilizada por um aplicativo web de banco financeiro, onde o ataque explora uma solicita\u00e7\u00e3o GET e uma entrega de hyperlink.<\/p>\n Suponha que o pedido GET de transfer\u00eancia de dinheiro seja algo parecido com isso:<\/p>\n Na solicita\u00e7\u00e3o genu\u00edna acima, o usu\u00e1rio solicita transferir $1.000 para uma conta com o n\u00famero 547895 como pagamento por produtos comprados.<\/p>\n Embora essa solicita\u00e7\u00e3o seja expl\u00edcita, simples e pr\u00e1tica, ela exp\u00f5e o titular da conta a um ataque CSRF. Isso ocorre porque a solicita\u00e7\u00e3o n\u00e3o requer detalhes que um atacante n\u00e3o possa saber. Portanto, para iniciar um ataque, um atacante s\u00f3 precisaria alterar os par\u00e2metros dessa solicita\u00e7\u00e3o (o valor e o n\u00famero da conta) para criar uma solicita\u00e7\u00e3o forjada execut\u00e1vel.<\/p>\n A solicita\u00e7\u00e3o maliciosa seria eficaz em qualquer usu\u00e1rio do banco, desde que eles tenham sess\u00f5es gerenciadas por cookies em andamento.<\/p>\n Aqui est\u00e1 como a solicita\u00e7\u00e3o forjada para transferir $500 para a conta de um hacker (aqui, n\u00famero Uma vez que isso estiver completo, o atacante deve descobrir uma maneira de enganar o usu\u00e1rio para enviar essa solicita\u00e7\u00e3o enquanto estiver conectado ao seu aplicativo do banco on-line. Uma das maneiras de fazer isso \u00e9 criar um hiperlink inofensivo que chame a aten\u00e7\u00e3o do usu\u00e1rio. O link pode ser assim:<\/p>\n Dado que o atacante encontrou os endere\u00e7os de e-mail corretos<\/a> de seus alvos, eles podem enviar isso por e-mail para muitos clientes do banco. Aqueles que clicarem no link enquanto estiverem logados ativar\u00e3o o pedido para enviar ao atacante $500 da conta logada.<\/p>\n Vamos ver como a mesma institui\u00e7\u00e3o financeira seria afetada por um CSRF se eles aceitassem apenas solicita\u00e7\u00f5es POST<\/a>. Nesse caso, a entrega de hiperlink usada no exemplo de solicita\u00e7\u00e3o GET n\u00e3o funcionaria. Portanto, um ataque CSRF bem-sucedido exigiria que o atacante criasse um formul\u00e1rio HTML. A solicita\u00e7\u00e3o genu\u00edna para enviar $1.000 para um produto comprado ficaria assim:<\/p>\n Essa solicita\u00e7\u00e3o POST requer um cookie para determinar a identidade do usu\u00e1rio, o valor que desejam enviar e a conta de destino. Os atacantes podem alterar essa solicita\u00e7\u00e3o para realizar um ataque CSRF.<\/p>\n O atacante s\u00f3 precisa adicionar um cookie genu\u00edno a uma solicita\u00e7\u00e3o falsificada para que o servidor processe a transfer\u00eancia. Eles podem fazer isso criando um hiperlink de apar\u00eancia inofensiva que leve o usu\u00e1rio a uma p\u00e1gina da web de disparo que se parece com isso:<\/p>\n J\u00e1 definimos os par\u00e2metros de valor e conta no formul\u00e1rio acima. Quando um usu\u00e1rio autenticado visita \u00e0 p\u00e1gina, o navegador adiciona o cookie de sess\u00e3o antes de encaminhar a solicita\u00e7\u00e3o para o servidor. O servidor, em seguida, encaminha $500 para a conta do hacker.<\/p>\n Existem v\u00e1rios m\u00e9todos para prevenir e mitigar drasticamente poss\u00edveis ataques CSRF em seu site ou aplicativo da web, incluindo:<\/p>\n Um site seguro contra CSRF atribui a cada sess\u00e3o um token \u00fanico e o compartilha com o servidor e o navegador<\/a> do cliente. Sempre que um navegador envia uma solicita\u00e7\u00e3o sens\u00edvel, o servidor espera que ela contenha o token CSRF atribu\u00eddo. Se o token estiver incorreto, o servidor descarta a solicita\u00e7\u00e3o. O token CSRF n\u00e3o \u00e9 armazenado em cookies de sess\u00e3o no navegador do cliente por motivos de seguran\u00e7a.<\/p>\n Embora os tokens CSRF sejam uma excelente medida de seguran\u00e7a, esse m\u00e9todo n\u00e3o \u00e9 \u00e0 prova de ataques. Algumas das vulnerabilidades que acompanham os tokens CSRF incluem:<\/p>\n Um atacante precisa apenas remover o token e enviar a solicita\u00e7\u00e3o assim para executar o ataque:<\/p>\n Um atacante pode fazer login em um aplicativo usando sua conta para obter um token, como:<\/p>\n E, como os tokens est\u00e3o agrupados, o atacante pode copiar e usar o mesmo token para fazer login na conta de um usu\u00e1rio diferente, como neste exemplo:<\/p>\n Assim, um atacante pode fazer login em um aplicativo usando sua conta e abrir o arquivo de cookie para ver o seguinte:<\/p>\n Eles podem, ent\u00e3o, usar essas informa\u00e7\u00f5es para criar outro cookie e completar o ataque.<\/p>\n Outra estrat\u00e9gia para prevenir ataques CSRF \u00e9 o uso do cabe\u00e7alho “Referer”. No HTTP, os cabe\u00e7alhos “Referer” indicam a origem das solicita\u00e7\u00f5es. Eles s\u00e3o tipicamente utilizados para an\u00e1lise<\/a>, otimiza\u00e7\u00e3o e registro de dados.<\/p>\n Voc\u00ea tamb\u00e9m pode habilitar a verifica\u00e7\u00e3o dos cabe\u00e7alhos “Referer” no lado do servidor para prevenir ataques CSRF. O lado do servidor verifica a origem da solicita\u00e7\u00e3o e determina a origem de destino da mesma. Se elas corresponderem, ent\u00e3o a solicita\u00e7\u00e3o \u00e9 permitida. Se houver uma diverg\u00eancia, o servidor descarta a solicita\u00e7\u00e3o.<\/p>\n Usar cabe\u00e7alhos “Referer” \u00e9 mais simples do que usar tokens porque n\u00e3o requer a identifica\u00e7\u00e3o individual de usu\u00e1rios.<\/p>\n Assim como os tokens CSRF, os cabe\u00e7alhos “Referer” tamb\u00e9m t\u00eam algumas vulnerabilidades significativas.<\/p>\n Em primeiro lugar, os cabe\u00e7alhos “Referer” n\u00e3o s\u00e3o obrigat\u00f3rios, e alguns sites enviar\u00e3o solicita\u00e7\u00f5es sem eles. Se o CSRF n\u00e3o tiver uma pol\u00edtica para lidar com solicita\u00e7\u00f5es sem cabe\u00e7alhos, os atacantes podem usar solicita\u00e7\u00f5es sem cabe\u00e7alhos para executar ataques que alteram o estado do sistema.<\/p>\n Al\u00e9m disso, esse m\u00e9todo se tornou menos eficaz com a recente introdu\u00e7\u00e3o da pol\u00edtica “Referer”<\/a>. Essa especifica\u00e7\u00e3o previne o vazamento de URLs para outros dom\u00ednios, dando aos usu\u00e1rios mais controle sobre as informa\u00e7\u00f5es no cabe\u00e7alho “Referer”. Eles podem optar por expor parte das informa\u00e7\u00f5es do cabe\u00e7alho “Referer” ou desativ\u00e1-lo adicionando uma etiqueta de metadados na p\u00e1gina HTML, como mostrado abaixo:<\/p>\n O c\u00f3digo acima remove o cabe\u00e7alho “Referer” de todas as solicita\u00e7\u00f5es feitas a partir desta p\u00e1gina. Fazendo isso, torna-se dif\u00edcil para aplicativos que dependem dos cabe\u00e7alhos “Referer” prevenir ataques CSRF provenientes dessa p\u00e1gina.<\/p>\n Como a Kinsta se Protege contra Ataques CSRF<\/p>\n Al\u00e9m de usar o cabe\u00e7alho “Referer” e tokens CSRF, h\u00e1 uma terceira e op\u00e7\u00e3o muito mais f\u00e1cil: escolher um servi\u00e7o de hospedagem seguro como a Kinsta<\/a> para seus sites e aplicativos da web oferece uma barreira muito mais forte e segura entre os atacantes e seus usu\u00e1rios.<\/p>\n Al\u00e9m de recursos de seguran\u00e7a cr\u00edticos, como backups autom\u00e1ticos<\/a>, autentica\u00e7\u00e3o de dois fatores<\/a> e protocolos SFTP via SSH<\/a>, a integra\u00e7\u00e3o da Kinsta com o Cloudflare<\/a> fornece prote\u00e7\u00e3o de n\u00edvel empresarial com prote\u00e7\u00e3o baseada em IP e firewall.<\/p>\n Especificamente, a Kinsta atualmente possui cerca de 60 regras personalizadas de firewall para ajudar a prevenir ataques maliciosos e lidar com vulnerabilidades severas n\u00e3o autenticadas em plugins e temas, incluindo regras espec\u00edficas que procuram por vulnerabilidades CSRF.<\/p>\n O Cross-Site Request Forgery (CSRF) \u00e9 um ataque que engana usu\u00e1rios autenticados a iniciarem solicita\u00e7\u00f5es que alteram o estado do sistema sem que eles percebam. Esses ataques miram em aplicativos que n\u00e3o conseguem distinguir entre solicita\u00e7\u00f5es genu\u00ednas e forjadas que alteram o estado.<\/p>\n Os ataques CSRF s\u00e3o bem-sucedidos em aplicativos que utilizam cookies de sess\u00e3o para identificar usu\u00e1rios logados e t\u00eam uma pol\u00edtica de cookies SameSite fraca. Al\u00e9m disso, o servidor deve aceitar solicita\u00e7\u00f5es sem exigir par\u00e2metros desconhecidos, como senhas. Os hackers podem executar ataques maliciosos usando tanto o m\u00e9todo GET quanto o POST.<\/p>\n Para prevenir ataques CSRF, \u00e9 comum utilizar tokens CSRF ou implementar a verifica\u00e7\u00e3o do cabe\u00e7alho “Referer”. No entanto, ambas as medidas t\u00eam potenciais vulnerabilidades que podem comprometer sua efic\u00e1cia se n\u00e3o forem cuidadosamente gerenciadas.<\/p>\nO que \u00e9 um ataque CSRF?<\/h2>\n
![\"Como](\"https:\/\/kinsta.com\/wp-content\/uploads\/2022\/11\/CSRF-Attack-Okta.png\")
Como funciona um ataque CSRF?<\/h2>\n
\n
CSRF para uma solicita\u00e7\u00e3o GET<\/h2>\n
GET https:\/\/xymbank.com\/online\/transfer?amount=1000&accountNumber=547895 HTTP\/1.1<\/code><\/pre>\n654585<\/code>) ficaria. Observe que o exemplo abaixo \u00e9 uma vers\u00e3o altamente simplificada dos passos envolvidos em um ataque CSRF para fins de explica\u00e7\u00e3o.<\/p>\nGET https:\/\/xymbank.com\/online\/transfer?amount=500&accountNumber=654585 HTTP\/1.1<\/code><\/pre>\n<a\nhref=\"https:\/\/xymbank.com\/online\/transfer?amount=500&accountNumber=654585\">Click here to get more information<\/a>.<\/code><\/pre>\nCSRF para uma solicita\u00e7\u00e3o POST<\/h2>\n
POST \/online\/transfer HTTP\/1.1\nHost: xymbank.com\nContent-Type: application\/x-www-form-urlencoded\nCookie: session=FRyhityeQkAPzeQ5gHgTvlyxHJYhg\namount=1000\naccount=547895<\/code><\/pre>\n<html>\n<body>\n<form action=\"https:\/\/xymbank.com\/online\/transfer\" method=\"POST\">\n<input type=\"hidden\" name=\"amount\" value=\"500\"\/>\n<input type=\"hidden\" name=\"account\" value=\"654585\" \/>\n<\/form>\n<script>\ndocument.forms[0].submit();\n<\/script>\n<\/body>\n<\/html><\/code><\/pre>\n3 maneiras de reduzir os ataques CSRF<\/h2>\n
\n
Como prevenir ataques CSRF usando tokens CSRF<\/h2>\n
Potenciais vulnerabilidades dos tokens CSRF<\/h3>\n
\n
POST \/change_password\nPOST body:\npassword=pass123&csrf_token=93j9d8eckke20d433<\/code><\/pre>\nPOST \/change_password\nPOST body:\npassword=pass123<\/code><\/pre>\n\n
[application_url].com?csrf_token=93j9d8eckke20d433<\/code><\/pre>\n\n
Csrf_token:93j9d8eckke20d433<\/code><\/pre>\n\n
Como prevenir ataques CSRF com o cabe\u00e7alho de referrer<\/h2>\n
Potenciais vulnerabilidades do cabe\u00e7alho referer<\/h3>\n
<meta name=\"referrer\" content=\"no-referrer\"><\/code><\/pre>\nComo a Kinsta se protege contra-ataques CSRF<\/h2>\n
Resumo<\/h2>\n