O ataque das requisies cross-site

s vezes, at mesmo ING, YouTube, New York Times e Google se enganam

Coluna do Kurt

COLUNA

taques do tipo cross-site request forgery (CSRF ou XSRF) esto se tornando rapidamente um srio problema de segurana desconhecido da maioria dos programadores e usurios. O CSRF um ataque baseado na Web que deriva do (mas ainda permanece semelhante ao) tradicional ataque cross-site scripting, ou XSS. Num ataque XSS, o agressor fornece contedo malicioso numa aplicao web (por exemplo, criando uma URL mal formada ou embutindo cdigo hostil numa caixa de resposta) que resulta em contedo hostil tal como JavaScript inserido em cdigos at ento seguros que sero servidos s vtimas. Ataques CSRF levam esse comportamento um passo adiante, inserindo contedo hostil que resulta numa ao por parte do navegador do usurio, como alterar a congurao de um ltro no webmail ou efetuar uma transferncia bancria pelo site do banco.

Exemplo de ataque

Ento voc entra em sites de rede social para conversar com amigos. Infelizmente, o site em questo permite que os usurios insiram imagens em conversas via Web (por exemplo, avatares de um frum). Em vez de usar uma URL como:
<img src="http://site-aleatrio/imagem.jpg">

o agressor usa a URL:

<img src="http://site-social/changepassword?newpassw ord=senha000">

Assim, quando o navegador web do usurio tenta carregar a imagem, ele se conecta ao site da rede social e executa um comando para alterar a senha. Esse ataque tambm pode ser executado a partir de outros sites. Por exemplo, se um usurio permanece logado no site da rede social enquanto navega em outra
14

aba e uma imagem de outro site aponta para a URL de mudana de senha, essa aba executa o comando e altera a senha do usurio, a menos que o site tenha protees especcas contra CSRF. Os ataques CSRF se popularizaram por trs motivos simples. O primeiro o crescimento de servios baseados na Web tais como email, comrcio online, Internet banking etc. Ataques CSRF podem resultar em envio de dinheiro para um agressor por sites de bancos ou de compra e venda de aes. Webmails permitem que o agressor altere ou pea cpias das senhas de vrios servios, como registros DNS e sites de comrcio eletrnico. Os agressores podem monetizar esses ataques pelo direcionamento do acesso a contas bancrias, alterao da senha do usurio etc. Algo to simples quanto alterar uma senha pode resultar no uso da conta, domnio ou servio como refm. Por uma pequena taxa, o agressor altera a senha e devolve-a ao usurio. O segundo motivo a presena da navegao por abas. Quando os navegadores Web surgiram, navegar pela Internet era uma tarefa totalmente serial. No me ocorreu durante algum tempo que eu algum dia precisaria de mais de uma sesso, porque o contedo no era to signicativo que me zesse conserv-lo (a navegao era literalmente navegao). Entretanto, com o advento do webmail, agora tenho trs sesses simplesmente logadas (mas paradas) para eu conseguir enviar emails rapidamente e ser noticado quando chegarem novas mensagens. Isso signica que um ataque CSRF tem muito mais chance de sucesso porque estou sempre logado em meu webmail (eu uso um navegador separado para o email, justamente para evitar esse problema). O terceiro motivo que a maioria das aplicaes web no tem qualquer segurana. Elas so absolutamente terrveis na ltragem dos dados fornecidos pelo usurio, e com isso permitem que agressores injetem contedo malicioso (como JavaScript) por meio de diversas vulnerabilidades

http://www.linuxmagazine.com.br

Insegurana | COLUNA

