Ataques CSRF, XSRF ou Sea-Surf

Por Acunetix

O que é CSRF?

O Cross Site Request Forgery (CSRF), o Sea Surf, ou o XSRF, é considerado um gigante adormecido no mundo da segurança na web , devido ao fato de que ele pode não ser levado tão a sério como deveria, embora possa provar ser um ataque furtivo e poderoso se executado corretamente. Além disso, é também um ataque comum que é regularmente explorado, e é por isso que ele tem garantido seu lugar na lista das 10 melhores da OWASP várias vezes seguidas. Dito isso, uma vulnerabilidade explorada de Cross-site Scripting (XSS) sempre superará qualquer vulnerabilidade CSRF, já que os ataques CSRF têm uma grande limitação. O CSRF permite apenas que mudanças de estado ocorram e, portanto, não podem atender a ataques que exigem que o invasor receba o conteúdo da resposta HTTP.

O Cross Site Request Forgery (CSRF) é um ataque pelo qual uma entidade maliciosa engana a vítima para executar ações em nome do invasor. O impacto do ataque dependerá do nível de permissões que a vítima está sendo explorada. As ações perpetradas pelo atacante certamente terão um efeito maior se a vítima que estiver executando as ações estiver em um nível administrativo versus um usuário de nível baixo, com menos privilégios. Os ataques de CSRF tiram proveito do fato de que um aplicativo da Web confia completamente em um usuário, uma vez que pode confirmar que o usuário é de fato quem ele diz ser.

Há duas partes principais na execução de um ataque de Cross Site Request Forgery (CSRF), a primeira parte é enganar a vítima para clicar em um link ou carregar uma página. Isso normalmente é feito por meio de engenharia social, que funciona excepcionalmente bem ao aproveitar a curiosidade da vítima para clicar em links maliciosos. A segunda parte é enviar uma solicitação criada no navegador da vítima, que enviará uma solicitação legítima para o aplicativo da web. A solicitação será enviada com os valores que o atacante deseja, incluindo quaisquer Cookies que a vítima tenha associado a esse site. Dessa forma, o aplicativo da web sabe que esta vítima pode executar determinadas ações no site e qualquer solicitação enviada com essas credenciais HTTP ou Cookies será considerada legítima, mesmo que a vítima esteja enviando a solicitação por meio do comando do invasor.

Quando uma solicitação é feita para um aplicativo da web, o navegador verificará se há algum cookie associado à origem do aplicativo da web que precisará ser enviado com a solicitação. Se for o caso, esses dados de autenticação, como Cookies, por exemplo, serão incluídos em qualquer solicitação enviada para este aplicativo da Web. Isso é feito para fornecer à vítima uma experiência perfeita, para que não seja necessário autenticá-la novamente para cada página visitada. Se o site aprovar o cookie sendo enviado e considerar a sessão como válida, um invasor poderá usar o CSRF para enviar solicitações como se a vítima estivesse enviando-as, sem que o site seja capaz de distinguir entre solicitações enviadas pelo invasor ou por a vítima, já que as solicitações estão sempre sendo enviadas pela vítima com seu próprio Cookie.

Um ataque CSRF simplesmente aproveita o fato de que o navegador envia o Cookie para o aplicativo da web automaticamente com cada solicitação.

Entendendo como um ataque é realizado

A falsificação de solicitação entre sites (CSRF) só será efetiva se a vítima for autenticada. Isso significa que a vítima precisará estar logada, para que o ataque seja bem-sucedido. Como os ataques de CSRF são usados ​​para ignorar o processo de autenticação, pode haver alguns elementos que não são afetados por ataques de CSRF, mesmo que eles não estejam protegidos contra ele, como aqueles que são publicamente acessíveis. Não é necessário que uma vítima conectada envie a solicitação, pois qualquer pessoa pode fazer isso. Por exemplo, vamos usar um formulário de contato em um site, onde os visitantes podem enviar consultas por meio do formulário. Isso não exige que a vítima tenha privilégios para enviar o formulário, o que significa que não importa se uma vítima do administrador ou uma vítima de baixo privilégio enviar o formulário.

CSRF Attacks, XSRF ou Sea-Surf

Para garantir que a vítima esteja conectada ao aplicativo da Web a ser explorado, os atacantes começaram a segmentar vítimas específicas do mesmo aplicativo da Web, para garantir que o ataque CSRF seja bem-sucedido.

