Protegendo sua aplicação web contra Cross-Site Request Forgery

Construir uma aplicação web segura é uma tarefa árdua hoje em dia. Afinal, existem dezenas de tipos de ataques que podem ser realizados contra ela, sendo que a cada dia que passa novos tipos de ataques vão surgindo.

Boa parte dos ataques está relacionada com vulnerabilidades presentes na infra estrutura da aplicação. É bem comum encontrarmos nosso ambiente de produção com softwares desatualizados, como por exemplo o Sistema Operacional, o Servidor de Aplicações e o SGBD. Outra vulnerabilidade comum ocorre quando esquecemos de remover ou alterar as configurações default de servidores de aplicação, como as páginas de administração e os usuários pré-definidos.

Mas a maior parte dos ataques está relacionada com vulnerabilidades presentes na própria aplicação, sendo responsabilidade do desenvolvedor ou arquiteto conhecer tais vulnerabilidades e principalmente como evitá-las.

Dentre os principais ataques podemos citar:

  • SQL Injection
  • Parameter Injection
  • Cross Site Scripting(XSS)
  • Cross Site Request Forgery(CSRF)
  • Session Hijacking
  • Man In The Middle
  • Unvalidated Redirects/Forwards

Aqui no blog já escrevemos anteriormente sobre alguns desses ataques e como se previnir deles, além de outros tópicos relacionados com segurança. Caso você não tenha lido algum deles, vou listar aqui seus respectivos links:

E neste post o foco será o ataque conhecido como Cross-Site Request Forgery(CSRF), um ataque que ultimamente está bastante comum, sendo inclusive citado pela OWASP como um dos Top 10 ataques/falhas mais comuns em aplicações web, e por conta disso alguns frameworks como Spring Security e Laravel já possuem mecanismos para se proteger contra ele.

Para entender melhor como funciona o ataque CSRF vou utilizar um exemplo que mostrará como estamos vulneráveis a ele. Imagine que você desenvolveu uma aplicação web que possui uma funcionalidade para cancelar um processo. Para que um determinado processo seja cancelado o usuário deve acessar a página do formulário de cancelamento e informar o motivo e a data do cancelamento.
O código desse formulário seria algo como:

<form action="sistema/processos/cancelar" method="post">
    <input type="hidden" name="processo.id" value="38">
    
    <input type="date" name="processo.dataCancelamento">
    <textarea name="processo.motivoCancelamento"></textarea>

    <input type="submit" value="Cancelar Processo">
</form>

Ou seja, cancelar um processo significa disparar uma requisição HTTP para a URL sistema/processos/cancelar, via método POST, levando três parâmetros: processo.id, processo.dataCancelamento e processo.motivoCancelamento.

Agora vamos imaginar que um hacker conseguiu, de alguma maneira, descobrir sobre esse mecanismo de cancelamento de um processo em nosso sistema. Sabendo dessas informações, ele poderia criar uma página HTML idêntica à mostrada anteriormente ou usar algum aplicativo que saiba disparar requisições HTTP, como o cURL, e com isso conseguiria disparar uma requisição válida para o nosso sistema, podendo assim cancelar processos aleatórios, ou até mesmo um processo que ele conheça e seja de seu interesse que o mesmo fosse cancelado. Como nos proteger dessa vulnerabilidade?

A solução é simples: basta implementar no sistema um mecanismo de autenticação. Com isso, os usuários precisariam se autenticar no sistema antes de cancelar um processo. Mas agora como que o servidor saberá se uma determinada requisição foi originada de um usuário autenticado?

Aqui entra um detalhe técnico. Geralmente quando implementamos uma funcionalidade de autenticação trabalhamos com o conceito de Sessões no lado do servidor. Sempre que um usuário se autentica no sistema criamos para ele uma sessão, que nada mais é do que um pequeno espaço na memória do servidor. Cada usuário tem a sua sessão exclusiva, e para diferenciar uma sessão das outras o servidor atribui a ela um identificador único que, geralmente, é devolvido para o usuário em um Cookie que será armazenado em seu navegador, e será enviado automaticamente nas próximas requisições.