a XSS. Embora eu raramente visite websites hostis, visito vrios sites conveis que sei (por constatao) que no possuem segurana adequada e podem resultar em ataques XSS, culminando na viabilizao de ataques CSRF. Alm disso, poucas aplicaes web implementam protees contra CSRF para evitar tais ataques. A forma de vencer o CSRF conceitualmente simples, mas, dependendo da aplicao web, sua implementao pode variar entre fcil e quase impossvel. Para vencer ataques CSRF, uma aplicao precisa simplesmente assegurar que todas as requisies sejam realizadas de forma adequada; em outras palavras, sua aplicao precisa manter seu estado para que o contedo da aba A que est logada no seu webmail seja o nico com permisso de enviar emails, e uma requisio feita pelo contedo da aba B, que est num website hostil, no resulte no envio ou leitura de emails. Para isso, sua aplicao web precisa manter informaes de estado. Mas a Web foi projetada como um sistema sem estado desde o princpio, ento qualquer acrscimo de estado requer truques tcnicos, pois o navegador em si no tem como ajudar diretamente. Para vincular o contedo de uma pgina requisio feita de forma correta a partir de outra pgina (isto , o usurio preenche um formulrio e clica em Enviar), preciso passar um one-time token no contedo, que o navegador ento repassa com a requisio, permitindo que se conrme que a requisio veio do local correto.

Defesas para programadores

simplesmente bloquear as invlidas, evitando assim que a aplicao sequer as enxergue. A desvantagem (ou potencialmente uma vantagem, dependendo do ponto de vista) que os usurios no podem mais adicionar a pgina aos favoritos, j que o one-time token no ser mais vlido. cookies
PHP: setcookie(Cookie_do_token, $textoaleatrio);

Os cookies precisam estar ativados para isso funcionar, e potencialmente podem ser roubados por um agressor inteligente (vrias falhas de navegadores j permitiram o roubo de cookies ao longo dos anos). A vantagem dessa tcnica, contudo, ser invisvel para o usurio e no exigir que o HTML seja exibido para o usurio ou que a URL a ser usada precise de modicaes; exigncias do back-end: todos esses exemplos requerem alguma forma de back-end para armazenar os dados de sesso e criar tokens para elas, compar-los e permitir ou rejeitar requisies com base neles. Alm disso, aplicaes baseadas na Web podem precisar de modicaes (por exemplo, se campos ocultos de formulrio forem usados para passar os dados). A boa notcia que cada vez mais aplicaes web esto implementando essa proteo por padro. Por exemplo, o popular framework Joomla agora possui a funo JRequest::checkToken(). A boa notcia que h um grande nmero de defesas contra ataques CSRF. Uma muito comum o plugin NoScript do Firefox. Infelizmente, para o NoScript ser ecaz necessrio desativar o JavaScript por padro e ento ativ-lo seletivamente para os sites conveis. Isso leva a questes bvias de usabilidade, pois muitos sites nem funcionam sem JavaScript. Alm disso, essa tcnica no impede que um agressor realize um ataque XSS em um site em que voc cona. Um navegador que incorporou essa estratgia o Google Chrome. Cada aba do Chrome um processo separado, e no uma thread com o mesmo contexto das outras abas. Portanto, as abas no podem interferir entre si, o que impede a maioria dos ataques CSRF. Para sofrer um ataque, seria preciso fazer login num servio baseado na Web e em seguida usar essa mesma aba para visitar um site hostil.
Kurt Seifried consultor de segurana da informao especializado em redes e Linux desde 1996. Ele frequentemente se pergunta como a tecnologia funciona em grande escala mas costuma falhar em pequena escala.

Envio e recepo de tokens

Defesas para usurios

Esse one-time token pode ser enviado e recebido de diversas maneiras: campos ocultos em formulrios
<input type=hidden name=token value=textoaleatrio />

A vantagem, nesse caso, que muitas aplicaes suportam a incluso de campos de formulrio e a lgica para process-los. A desvantagem que pginas web que no usam formulrios mas ainda permitem interao no tm uma soluo to fcil assim; componentes de URL (seja dentro da URL ou como parmetros)
http://exemplo.org/novasenha?nova=senha&token=texto aleatrio

Esta tem a vantagem de disponibilizar os dados para o servidor para que se possa, em teoria, usar um mdulo do Apache para validar todas as requisies e

Linux Magazine #51 | Fevereiro de 2009

15