Um exemplo de ataque CSRF, usando uma solicitação GET

O exemplo que será descrito nesta seção é bastante simples e não reflete necessariamente um exemplo do mundo real, no entanto, serve como um bom exemplo para mostrar como os ataques de CSRF funcionam.

As solicitações GET são, pela sua própria natureza, destinadas a serem idempotentes, o que significa que não devem ser usadas para executar mudanças de estado, portanto, o envio de uma solicitação GET não deve alterar nenhum dado. Naturalmente, alguns aplicativos da Web ainda usam GET em vez do POST mais apropriado para executar alterações de estado para operações, como alterar uma senha ou adicionar um usuário.

Quando o link malicioso que mencionamos anteriormente é clicado, o invasor pode direcionar a vítima para seu próprio aplicativo da Web malicioso que executará um script que, por sua vez, acionará o navegador da vítima para enviar uma solicitação ilegal. Essa solicitação é definida como ilegal, pois a vítima não está ciente de que está sendo enviada, embora apareça para o servidor da Web como se o usuário a tivesse enviado, porque inclui os Cookies necessários que o servidor da Web precisa para verificar se a vítima está quem eles dizem que são.

Imagine se www.example.com processasse transferências de fundos por meio de uma solicitação GET que incluiria dois parâmetros: o valor a ser transferido e o identificador da conta para a qual o dinheiro será transferido. O exemplo abaixo mostra um URL legítimo, que solicitará que o aplicativo da web transfira 100.000 unidades da moeda apropriada para a conta de Fred.

http://example.com/transfer?amount=1000000&account=Fred

A solicitação incluirá o Cookie para o usuário autenticado, portanto, não será necessário definir de qual conta o dinheiro será transferido. Isso significa que, se um usuário normal acessar esse URL, será necessário autenticá-lo para que o aplicativo da Web saiba de qual conta os fundos serão retirados. Agora que sabemos como essa solicitação pode ser usada por motivos legítimos, podemos descobrir uma maneira de enganar a vítima para que ela envie a solicitação que o atacante deseja, enquanto é autenticada como a vítima.

Se o aplicativo da Web que estiver sendo explorado estiver esperando uma solicitação GET, o invasor poderá incluir uma CSRF Attacks, XSRF ou Sea-Surftag em seu próprio site, que, em vez de vincular a uma imagem, enviará uma solicitação para o aplicativo Web do banco:

<img src = "http://example.com/transfer?amount=1000000&account=Fred" />

O navegador, em circunstâncias normais, enviará automaticamente os Cookies relacionados a esse aplicativo da Web, permitindo que a vítima realize uma alteração de estado em nome do invasor, em que a alteração de estado é uma transferência de fundos.

Ataques CSRF usando solicitações de POST

Embora esse ataque funcione em solicitações GET com muita facilidade, os invasores também podem usar o método POST para enviar solicitações. Na verdade, a maioria das solicitações de alteração de estado será feita por meio de solicitações POST, que enviarão quaisquer parâmetros e valores no corpo da solicitação, e não a própria URL, como em uma solicitação GET. Isso significa que os aplicativos da Web exploráveis ​​terão maior probabilidade de aceitar solicitações POST em vez de GET quando uma alteração de estado estiver envolvida.

Enganar uma vítima para enviar uma solicitação POST pode ser um pouco mais complicado do que enviar uma solicitação GET. Com a solicitação GET, o invasor só precisava que a vítima enviasse uma solicitação com todas as informações necessárias na URL, enquanto as solicitações POST exigem que um corpo de solicitação seja anexado à solicitação. Com um pouco de JavaScript, um invasor pode atrair uma vítima para seu aplicativo da Web mal-intencionado. Assim que a página da Web for carregada, a solicitação POST ilegal será enviada automaticamente.

Tome o seguinte exemplo usando a função onload, que enviará automaticamente uma solicitação do navegador da vítima assim que a página for carregada. Vamos dar o seguinte exemplo:

<body onload="document.csrf.submit()">
 
<form action="http://example.com/transfer" method="POST" name="csrf">
	<input type="hidden" name="amount" value="1000000">
	<input type="hidden" name="account" value="Fred">
</form>

Assim que a página é carregada, a função onload garante que o formulário denominado csrf seja enviado, o que, por sua vez, enviará a solicitação POST. Observando o formulário csrf, podemos ver que ele inclui dois parâmetros e seus valores, que foram configurados estaticamente pelo invasor, em que example.com identificará a solicitação como legítima, já que incluirá os Cookies da vítima.