Agora se o hacker tentar disparar uma requisição será barrado pelo servidor, pois ele não possui uma sessão ativa, e além disso sua requisição não incluiu o cookie com o identificador da sessão. O único jeito dele efetuar o ataque seria fazendo com que algum usuário autenticado no sistema disparasse a requisição em seu lugar, sem que soubesse disso, ou seja, por meio de um usuário legítimo ele estaria forjando uma requisição válida. Nesse caso como a requisição seria disparada a partir do navegador de um usuário legítimo que está autenticado no sistema, o cookie com o identificador da sessão seria enviado e o servidor aceitaria a requisição.

Esse é o famoso ataque Cross-Site Request Forgery. Para que um hacker consiga realizar esse ataque ele precisa induzir algum usuário a disparar uma requisição para o sistema a ser atacado. Isso pode ser feito com o envio de um email para a vítima contendo um link ou formulário que ao ser clicado/submetido dispara a requisição ao sistema. Aqui o hacker poderia utilizar Engenharia Social para induzir a vítima a realizar a ação desejada.

E agora? Como se proteger desse tipo de ataque?

A solução consiste em criar um mecanismo onde o servidor consiga identificar de alguma maneira se as requisições, mesmo sendo originadas de usuários legítimos e autenticados, foram de fato disparadas de maneira intencional e se foram realizadas dentro do próprio sistema.

O que os frameworks geralmente fazem para implementar tal mecanismo é gerar Tokens de segurança aleatórios, que são válidos apenas para a próxima requisição, e embuti-los nas páginas que possuem formulários, para que quando tais formulários sejam submetidos o servidor possa validar a requisição.

Assim, no nosso exemplo, quando um usuário entrar na tela de cancelamento de processo, o servidor gera um token aleatório e o devolve junto com a resposta, geralmente como um input hidden. Logo, o HTML final exibido no navegador do usuário seria algo como:

<form action="sistema/processos/cancelar" method="post">
    <input type="hidden" name="processo.id" value="38">

    <input type="hidden" name="csrf_token" value="09ktI70ogh1ah0A0S4961IE4QRE871ACGD73OVxuza6yeAInUG0aOYEqfc91nnvhuq7Tdv8">
    
    <input type="date" name="processo.dataCancelamento">
    <textarea name="processo.motivoCancelamento"></textarea>

    <input type="submit" value="Cancelar Processo">
</form>

Repare que agora o formulário possui um novo input hidden chamado csrf_token, contendo um valor gerado de maneira aleatória pelo servidor. Quando submetermos o formulário o servidor deve recuperar esse token e verificar se ele é válido, devendo rejeitar a requisição caso não seja.

No Spring Security conseguimos adicionar esse token em nossas páginas JSP com o seguinte código:

<input type="hidden" name="${_csrf.parameterName}" value="${_csrf.token}"/>

Caso no seu JSP você esteja utilizando a taglib do próprio Spring, ao utilizar a tag form:form o input hidden com o token será adicionado automaticamente.

Já no Laravel existem várias maneiras de se adicionar o token nas páginas, inclusive de modo automático. Caso você esteja trabalhando com o Blade como template engine, por exemplo, pode adicionar o token manualmente em suas páginas da seguinte maneira:

<input type="hidden" name="_token" value="{{ csrf_token() }}"/>

Agora mesmo que o hacker consiga induzir o usuário a clicar em algum link ou formulário falso, a requisição será rejeitada pelo servidor, pois o formulário do hacker não vai possuir o token de segurança. O hacker até poderia tentar adicionar o token no formulário falso, mas para isso ele precisaria descobrir um valor válido para o token, algo que seria praticamente impossível, uma vez que cada token é gerado de maneira aleatória e somente é válido para uma única requisição.

Pronto! Agora estamos protegidos. 🙂
Pelo menos para esse tipo de ataque, mas lembre-se de que existem dezenas de outros possíveis ataques.

E você, já precisou se proteger desse tipo de ataque alguma vez? Conte-nos como foi a experiência e se utilizou algum framework ou biblioteca.

