q
Cross Site Request Forgery (CSRF) é um ataque que se aproveita de uma sessão de usuário já estabelecida com a aplicação vulnerável, para realizar operações de maneira automática, sem o conhecimento e consentimento da vítima.
Exemplos de ações que podem ser executadas variam de um simples encerramento de sessão até a transferência de fundos em um sistema bancário. Na literatura, também é conhecido por diversos outros nomes e acrônimos, como Session Riding (Schreiber, 2004), XSRF (Stuttard e Pinto, 2007), ataque One-Click (Esposito, 2005) e Cross Site Refe- rence Forgery (Burns, 2005).
O ataque é possível devido a diversos aspectos dos mecanismos de gerenciamento de sessões implementados em aplicações web (Meucci et al., 2008; Schreiber, 2004; Burns, 2007):
1Cookies são enviados automaticamente pelos navegadores web, em todas as requi- sições subsequentes realizadas, ao servidor que os definiu. O mesmo acontece com cabeçalhos de autorização, depois de realizada uma autenticação HTTP.
1Uso de estrutura de URL invariável, isso é, cada recurso da aplicação é sempre aces- sado pela mesma URL, independentemente do usuário e da sessão estabelecida.
1Impossibilidade de se determinar nativamente que uma dada requisição originou-se na interface da aplicação. Por exemplo, requisições idênticas podem ser realizadas digitando a URL diretamente no navegador web, clicando em um link existente em uma página de terceiros ou lendo uma mensagem de correio eletrônico, em HTML, que con- tenha uma imagem, cujo atributo “src” seja a URL para executar a ação no sistema.
1O mecanismo de autorização decide se uma ação pode ou não ser realizada, somente com base em informações enviadas automaticamente pelo navegador web, como cookies e cabeçalhos de autorização.
Todos esses pontos podem ser explorados em um ataque cross-site request forgery, conforme o cenário ilustrado na Figura 4.12 e explicado em seguida.
<a href=”http://www.app.com/proc.jsp?acao=10”> Clique aqui<a/>
Usuário + senha
Identificador de sessão (SID)
SID + http://www.app.com/proc.jsp?acao=10
Ação “10” realizada com sucesso!
(1) (3) (2) (5) (4) Vítima www.app.com
1. Usuário acessa a aplicação web e informa o identificador e senha para autenticar-se e poder utilizar opções protegidas do sistema.
Figura 4.12
Exemplo de um ataque CSRF.
Te st e d e I nv as ão d e A pl ic aç õe s W eb
2. A aplicação verifica as credenciais e, caso estejam corretas, atribui um identificador único à sessão do usuário, na forma de um cookie, que é enviado pelo navegador, em todas as requisições seguintes realizadas ao sistema.
3. Um usuário malicioso, que conhece a estrutura das URLs da aplicação, envia uma men- sagem à vítima, contendo um link para executar uma ação no sistema. É fácil perceber que, adotando essa abordagem, o usuário deve ser induzido a clicar no link, por meio de engenharia social, para que o ataque funcione. Dependendo de quão consciente ele é, em termos de segurança da informação, isso pode ou não ocorrer. Assim, é mais eficaz utilizar elementos HTML que realizam as requisições, automaticamente, como é o caso de imagens, por exemplo.
4. A vítima abre uma nova janela do mesmo navegador que está usando no acesso à apli- cação para ler a caixa de correio eletrônico. Nisso, acessa a mensagem maliciosa e clica no link fornecido pelo atacante. O navegador, então, efetua a requisição à aplicação e envia, também, o identificador de sessão atribuído ao usuário.
5. A aplicação atende a requisição, pois não tem como discerni-la de uma solicitação legítima, feita pela própria interface do sistema, uma vez que o identificador de sessão está correto.
Como exemplo, considere o cenário abaixo baseado em um ponto de acesso sem fio real, que utiliza uma interface web para gerenciamento, como a grande maioria desses dis- positivos. A aplicação emprega o método de autenticação básica do protocolo HTTP e as requisições são feitas todas por meio do método POST. Uma das diversas funcionalidades apresentadas pelo equipamento é o controle de acesso por meio do endereço MAC do cliente, que precisa estar pré-cadastrado para conseguir conectar-se. A Figura 4.13 ilustra a interface para desativação desse serviço e o formato da requisição gerada, quando o admi- nistrador clica em Apply.
Com um teste simples, é fácil constatar que a requisição pode ser feita também por meio do método GET. Embora isso não seja um pré-requisito para que um ataque de cross-site request forgery aconteça, facilita muito a vida do atacante. Observe, também, que, aparen- temente, não há parâmetros que sejam função da sessão estabelecida, o que implica que a URL para realizar a operação segue uma estrutura fixa. Com base nessas informações todas, um ataque pode proceder da seguinte maneira:
1. O administrador do ponto de acesso sem fio se autentica na aplicação de gerenciamento, utilizando um navegador X.
2. O atacante envia um e-mail em HTML ao administrador contendo o seguinte elemento:
Figura 4.13
Estrutura da requi- sição para desativar o filtro de MAC.
Ca pí tu lo 4 - T es te d o g er en ci am en to d e s es sõ es <img src=”http://192.168.0.1:80/adv_filters_mac.cgi? editRow=-1&delrow=-1&filters=1&macFilter=0&name=& mac1=&mac2=&mac3=&mac4=&mac5=&mac6=” />
3. Com a aplicação de gerenciamento ainda aberta, o administrador acessa a conta de e-mail, usando o mesmo navegador X, e lê a mensagem maliciosa. Quando esta é exibida, a imagem é carregada, automaticamente, e, com isso, a requisição para desativação do filtro de MAC é enviada ao ponto de acesso, juntamente, com as credenciais do usuário. Como estas estão corretas, a aplicação atende a solicitação, como se fosse legítima.
4. O usuário malicioso se conecta ao ponto de acesso à rede sem fio.
No cenário acima, optou-se por utilizar uma requisição GET, no lugar do método POST, usado originalmente pela aplicação. Observe que essa tradução nem sempre é possível e, em tais situações, outra técnica deve ser empregada para executar o ataque CSRF. Considere, por exemplo, um sistema que permite a troca de senhas, por meio do seguinte formulário:
<form action=”#” method=”POST”> New password:<br>
<input type=”password” AUTOCOMPLETE=”off” name=”password_new”><br> Confirm new password:<br>
<input type=”password” AUTOCOMPLETE=”off” name=”password_ conf”><br>
<input type=”submit” value=”Change” name=”Change”> </form>
q
Uma maneira de enviá-lo, automaticamente, consiste na utilização de código Javascript. Note, entretanto, que a política de mesma origem proíbe que o código carregado a partir de um domínio interaja com objetos originários de outro. Embora isso seja uma realidade, a mesma política não impede que submissões de formulários sejam realizadas por origens diferentes. Isso permite criar, em um domínio controlado pelo atacante, um formulário contendo os mesmos elementos que o original e com o atributo action definido para o sistema vulnerável a CSRF. A submissão pode ser realizada, por meio de Javascript, tão logo a página seja car- regada, bastando, então, induzir a vítima a acessá-la (Jovanovic et al., 2006). Tudo isso está ilustrado no código HTML abaixo:
<body onload=”document.forms[‘fcsrf’].Change.click();”>
<form name=”fcsrf” action=”http://dvwa.esr.rnp.br/vulnerabilities/ csrf/”
method=”post”>
<input type=”hidden” name=”password_new” value=”pwd”/> <input type=”hidden” name=”password_conf” value=”pwd”/> <input type=”Submit” name=”Change” value=”Change”/>
Te st e d e I nv as ão d e A pl ic aç õe s W eb </body>
Um problema da abordagem acima é que, uma vez enviado o formulário, a página de res- posta é carregada na janela do navegador, alertando o usuário sobre o ataque realizado. Para evitar que isso aconteça, um pequeno ajuste pode ser realizado, o qual consiste em abrir o formulário em um iframe invisível, contido em outra página do domínio do atacante. Desse modo, o documento de resposta, fornecido pela aplicação alvo, não fica visível à vítima. A página HTML abaixo ilustra essa técnica, empregando o atributo opacity para con- seguir a transparência necessária.
<html>
<head><title>Evil.org</title></head> <body>
<iframe id=”ifcsrf” src=”csrf.html” style=”opacity:0.00”> </iframe>
</body> </html>
Todos os exemplos abordados até aqui são viáveis apenas porque a aplicação não é capaz, como vimos, de validar se a origem da requisição é o próprio sistema. Atacando esse problema, surge a solução mais eficaz para evitar ataques CSRF, a qual consiste na inclusão, em cada página da aplicação, de um elemento com valor gerado em função da URL, do identificador de sessão, do nome da conta do usuário e de um segredo conhecido apenas pelo sistema.
q
Toda vez que uma requisição é recebida pela aplicação, esse valor, chamado de token anti-CSRF, deve ser validado e, caso não seja o esperado ou não esteja presente, uma resposta de erro deve ser enviada ao solicitante.
Note que, para não ser vulnerável a ataques, o token não pode ser previsível e deve ter um tamanho em bits suficiente para evitar busca exaustiva de valores.
q
Adotada essa contramedida, o usuário malicioso precisa, para efetuar o ataque, des- cobrir o valor do token anti-CSRF ou, então, que a aplicação seja vulnerável, também, a um ataque de cross-site scripting. Nesse último caso, todo e qualquer controle, para evitar ataques CSRF, é inutilizado, e a exploração de requisições via método POST deixa de necessitar que a vítima visite uma página maliciosa, uma vez que a política de mesma origem é respeitada.
A interação entre esses defeitos é tema do Capítulo 5, que trata especificamente de cross-site scripting. Caso esse ataque não seja possível, a técnica chamada clickjacking, refinada há pouco tempo (Stone, 2010), apresenta-se como um método alternativo para violar tokens anti-CSRF.
q
Para encerrar esta seção, observe o roteiro de teste que pode ser utilizado, com o obje- tivo de verificar se uma aplicação é vulnerável a cross-site request forgery:
1Habilite um proxy de interceptação para monitorar as requisições realizadas à aplicação.
1Autentique-se no sistema e percorra as diversas áreas protegidas.
1Para cada requisição, identifique os parâmetros e construa uma página HTML que efetue a mesma solicitação. A ausência de elementos específicos de sessão, na página original, é um grande indicativo de que a aplicação é vulnerável.
Ca pí tu lo 4 - T es te d o g er en ci am en to d e s es sõ es
q
1Abra a página criada em uma nova janela e verifique se a ação é realizada, automati- camente, pela aplicação. Em caso de resposta positiva, o ataque é possível.