Esta não é a única maneira de executar esse ataque. Um invasor também pode usar um iframe, que teria seus atributos configurados para torná-lo invisível. Usando a mesma função onload, o invasor pode carregar o iframe de seu próprio aplicativo da Web mal-intencionado e, assim que o iframe for carregado, a solicitação será enviada.

Prevenindo vulnerabilidades de CSRF

Embora tenha havido uma variedade de mecanismos de prevenção propostos pela CSRF, nem todos são eficazes em todos os cenários. As implementações a seguir demonstram ser eficazes para uma variedade de aplicativos da Web, ao mesmo tempo em que fornecem proteção contra ataques de CSRF.

Tokens Anti-CSRF

A implementação mais popular para impedir a falsificação de solicitações entre sites (CSRF) é usar um token de desafio associado a um usuário específico e pode ser encontrado como um valor oculto em todos os formulários de alteração de estado presentes no aplicativo da Web. . Esse token, chamado Token CSRF ou Token Sincronizador , funciona da seguinte maneira:

  • O servidor da web gera um token
  • O token é definido estaticamente como uma entrada oculta no formulário protegido
  • O formulário é enviado pelo usuário
  • O token está incluído nos dados do POST
  • O aplicativo da web compara o token gerado pelo aplicativo da web com o token enviado por meio da solicitação
  • Se esses tokens forem correspondentes, a solicitação será válida, pois foi enviada pelo formulário real no aplicativo da Web.
  • Se não houver correspondência, a solicitação será considerada ilegal e será rejeitada.

Isso protege o formulário contra ataques CSRF (Cross-site Request Forgery), porque um invasor que cria uma solicitação também precisará adivinhar o token anti-CSRF para enganar com sucesso a vítima, enviando uma solicitação válida. Além disso, esse token deve ser invalidado após algum tempo e depois que o usuário fizer logout.

Para que o mecanismo anti-CSRF seja implementado adequadamente, ele também precisará ser criptograficamente seguro, de modo que o token em si não possa ser facilmente adivinhado, o que é uma possibilidade se o token estiver sendo gerado com base em um padrão previsível.

Também é recomendável que você faça uso da opção prontamente disponível em estruturas populares que se defenderão contra ataques de CSRF para você, o que significa que você deve se abster de usar seu próprio mecanismo anti-CSRF, se possível. Isso permite menos espaço para erros, enquanto torna a implementação mais rápida e fácil.

Mesmo site cookies

Os ataques CSRF só são possíveis, pois os cookies são sempre enviados com quaisquer solicitações enviadas a uma origem específica , relacionada a esse cookie. Devido à natureza de um ataque CSRF, um sinalizador pode ser definido contra um cookie, ajustando-o em um cookie do mesmo site. Um cookie no mesmo site é um cookie que só pode ser enviado se a solicitação estiver sendo feita a partir da mesma origem relacionada ao cookie que está sendo enviado. O Cookie e a página de onde a solicitação está sendo feita são considerados como tendo a mesma origem se o protocolo, a porta (se aplicável) e o host forem os mesmos para ambos.

Uma limitação atual dos cookies no mesmo site é que nem todos os navegadores modernos os suportam, enquanto navegadores mais antigos não atendem a aplicativos da Web que fazem uso de cookies no mesmo site ( clique aqui para obter uma lista de navegadores suportados). No momento, os cookies do mesmo site são mais adequados como uma camada adicional de defesa profunda devido a essa limitação, enquanto ainda fazem uso de outros mecanismos de proteção de CSRF.

Conclusão

Os cookies são intrinsecamente vulneráveis, pois são enviados automaticamente a cada solicitação, permitindo que os invasores criem facilmente solicitações maliciosas que levam ao CSRF. Embora o atacante não consiga obter o corpo da resposta ou o próprio Cookie, o invasor pode executar ações com os direitos elevados da vítima. O impacto de uma vulnerabilidade de CSRF também está relacionado ao privilégio da vítima, cujo Cookie está sendo enviado com a solicitação do invasor. Embora a recuperação de dados não seja o escopo principal de um ataque de CSRF, as alterações de estado certamente terão um efeito adverso no aplicativo da Web que está sendo explorado.

 

Este artigo é uma tradução de: https://www.acunetix.com/websitesecurity/csrf-attacks/