O que é falsificação de solicitação entre sites?

O que é falsificação de solicitação entre sites (CSRF)?

Um ataque de falsificação de solicitação entre sites é um tipo de ataque cibernético confused deputy* que induz um usuário a usar acidentalmente suas credenciais para invocar uma atividade de mudança de estado, como transferir fundos de sua conta, alterar seu endereço de e-mail e senha ou alguma outra ação indesejada.

Embora o possível impacto contra um usuário comum seja substancial, um ataque CSRF bem-sucedido contra uma conta administrativa pode comprometer um servidor inteiro, resultando possivelmente no controle completo de um aplicativo web, API ou outro serviço.

Como funciona o ataque de falsificação de solicitação entre sites?

Esse ataque se concentra na segmentação de solicitações de mudança de estado, que se refere ao tipo de solicitação que resulta em dados sendo alterados de um valor para outro. Por exemplo, uma solicitação direcionada pode fazer uma compra ou alterar um valor em uma conta. Curiosamente, este é um “ataque cego” e não retorna dados ao invasor, tornando-se uma má escolha para roubo de dados.

Eis um exemplo das quatro etapas de um ataque de falsificação de solicitação entre sites:

1. Um invasor cria uma solicitação falsa que, quando executada, transfere US$ 10 mil de um banco específico para a conta do invasor.
2. O invasor incorpora a solicitação falsa em um hiperlink e a envia em e-mails em massa e também a incorpora em sites.
3. Uma vítima clica em um e-mail ou link de site colocado pelo invasor, fazendo com que a vítima faça uma solicitação ao banco para transferir US$ 10 mil .
4. O servidor do banco recebe a solicitação e, como a vítima está devidamente autorizada, trata a solicitação como legítima e transfere os fundos.

Os ataques de CSRF variam na metodologia, mas normalmente têm as seguintes características:

1. exploram sites que dependem da identidade de um usuário
2. enganam o navegador do usuário para que ele envie solicitações HTTP para o site visado
3. envolvem o uso de solicitações HTTP que têm efeitos colaterais e não têm as devidas proteções contra CSRF em vigor

Diversos verbos usados em HTTP têm vulnerabilidade variável a ataques CSRF, resultando em estratégias de proteção variáveis. Isso se deve à maneira como os navegadores web lidam de maneira diferente com os verbos.

As solicitações HTTP GET têm parâmetros incorporados, como aqueles dentro de tags de imagem, que podem ser manipulados e explorados. Normalmente, as solicitações GET não modificam o estado, tornando-as ineficazes como alvos do CSRF para um aplicativo web ou outro recurso implementado corretamente.

O HTTP POST é usado para alterar o estado, resultando em maior necessidade de proteção. Para isso, os navegadores web implementam medidas de segurança chamadas de política de mesma origem (SOP) e compartilhamento de recursos de origem cruzada (CORS), que contém a política de segurança de origem cruzada. A SOP permite apenas solicitações da mesma origem e o CORS permite apenas determinados tipos de solicitações provenientes de uma origem diferente. A combinação dessas implementações ajuda a evitar ataques de CSRF (entre outros) limitando a capacidade de uma solicitação ou página web de interagir com uma origem diferente.

Outros verbos HTTP, como PUT e DELETE, só podem ser executados usando a SOP e o CORS, mitigando muitos ataques entre sites.

Embora seja incomum, alguns sites desabilitam explicitamente essas medidas de segurança e também é possível desativá-las dentro de um navegador web.

Como pode ser mitigada a falsificação de solicitação entre sites?

A metodologia mais comum para mitigar ataques de CSRF envolve o uso de tokens anti CSRF usando um dos dois métodos. Embora as implementações de token sejam ligeiramente diferentes, o princípio subjacente permanece o mesmo; ao criar e comparar uma string de token gerada aleatoriamente, é menos provável que um invasor seja capaz de realizar um ataque sem uma suposição excepcionalmente improvável.

Padrão de token do sincronizador:

quando um usuário visita uma página web, como a página do banco que permite a transferência de fundos, o site do banco incorpora um token aleatório no formulário. Quando o usuário envia o formulário, o token aleatório é retornado e o banco pode verificar se os dois tokens correspondem. Se os tokens corresponderem, a transferência ocorrerá. O invasor não tem como acessar o valor do token aleatório criado na página web e, se ele solicitar para a página, a mesma política de origem evitará que o invasor leia a resposta.

A desvantagem desse método de mitigação é que aumenta a carga no lado do servidor para verificar a validade dos tokens com cada solicitação. Também pode criar problemas se um usuário tiver várias janelas do navegador ou outras condições que envolvam software diferente fazendo a solicitação. Ao expandir o escopo do token para ser por sessão em vez de por solicitação, algumas dessas dificuldades podem ser evitadas.

Token de cookie no cabeçalho:

outro método envolve a emissão de um cookie para o navegador web do visitante que contém um token aleatório. O JavaScript operando no lado do cliente lerá o valor do token no cookie e o copiará em um cabeçalho HTTP que será enviado com cada solicitação. Se uma solicitação genuína for enviada a partir do usuário, o valor no cabeçalho poderá ser verificado pelo servidor. Quaisquer outras instâncias falharão, mitigando um ataque bem-sucedido.

Ao usar regras personalizadas por meio de um WAF, os usuários podem ajudar a evitar certos ataques de CSRF. Explore o firewall de aplicativos web da Cloudflare.

*Problema confused deputy

Um confused deputy refere-se a um programa de computador que é enganado para abusar de sua autoridade. O risco associado a esse tipo de vulnerabilidade é o motivo pelo qual a segurança baseada em recursos ajuda a reduzir os riscos associados ao uso indevido. Ao instalar um software, por exemplo, a maioria dos computadores hoje exige que o usuário faça login. Isso ajuda a evitar que o código seja executado involuntariamente quando o usuário acidentalmente usar sua autoridade para autorizar uma instalação.