Já criou algo no Rails 2.0? Mesmo que apenas para testar? Já viu o arquivo application.rb?

class ApplicationController < ActionController::Base
  helper :all

  protect_from_forgery
end

Hmm… protect_from_forgery? Para que diabos serve isto? Antes de explicar, me deixa contar uma história…

Calma é uma história chata, mas é curta, e depois fica legal

Já ouviu falar de Cross Site Scripting? Este é o nome de uma falha de segurança encontrada facilmente em grande parte dos websites e aplicações web que permite à pessoas maldosas (aqui estou me referindo à adolescentes sem nada para fazer e sem vida social) alterarem o conteúdo de páginas web, incluírem conteúdo hostil, executarem ataques de phishing, obterem o controle do navegador através de códigos JavaScript e na maioria dos casos forçarem o usuário a executar algum comando que eles desejem. Este último tipo de ataque se chama cross­site request forgeries.

O Cross Site Request Forgeries é um tipo de ataque que consiste em obrigar usuários legítimos a executarem uma série de comandos sem nem mesmo saberem disto. E agora com o aumento do uso de Ajax, a coisa tem ficado ainda pior. Já ouviu falar do Samy Worm?

Samy é o meu herói

Talvez você não o conheça, mas o MySpace.com conhece muito bem, na verdade conhece mais do que gostaria. Graças a uma falha de segurança em um código JavaScript, o tal do “Samy”, um garoto solitário e sem amigos (e por isso, um cara muito mal), descobriu uma forma nova de fazer amizades na internet. Ele conseguiu atráves de técnicas de Cross Site Scripting injetar um bloco de código (JavaScript) na sua página pessoal. Este código fez nada mais, nada menos que adicionar automaticamente como “amigo” cada pessoa que entrasse na sua página. O mais interessante é que depois disso o código também era passado para a página do novo “amigo” e ainda incluía a frase “O Samy é meu herói” no perfil da pessoa. Em questão de poucas horas ele ser tornou o herói de mais de um milhão de pessoas e o grande amigão do MySpace. E provavelmente deve ter levado uma bela surra dos seus pais quando a policia chegou na sua casa.

Graças ao Samy, o MySpace caiu, os funcionários levaram uma boa ralada do chefe e sofreram durante alguns dias para se recuperarem dos danos.

O que isso tem a ver com Rails?

Tudo! O caso do MySpace foi algo bem simples, que se resolveu apagando o “Samy” do banco de dados. Mas com certeza você não gostaria de ter o Samy cadastrado em seu site, correto? O problema é que existem muitos Samys por aí…

E a droga do método protect_from_forgery, para que serve???

Calma! O método protect_from_forgery serve para te proteger do Samy!

Na verdade, este método serve para nos assegurar de que todos os formulários que sua aplicação está recebendo estão vindo dela mesma, e não de um link perdido de algum outro site. Ele consegue isto incluindo um token (se você não sabe o que é um token, clique aqui) baseado na sessão em todos os formulários e requisições Ajax geradas pelo Rails, e depois verifica a autenticidade deste token no controller.

Há, eu já ia me esquecendo… requisições via GET não são protegidas. Mas isto não é um problema, afinal elas só devem ser usadas para nos trazer dados, e nós nunca às usamos para alterar ou gravar algo em nosso banco de dados, não é verdade? NÃO É VERDADE?

Se quiser aprender mais sobre CSRF(Cross-Site Request Forgery, ué) use os links abaixo:

• isc.sans.org/diary.html?storyid=1750
• en.wikipedia.org/wiki/Cross-site_request_forgery

Mas lembre-se que isto NÃO é uma solução definitiva para nosso problema, ou como costumamos dizer, não é uma bala de prata. Continuem espertos, e por favor deixem este método lá.