INW-Segurança

Vulnerabilidades Web (CSRf) Cross Site Request Forgery

Hoje vou falar sobre um tipo de vulnerabilidade de aplicações web chamado Cross Site Request Forgery (CSRF). Mesmo que seu nome guarde certa similitude com outro tipo de vulnerabilidades como Cross Site Scripting (XSS), hí importantes diferenças entre elas. A diferença dos ataques XSS, que se baseiam em explodir a confiança que tem um usuírio em um determinado sàtio web ou aplicação, os ataques CSRF, também denominados como Cross Site Reference Forgery ou XSRF, se baseiam em explodir a confiança que os sàtios web têm com seus usuírios.

Vejamos como funciona com um exemplo:

Imaginemos que estamos conectados a um site que requer autenticação, e que por exemplo estamos mantendo uma conversa por chat com outra pessoa. Essa pessoa poderia enviar-nos um link de uma pígina que contivesse uma imagem oculta que apontasse a uma url do site no qual estamos autenticados. Quando entríssemos nessa pígina, a imagem oculta faria com que solicitíssemos ao site uma determinada ação sem estarmos conscientes disso, por exemplo mudando nossos dados de registo, publicando informação em um fórum em nosso nome, ou qualquer outra coisa que se nos ocorra.

O problema portanto é que o site no qual estamos autenticados, é incapaz de saber se a petição que lhe chega a realizamos nós de forma voluntíria ou se foi injectada por algum ataque CSRF. Normalmente muitos sites são vulneríveis a este tipo de ataques, mesmo que os mecanismos de protecção deles são relativamente simples, sempre e quando os emolduremos também dentro de outro tipo de protecção, como os ataques XSS.

Mecanismos de ataque

Na continuação apresento alguns dos mecanismos mais frequentes mediante os que realizam este tipo de ataques, como os métodos baseados na utilização de imagens scripts de javascript, iframes, ou XMLHttpRequest.

Os mais simples se baseiam na utilização dos atributos src dos rótulos img, script e iframe. Este tipo de ataques são suficientes para aqueles sites que aceitam os parâmetros da ação mediante GET. Por exemplo, poderia ser suficiente indicar uma imagem de tamanho nulo com o atributo src http://www.site.com/page?parametros.

Outra forma de ataque é a utilização de código JavaScript que nos permite realizar ataques a píginas com parâmetros GET como as anteriores, tal como se amostra no seguinte exemplo, mas que também permite de forma muito simples atacar a píginas que utilizem parâmetros via POST.

Bom tive de criar esta imagem visto que o fórum não estava aceitando os scripts.

Bom agora vamos hí defesa como era de se esperar em meus tópicos, pois meus estudos são baseados na segurança.

Mecanismos de defesa

Jí vimos em que consiste este tipo de ataques e os mecanismos que se podem utilizar para implementa-los, que são realmente simples, por isso é hora de ver que mecanismos de defesa existem e daà ver o que nos oferece cada um deles, com suas vantagens e desvantagens.

Uso de um token de sessão pessoal

Este é um dos mecanismos mais utilizados frequentemente, o qual contribui com um bom nàvel de segurança aplicado correctamente. Se baseia na geração e codificação de um número aleatório (token) depois do login do usuírio na aplicação, que se armazena na sessão do usuírio. Em cada formulírio que se lhe presente ao usuírio se inclui um campo oculto no qual se escreve este token. À recepção do formulírio no servidor se comprova que o token se tenha recebido e coincida com o armazenado para o usuírio. Se o token não coincide se aborta a ação do formulírio.

Com o fim de evitar que o token possa ser facilmente visàvel na barra de direcções do navegador ou que chegue em outras píginas via a cabeceira HTTP_REFERER, é aconselhível enviar sempre o token mediante POST. Em aplicações nas quais se utilize uma conexão automítica se o usuírio jí se autenticou anteriormente, também é conveniente fazer com que o valor de token expire, bem de forma independente ou com a sessão, com o objectivo que se alguém obtém o token este caduque passado um tempo.

