O documento discute tópicos importantes de segurança em aplicações Rails, incluindo: 1) Como sessões funcionam e como mantê-las seguras; 2) Problemas como roubo e reenvio de sessões e como evitá-los; 3) Boas práticas como não armazenar dados críticos em sessões.

1. Segurança em Rails
Marcelo Castellani
marcelo@mindaslab.com

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. O que é segurança?
• Confiabilidade
• Integridade
• Confidencialidade

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. 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. 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. O que é segurança?
• Confiabilidade
• Integridade
• Confidencialidade

13. Sessões

14. HTTP É UM PROTOCOLO QUE
NÃO MANTÉM ESTADO
Sessões fazem com o estado seja mantido.

15. 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.

16. 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.

17. 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

18. Ethereal/Wireshark

19. 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.

20. Por que não usar cookies?
• Outro exemplo clássico de problema com
cookies é o “replay de cookies”.

21. 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.

22. 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.

23. 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).

24. 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

25. Fixação de sessão

26. Como evitar?
• Uma única linha de código salva sua vida
nesses casos:
reset_session

27. 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

28. 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.

29. 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.

30. 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.

31. 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.

32. BCrypt
http://gom-jabbar.org/articles/2008/12/03/why-you-should-use-bcrypt-to-store-your-passwords

33. Mais sobre criptografia

34. Cross-Site reference forgery (CSRF)

35. 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.

36. 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.

37. Cross-Site reference forgery (CSRF)

38. 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.

39. “Every developer
working with the Web
needs to read this
book.”
David Heinemeier
Hansson, creator of
the Rails framework

40. 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.

41. 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.

42. SQL Injection no banco de dados de usuários do
Speedy, em 10 de julho de 2009
http://telefonica.ath.cx/

43. SQL INJECTION NÃO É
EXCLUSIVIDADE DO RAILS
O site da telefonica é em PHP.

44. USUÁRIOS SEMPRE SÃO A
PARTE MAIS FRÁGIL DA
SEGURANÇA
E não há nada que você possa fazer.

45. Seu site?

46. 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”.

48. 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/

50. OBRIGADO!!!
marcelo@mindaslab.com - RS on Rails 2009