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

As vulnerabilidades de falsificação de solicitação entre sites (CSRF ou XSRF) raramente são altas ou críticas em suas classificações de gravidade. Eles ainda podem fazer muito mal, no entanto. Eles têm sido a segunda vulnerabilidade mais comum do WordPress nos últimos anos, depois das vulnerabilidades Cross-Site Scripting (XSS). Você entenderá como proteger melhor seu site se souber o que é uma vulnerabilidade CSRF e como os invasores costumam explorá-la.

Como contornar a política de mesma origem

Uma vulnerabilidade CSRF permite que um invasor contorne um recurso padrão do navegador chamado política de mesma origem. Todos os navegadores da web seguem esta regra para evitar o tipo de interferência que os CSRFs permitem. Normalmente, quando você está carregando uma página da web, seu navegador só interage com um domínio ou subdomínio, exceto quaisquer exceções permitidas. E só aceitará conteúdo em um protocolo, HTTP ou HTTPS (não ambos), sem avisar que há um problema. Se indivíduos mal-intencionados ignorarem a política de mesma origem, eles também podem induzi-lo a clicar em links que executam ações indesejadas interagindo inesperadamente com um site diferente.

Visualmente, você teria poucas ou nenhuma pista de que está interagindo com outro site de forma indesejada. O clickjacking funciona assim. Se o seu site WordPress foi explorado por meio de uma vulnerabilidade CSRF, você e seus visitantes podem estar sujeitos a phishing, clickjacking e coisas piores.

Neste guia, vamos nos aprofundar nos detalhes das falsificações de solicitações entre sites. Veremos um exemplo específico de uma vulnerabilidade CSRF para que você entenda como eles funcionam. Em seguida, mostraremos o que você pode fazer para evitar que vulnerabilidades CSRF surjam em seu site. Também vamos sugerir algumas maneiras de anular ou limitar o dano que uma exploração CSRF bem-sucedida pode causar protegendo seu site contra esses e outros tipos de ataques.

Vamos dar uma olhada.

Como um ataque de falsificação de solicitação entre sites (CSRF) afeta seu site WordPress?

Quando um ataque CSRF é bem-sucedido, suas vítimas autorizam involuntariamente uma ação prejudicial, como uma atualização de suas credenciais de login. Eles podem ser levados a permitir que um invasor assuma o controle de sua conta de usuário. Pior ainda, uma vítima de uma exploração CSRF pode permitir que invasores iniciem transferências financeiras em seu nome.

Se um plug-in em seu site WordPress contiver uma vulnerabilidade CSRF, um invasor poderá sequestrar algumas contas de usuário. Esse seria um dos piores cenários. Se uma conta roubada tiver uma função administrativa no WordPress ou o usuário reutilizar sua senha em outros sites, o dano pode ser extenso.

Como funciona um ataque CSRF?

Três condições diferentes devem existir para um hacker fazer um ataque CSRF funcionar. Se você entendê-los em um nível geral, terá uma boa compreensão prática de alguns fundamentos de segurança da Web.

1. Manipulação de sessão baseada em cookies

Como outros aplicativos sem estado, o WordPress depende de cookies de sessão para identificar usuários. Em condições de segurança baixa ou comprometida, um invasor pode criar alguns cookies de sessão falsos ou manipular um usuário conectado para executar alguma ação indesejada. O WordPress aceitará solicitações forjadas e manipuladas que são ou parecem ser de um usuário conectado.

Embora as explorações de CSRF geralmente tenham como alvo a manipulação de sessões baseadas em cookies, esse não é o único alvo. Os ataques CSRF podem ser eficazes contra qualquer aplicativo que adicione automaticamente credenciais de usuário às solicitações. A autenticação baseada em certificado e a autenticação básica HTTP também são suscetíveis a vulnerabilidades CSRF por esse motivo.

2. Uma ação relevante pode ser direcionada

