Edge Rails: Requisições AJAX não terão mais validação de tokens

17 de abril de 2009  |  Edge Rails  | 

Faz tempo que não escrevo sobre as novidades para a próxima versão do Rails, mas esta em particular me chamou a atenção. No Rails 3.0 não teremos mais a validação de tokens em requisições AJAX.

Este tipo de validação por tokens é essencial para evitar ataques do tipo CSRF. Ao montar um formulário HTML, automaticamente o Rails adiciona um token (um código com letras e números baseado no id da sessão atual) ao formulário, quando o mesmo é enviado de volta ao servidor é possível então verificar se aquele formulário está vindo de uma sessão valida ou se está vindo de algum outro site malicioso.

Até então, este token por padrão também era adicionado automaticamente às chamadas AJAX através dos helpers do Rails. Mas ao criar os seus próprios códigos AJAX Javascript, era necessário que você manualmente incluísse este token para que sua requisição não fosse recusada pelo servidor.

Mas requisições AJAX maliciosas não podem produzir ataques do tipo CSRF, então todo este trabalho manual era desnecessário, e por isto será retirado do Rails na próxima versão. Particularmente eu gostei disso.


5 Comentários


  1. Olá Carlos,

    Primeiramente parabéns pelo blog, excelente conteúdo.

    Também achei interessante removerem isso. Mas ataques CSFR não podem mesmos serem realizados via AJAX?

    Não me lembro bem onde li que estavam implementando AJAX sob domínios diferentes. Se não me engano, era a Mozilla que estava fazendo testes desse recurso. Soube algo a respeito?

    Abraços

  2. Gabriel, não fiquei sabendo de nada disso. Mas é algo interessante a se pesquisar.

    Eu sei que todos os navegadores em suas politicas de segurança não permitem isso.

  3. Carlos, somente a validação do token não é suficiente para garantir que o forgery não ocorrerá, isso acontece pois caso a sua aplicação esteja vulnerável a xss, o seu token poderá estar exposto e a solicitação maliciosa irá ocorrer com o token. Se não existir proteção contra xss, a proteção contra request forgery pode não servir de nada.
    As políticas de same origin são de forma geral ruins na maioria dos browsers.
    De uma olhada nesta referência:
    http://code.google.com/p/browsersec/wiki/Part2#Same-origin_policy

  4. Carlos,

    Encontrei um link no site do framework Dojo (http://www.dojotoolkit.org/node/87) e do Bugzilla (https://bugzilla.mozilla.org/show_bug.cgi?id=389508):

    “The browser security model does not allow using XMLHttpRequest (XHR) from one web page domain to contact an URL on another domain. However, there are cases when it would be nice to do cross domain XHR requests. There is a proposal in the W3C’s Web API group to address this need (see this Mozilla tracking bug, and the bug comments for a link to the proposal).”

    Pelo que indica estão implementando isso. Nesse caso, não acho que seria prudente remover porque, em teoria, teremos suporte a Cross Domain XHR.

  5. Pra evitar um XSRF/CSRF só solicitando uma nova autenticação, estes recursos minimizam o risco e dificultam a exploração, mas não são uma solução definitiva. Basta ver os internet banking, aquela autenticação chata, antes de qualquer transação, é a única solução efetiva para evitar CSRF.

    Quanto ao Cross-Domain, existe maneiras de burlar o cross-domain, como esta usando css: http://ajaxian.com/archives/csshttprequest-cross-domain-ajax-using-css-for-transport

Deixe um comentário