16 Comentários

  1. Evaldo Wolkers 16/09/2015 at 07:56 #

    Olá, ótimo texto.
    Após anos de experiência com desenvolvimento e sem conhecimento de segurança, resolvi entrar nesta área fazendo minha especialização em segurança da informação.
    Percebi que a maioria dos desenvolvedores não tem um conhecimento mínimo de segurança, o que torna suas aplicaçoes vulneráveis.
    Com o objetivo de introduzir o conceito de segurança ao desenvolvedor, escrevi o livro “Segurança da Informação em Aplicações Web com Grails” disponível em http://www.lcm.com.br/site/#/livros/detalhesLivro/seguranca-da-informacao-em-aplicacoes-web-com-grails.html

  2. Rodrigo Ferreira 16/09/2015 at 08:52 #

    Oi Evaldo,

    Realmente a maioria dos desenvolvedores tem muito pouco conhecimento na área de segurança =/

    Muito bacana seu livro.
    Se for do seu interesse você poderia entrar em contato com o pessoal da editora Casa do Código, para quem sabe escrever um livro por lá. Se não me engano não temos nenhum livro focado em segurança.

    Abraços!

  3. Luiz Henrique Leme 17/09/2015 at 07:55 #

    Concordo com o Rodrigo.

    O Evaldo, poderia publicar o livro pela Casa do Código. Além do que poderiam ter outros livros de segurança para as plataformas Java, Ruby, .Net

  4. Daniel Faria 17/09/2015 at 08:45 #

    @Rodrigo

    Excelente post e série sobre assunto no blog.Sou desenvolvedor e realmente tenho muito conhecimento sobre segurança.Fica a sugestão de um livro sobre o tema na casa do código ou até um curso no Alura.

    Você recomenda algum livro sobre assunto?

    @Evaldo

    Vou olhar o livro aqui, obrigado pela sugestão.

  5. Rodrigo Ferreira 17/09/2015 at 08:49 #

    Oi @Daniel,

    Tem um livro que eu não cheguei a ler, mas me disseram que é bom: Web Application Security, A Beginner’s Guide

    Abraço!

  6. Jhonatan Morais 22/09/2015 at 10:42 #

    Otimas Dicas, e reunião de mais artigos relacionados. Ainda bem que a maioria dos frameworks nos ajudam nestas soluções de segurança. 😀

  7. Vinicius Martins Rosa 22/09/2015 at 11:23 #

    Muito bom post.
    Eu me encaixo nesse grupo de desenvolvedores com pouca noção de segurança, e de um tempo para cá tento sempre ler tópicos sobre o assunto! Mais um post sensacional do pessoal do blog da Caelum!
    Fiquei com duas dúvidas,a primeira é:Para ter o token inserido pelo security, basta eu usa-lo como autenticador de minha aplicação ou preciso fazer alguma config a mais?
    e a segunda , desde qual versão do security essa feature foi introduzida?

  8. Rodrigo Ferreira 22/09/2015 at 11:28 #

    Oi Vinicius,

    1) Basta habilitar o Spring Security na sua aplicação, e assim já dá para adicionar os tokens nas páginas;
    2) Essa feature entrou no Spring Security 3.2.0

    Abraços!

  9. Thiago Alves 22/09/2015 at 21:03 #

    Excelente artigo.

    Faltou o jabá para o FJ-27, de Spring… kkkk

    Fiz ele, e essa parte foi muito bem explicada também

  10. Luítame de Oliveira 05/10/2015 at 19:42 #

    Texto muito bom. Atualmente tenho usado bastante o Laravel e tenho desfrutado disso. Abs!

  11. Daniel Sava 28/10/2015 at 11:27 #

    Ótimo artigo: simples e esclarecedor. Pra quem utiliza JSF, fica uma dica de leitura: http://www.oracle.com/webfolder/technetwork/tutorials/obe/java/JSF-CSRF-Demo/JSF2.2CsrfDemo.html

  12. Rodrigo Ferreira 28/10/2015 at 13:21 #

    Oi @Daniel,

    Bem bacana a dica!
    JSF também já tem proteção nativa contra CSRF, desde a versão 2.2(JavaEE 7).

    Abraços!

  13. Evaldo 20/12/2015 at 22:14 #

    Olá Rodrigo e Luiz Henrique.

    Acho interessante sim escrever pela Casa do Código, aliás, tenho um amigo que já lançou dois livros, o Henrique Lobo.

    Se pudermos conversar mais sobre isso, estou à disposição (evaldowolkers@gmail.com)

    Abraços,

    Evaldo Wolkers.

Deixe uma resposta