Deve haver alguma ação dentro do aplicativo de destino que as vítimas possam ser induzidas a realizar. Essa pode ser uma ação privilegiada, como alterar as permissões do usuário. Pode estar relacionado a dados específicos do usuário, como atualizar a senha de um usuário. Essas são ações comuns em todos os aplicativos da Web, incluindo o WordPress. Eles têm valor como alvos para hackers porque podem abrir um caminho para eles roubarem contas de usuários e se aprofundarem em formas de se envolver em roubo, fraude ou outras atividades maliciosas.

3. Nenhum parâmetro de solicitação imprevisível

As solicitações que executam a ação de destino devem ser conhecidas ou previsíveis. Se as solicitações de destino não precisarem conter parâmetros cujos valores o invasor não possa determinar ou adivinhar, elas estarão mais vulneráveis ​​à manipulação.

Por exemplo, se uma solicitação de alteração de senha válida precisar incluir a senha existente, ela é segura — desde que o invasor não saiba a senha. Os tokens CSRF e os cookies SameSite adicionam mais obstáculos aos invasores quando os desenvolvedores os usam para proteger seu código. Mas, às vezes, os desenvolvedores não implementam esses métodos de segurança corretamente ou não os implementam. (É por isso que a autenticação de usuário forte e sem senha é valiosa.)

Explorando uma vulnerabilidade CSRF para alterar e-mails de conta de usuário — um exemplo

Aqui está um exemplo mais aprofundado. Na verdade, não funcionará, mas ilustra os principais conceitos em jogo para uma exploração CSRF eficaz.

Considere uma solicitação de alteração de e-mail. Quando um usuário realiza essa ação, ele faz uma solicitação HTTP semelhante a esta para o servidor da Web que a recebe:

 POST /test HTTP/1.1 Host: yourwebsite.com Content-Type: application/x-www-form-urlencoded Content-Length: 60 Cookie: session=yvthgjrudhgeQkAPzeQ5gHgTvlyxHfsAfE;[email protected]

Por que funciona

Isso atende às condições exigidas para CSRF se/porque:

• O site/aplicativo de destino usa um cookie de sessão para identificar qual usuário emitiu a solicitação e não há outros tokens ou mecanismos para rastrear as sessões do usuário. É por isso que os desenvolvedores devem usar tokens CSRF e/ou cookies SameSite.
• Alterar o endereço de e-mail de um usuário é uma ação relevante no interesse de um invasor. Com certeza é! Se você pode alterar o endereço de e-mail de um usuário para um que você controle, você pode assumir o controle total de sua conta.
• O invasor conhece os parâmetros de solicitação necessários para alterar o endereço de e-mail de um usuário e pode gerar valores válidos para eles. Esses parâmetros não são secretos e não é difícil determinar quais endereços de e-mail muitas pessoas usam para suas contas online. O cookie de sessão é mais complicado.

Como um invasor pode roubar cookies de sessão

O principal obstáculo do invasor é determinar os valores reais dos parâmetros que acessarão a conta de um determinado usuário. Eles podem fazer isso criando uma página da web destinada aos usuários do site de destino. Este site enganoso pode ter links ou botões que parecem ter uma finalidade legítima, como solicitar brindes. Na realidade, se você clicar nesses links ou botões, a única pessoa que receberá algumas guloseimas de graça é o invasor.

Quando você clica nesses links fraudulentos, eles fazem uma solicitação de alteração de endereço para o site visado e vulnerável ao CSRF. Se você estiver logado nesse site, a solicitação será válida. Sua conta foi roubada - você entregou suas chaves.

Os usuários de um site WordPress que permanecem conectados a ele têm um cookie de sessão ativo em seu navegador que persiste mesmo quando estão em um site diferente. O navegador deles incluirá automaticamente esse cookie de sessão em uma solicitação forjada. O WordPress pode ver isso como uma solicitação de endereço de alteração perfeitamente válida - mesmo que esteja vindo de outro site e o usuário não tenha ideia de que está fazendo isso.