Uso de um token de sessão pessoal por ação

De forma similar à opção anterior se utilizam tokens gerados de forma aleatória e codificados, mas no entanto, não se utiliza unicamente um token diferente por cada usuírio, mas cada usuírio utiliza um token independente por cada possàvel ação que a aplicação lhe oferece. Estes tokens se geram previamente ao uso das ações e se guardam em um mapa (um Hashtable por exemplo) na sessão do usuírio, associando cada ação com seu token correspondente. Desta forma cada vez que o usuírio solicite uma ação deverí incluir um parâmetro, preferivelmente via POST, que coincida com o valor armazenado para essa ação na sessão.

No caso que um atacante obtivesse acesso a um destes tokens sua margem de actuação seria menor, ficando limitado unicamente à ação sobre a qual esteja definido o token e não pudendo aceder ao resto.

Uso de um token encriptado pessoal por ação

Nesta alternativa se ampla a opção anterior fazendo com que os token gerados para cada ação estejam encriptados a partir de um código ou nome de ação, o identificador de sessão do usuírio e uma palavra secreta comum. Da mesma forma que nos casos anteriores este token se envia via POST em cada ação e a sua recepção se comprova que o valor recebido coincida com o resultante de realizar a mesma operação de encriptação. Desta forma não é necessírio dispor de um mapa em sessão com as ações e o token associado a cada uma, jí que estes tokens não são aleatórios mas se geram a partir de uma função aplicada sobre o código da ação, o identificador de sessão e a palavra secreta.

Esta dependência funcional destes 3 valores faz com que os tokens sejam independentes para cada usuírio, para cada ação, e que estejam associados à sessão do usuírio, de modo que quando esta expire também o faça o token. Por outra parte permite inutilizar todos os tokens em uso em um determinado momento simplesmente mudando a palavra secreta.

Falsa sensação de segurança

As alternativas anteriores permitem alcançar boas cotas de segurança sem ser muito complexa sua implementação, no entanto hí outras alternativas que habitualmente se aceitam como boas e que dão uma falsa sensação de segurança ao não proteger-nos tanto como em um primeiro princàpio muita gente pudesse pensar.

* Formulírios POST: os ataques CSRF não afectam unicamente as píginas que aceitam parâmetros via GET. Bem é certo que estas píginas são mais simples de atacar, e também é certo que é relativamente simples atacar qualquer pígina baseada em POST mediante JavaScript ou XMLHttpRequest.

* Formulírios multipígina: da mesma forma que é possàvel e fícil atacar a píginas com parâmetros POST, também é simples realizar ataques sobre formulírios multipage utilizando por exemplo um XMLHttpRequest.

* Comprovação do Referer: uma técnica habitual para evitar ataques CSRF é comprovar que a cabeceira HTTP_REFERER coincide com a qual se esperaria para essa ação. Isto que hí primeira impressão pode parecer boa ideia não o é tanto jí que esta cabeceira se pode manipular de forma trivial, fazendo com que contenha o que se deseje e permitindo saltar facilmente este controle.

À parte destes mecanismos de falsa segurança, hí uma série de ideias muitas vezes aceitadas que fazem com que este tipo de ataques proliferem.

* Responsabilizar ao usuírio: Ao invés que em outras situações, o usuírio não costuma ter a culpa de padecer este tipo de ataques nem pode fazer nada para impedà-los, mas é tarefa dos programadores colocar os meios para isso.

* Pouco impacto dos ataques: o impacto que pode gerar um ataque CSRF é directamente proporcional às possàveis ações que possa gerar uma aplicação, modificar dados pessoais, publicar informação em nome de outro, comprar produtos, modificar senhas, etc.

*Nem o firewall do servidor, nem a encriptação SSL, nem o framework de programação que se utilize defende a aplicação frente a estes ataques. É tarefa do programador fazer com que a aplicação seja o menos vulnerível possàvel.

Autor: Placker