Segurança em Rails

1,396 views
1,311 views

Published on

Nesta palestra mostrarei as mais comuns falhas de segurança cometidas por desenvolvedores em projetos Ruby on Rails, e como as evitar.

por de Marcello Castellani no 1° RS on Rails

Published in: Technology, Sports
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,396
On SlideShare
0
From Embeds
0
Number of Embeds
119
Actions
Shares
0
Downloads
39
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Antes de começar vamos falar de duas coisas, o que é segurança e se seu site é seguro.
  • Antes de começar vamos falar de duas coisas, o que é segurança e se seu site é seguro.
  • Perguntar para o pessoal da platéia quem tem programas rails rodando em versões menores do que a 2.3.3
  • Pedir para o pessoal dar exemplo de aplicações com sessões
  • Se você utiliza o popular plugin RestfulAuthentication para manutenção de usuários, adicione reset_session à action SessionsController#create. Note que isso remove qualquer valor da sessão, você precisa transferi-los para a nova sessão.
  • Bcrypt é mais lento, e mais eficiente. O algoritmo usado no BCrypt é blowfish, o mesmo usado no FreeBSD e no Linux kernel,v2.5.47ou superior. Muitos preferem o md5 ou o sha1 por serem mais rápidos.
  • Segurança em Rails

    1. 1. Segurança em Rails Marcelo Castellani marcelo@mindaslab.com
    2. 2. O palestrante (eu) • Desenvolvedor de software desde 1989; • Membro do NetBeans Translation Team; • Um dos fundadores do grupo de usuários de Ruby de SP; • Idealizador do evento Ruby + Rails no mundo real.
    3. 3. O que é segurança? • Confiabilidade • Integridade • Confidencialidade
    4. 4. Confiabilidade • Em geral, confiabilidade (definição sistêmica) é a capacidade de uma pessoa ou sistema de realizar e manter seu funcionamento em circunstâncias de rotina, bem como em circunstâncias hostis e inesperadas. • http://pt.wikipedia.org/wiki/Confiabilidade
    5. 5. Integridade • Em segurança da informação integridade significa ter a disponibilidade de informações confiáveis, corretas e dispostas em formato compatível com o de utilização, ou seja, informações íntegras. • http://pt.wikipedia.org/wiki/Integridade
    6. 6. Confidencialidade • Confidencialidade é a propriedade de que a informação não estará disponível ou divulgada a indivíduos, entidades ou processos sem autorização. • http://pt.wikipedia.org/wiki/Confidencialidade
    7. 7. O que é segurança? • Confiabilidade • Integridade • Confidencialidade
    8. 8. Sessões
    9. 9. HTTP É UM PROTOCOLO QUE NÃO MANTÉM ESTADO Sessões fazem com o estado seja mantido.
    10. 10. O Que é uma sessão? • Uma sessão consiste em um hash de valores e um id de sessão, geralmente uma string com 32 caracteres, para identificar o hash. • Cada cookie enviado para o browser do usuário inclui o id de sessão. • No caminho inverso, o browser enviará o id de sessão para o servidor em cada request.
    11. 11. Pra que serve uma sessão? • A maioria das aplicações precisam ter controle sobre alguns aspectos relacionados ao estado de um usuário particular como um carrinho de compras ou o id do usuário atualmente autenticado. • Sem a ideia de sessões, o usuário teria que se identificar a cada nova requisição.
    12. 12. Seqüestro/Roubo de sessãoLogin Usuário real faz login no site Sniffingderede Invasor obtém o ID do usuário Sequestro Invasor passa a ser o usuário real
    13. 13. Ethereal/Wireshark
    14. 14. Rails e Sessões • O Rails fornece vários métodos para salvar os dados de sessões, incluindo o ActiveRecordStore e o CookieStore. • O ActiveRecordStore salva os dados da sessão numa tabela no banco de dados. • O CookieStore salva os dados da sessão como um cookie no cliente.
    15. 15. Por que não usar cookies? • Outro exemplo clássico de problema com cookies é o “replay de cookies”.
    16. 16. Replay de cookies Um usuário recebe créditos, o valor é armazenado na sessão (o que é uma má idéia, de qualquer forma, mas nós iremos fazer isso para fins de demonstração). O usuário compra algo.
    17. 17. Replay de cookies Seu novo crédito, mais baixo, será armazenado na sessão. O lado negro do usuário o força a pegar o cookie do primeiro passo (o qual ele copiou) e substituir o cookie atual no navegador. O usuário tem seus créditos de volta.
    18. 18. Como evitar? • A melhor solução contra ataques de replay é não guardar este tipo de informação no cookie de sessão, mas sim no banco de dados. • Neste caso guarde os créditos no banco de dados o id do usuário atual na sessão (pode ser até num cookie, apesar de eu nunca achar uma boa idéia usar cookies).
    19. 19. Evitar cookies na minha aplicação • Para não usar cookies em sua aplicação vá em config/initializers/session_store.rb e use: ActionController::Base.session_store = :active_record_store
    20. 20. Fixação de sessão
    21. 21. Como evitar? • Uma única linha de código salva sua vida nesses casos: reset_session
    22. 22. user_sessions_controller.rb def create reset_session @client_session = ClientSession.new(params[:client_session]) if @client_session.save flash[:notice] = "Login successful!" redirect_back_or_default '/' else flash[:notice] = "Invalid login name or password." render :action => :new end end
    23. 23. Outras maneiras de proteger-se • salvar propriedades específicas do usuário na sessão, • verificá-las a cada novo request, • negar acesso se a informação não bater.
    24. 24. Não use o IP para salvar dados • Ao salvar o endereço IP, você deve ter em mente que existem provedores de serviços de Internet ou grandes organizações que colocam seus usuários atrás de proxies. Estes proxies podem mudar durante a duração de uma sessão, logo estes usuários não serão capazes de utilizar sua aplicação, ou apenas poderão usá-la de forma limitada.
    25. 25. Resumo sobre sessões • Use authlogic ou algo parecido para gerenciar logins em seu software. • Use algoritmos de criptografia complexos, nada de hashes. O BCrypt é a melhor opção. • Reinicie sempre a sessão antes de a criar. • Evite usar cookies sempre que possível. • Evite usar o IP para manter dados em sessões.
    26. 26. Boas práticas em sessões • Não guarde dados críticos na sessão. • Não guarde objetos muito grandes em uma sessão. • Evite usar cookies para armazenar dados da sessão.
    27. 27. BCrypt http://gom-jabbar.org/articles/2008/12/03/why-you-should-use-bcrypt-to-store-your-passwords
    28. 28. Mais sobre criptografia
    29. 29. Cross-Site reference forgery (CSRF)
    30. 30. Como funciona • Bob navega por um fórum de discussão e visualiza uma mensagem criada por um hacker onde existe um elemento HTML de imagem forjado. O elemento referencia um comando na aplicação de gerenciamento de projetos de Bob, ao invés de um arquivo de imagem. <img src="http://www.webapp.com/project/1/destroy"/> • A sessão de Bob em www.webapp.com ainda está ativa, porque ele não fez seu logout alguns minutos atrás. • Por acessar a mensagem, o navegador encontra uma tag de imagem. Ele tenta carregar a imagem suspeita a partir de www.webapp.com. Como explicado anteriormente, ele também enviará o cookie com id de sessão válido.
    31. 31. Como funciona • A aplicação web em www.webapp.com verifica a informação do usuário no respectivo hash de sessão e destroy o projeto com ID 1. Ele então retorna a página com o resultado da operação, o que é um resultado inesperado para o navegador, logo ele não irá exibir a imagem. • Bob não percebe o ataque — Mas alguns dias mais tarde ele percebe que o projeto número um se foi.
    32. 32. Cross-Site reference forgery (CSRF)
    33. 33. Como evitar? • Saiba como usar o HTTP: • Get serve para perguntas, como uma pesquisa ou operação de leitura; • Post server para executar ordens. • É muito importante conhecer HTTP pois ele é a base de aplicações internet. • É muito importante conhecer o Rest, pois o Rails faz uso de Rest o tempo todo.
    34. 34. “Every developer working with the Web needs to read this book.” David Heinemeier Hansson, creator of the Rails framework
    35. 35. Injection • Injeção é uma categoria de ataques que introduzem código malicioso ou parâmetros em uma aplicação web de forma a executar estes códigos dentro do contexto de segurança da aplicação. Os exemplos mais proeminentes de injeção são o cross-site scriptintg (XSS) e o SQL injection.
    36. 36. Injection não é algo simples • Injeção é algo complicado, porque um mesmo código ou parâmetro pode ser malicioso em um contexto e completamente inofensivo em outro. Um contexto pode ser um script, uma query ou linguagem de programação, o shell ou um método do Ruby/Rails.
    37. 37. SQL Injection no banco de dados de usuários do Speedy, em 10 de julho de 2009 http://telefonica.ath.cx/
    38. 38. SQL INJECTION NÃO É EXCLUSIVIDADE DO RAILS O site da telefonica é em PHP.
    39. 39. USUÁRIOS SEMPRE SÃO A PARTE MAIS FRÁGIL DA SEGURANÇA E não há nada que você possa fazer.
    40. 40. Seu site?
    41. 41. Gerenciamento de usuários • Exija a autenticação de usuários usando plugins prontos para isso, como o Authlogic; • No cadastramento de seu usuário, exija que o mesmo digite duas vezes a senha e o e-mail; • Crie regras para que o usuário não crie senhas como “eu” ou “senha”.
    42. 42. Mais informações • http://guias.rubyonrails.pro.br/security.html • Conheça o site: http://www.rorsecurity.info/ • Conheça o Nessus: http://www.nessus.org/
    43. 43. OBRIGADO!!! marcelo@mindaslab.com - RS on Rails 2009

    ×