Supondo que nenhuma outra medida de segurança esteja em vigor, como o atributo de cookie SameSite, o site de destino vulnerável processará uma solicitação forjada da mesma forma que uma válida. Se o site de destino não aplicar uma etapa de confirmação de alteração de endereço ou se o invasor tiver uma maneira de contornar isso, o invasor alterará com êxito o endereço do usuário para qualquer um que o invasor escolher.

Como um ataque CSRF é entregue a um site vulnerável

Os mecanismos de entrega para ataques CSRF e ataques Reflected Cross-Site Scripting (Reflected XSS) são semelhantes.

Na maioria dos casos, os invasores colocarão seu código malicioso em um site enganoso que eles controlam. Este pode ser um site legítimo que eles já comprometeram, e é por isso que o Google mantém uma lista de sites enganosos. Todos os navegadores avisarão seus usuários se você estiver nesta lista! É por isso que o iThemes Security verifica todos os dias para garantir que seu site não se tornou uma ferramenta de hackers.

Conseguir que as vítimas em potencial visitem um site enganoso é simplesmente uma questão de mídia social básica e marketing por e-mail. Às vezes, o código malicioso é simplesmente colocado em um site popular em uma área ativa.

Um invasor pode nem precisar de um site para atrair suas vítimas. Algumas explorações CSRF simples usam o método GET. Isso é o que seu navegador faz quando você clica em um link ou insere um URL na barra de endereço. Ele faz uma solicitação GET usando a URL no link ou que você fornece. Às vezes, um ataque CSRF pode ser totalmente executado com uma única solicitação GET para um site vulnerável. Em situações como essa, o invasor pode não precisar usar um site enganoso. Eles podem simplesmente alimentar suas vítimas com uma URL maliciosa diretamente.

Protegendo seu site contra ataques de falsificação de solicitação entre sites (CSRF)

Vulnerabilidades CSRF frequentemente surgem em plugins e, às vezes, em temas. Quando os hackers os atacam, não é difícil se proteger. Use plug-ins e temas de qualidade em que você confia, remova aqueles que não está usando e mantenha todos os seus softwares atualizados . Você também deve implementar uma política de segurança de usuário bem pensada e considerar a possibilidade de não usar senha. Se uma vulnerabilidade CSRF (ou qualquer outra) for explorada em seu site para obter acesso a contas de usuário, não será muito bom para o invasor se você estiver usando senhas. Ninguém pode roubar o que não existe.

Além de gerenciar atualizações e avisá-lo sobre plugins e temas vulneráveis, o iThemes Security Pro facilita a configuração e o gerenciamento de regras de segurança baseadas em funções e usuários. Delegue privilégios com base no princípio do menor privilégio. Proteja seu login, recuperação de senha e formulários de contato com CAPTCHAs. Não dê aos seus usuários mais recursos do que eles precisam. Exigir que usuários com privilégios mais altos usem métodos de autenticação mais fortes. E, definitivamente, adote a maneira mais conveniente e simples de fazer login no WordPress sem uma senha: senhas!

O melhor plugin de segurança do WordPress para proteger e proteger o WordPress

Atualmente, o WordPress é responsável por mais de 40% de todos os sites, tornando-se um alvo fácil para hackers com intenções maliciosas. O plug-in iThemes Security Pro elimina as suposições sobre a segurança do WordPress para facilitar a segurança e a proteção do seu site WordPress. É como ter um especialista em segurança em tempo integral na equipe que constantemente monitora e protege seu site WordPress para você.

Obtenha o iThemes Security Pro

Dan Knauss

Dan Knauss é generalista de conteúdo técnico da StellarWP. Ele é escritor, professor e freelancer trabalhando com código aberto desde o final dos anos 1990 e com WordPress desde 2004.