Segurança em Rails

Marcelo Castellani

marcelo@mindaslab.com

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.

O que é segurança?

• Confiabilidade• Integridade• Confidencialidade

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

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

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

O que é segurança?

• Confiabilidade• Integridade• Confidencialidade

Sessões

HTTP É UM PROTOCOLO QUE NÃO MANTÉM ESTADO

Sessões fazem com o estado seja mantido.

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.

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.

Seqüestro/Roubo de sessão

Ethereal/Wireshark

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.

Por que não usar cookies?• Outro exemplo clássico de problema com

cookies é o “replay de cookies”.

Replay de cookies

Replay de cookies

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

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

Fixação de sessão

Como evitar?

• Uma única linha de código salva sua vida nesses casos:

reset_session

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

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.

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.

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.

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.

BCrypt

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

Mais sobre criptografia

Cross-Site reference forgery (CSRF)

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.

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.

Cross-Site reference forgery (CSRF)

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.

“Every developer working with the Web needs to read this book.”

David Heinemeier Hansson, creator of the Rails framework

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.

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.

SQL Injection no banco de dados de usuários do Speedy, em 10 de julho de 2009

http://telefonica.ath.cx/

SQL INJECTION NÃO É EXCLUSIVIDADE DO RAILS

O site da telefonica é em PHP.

USUÁRIOS SEMPRE SÃO A PARTE MAIS FRÁGIL DA SEGURANÇA

E não há nada que você possa fazer.

Seu site?

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

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/

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