7. Sessões
• HTTP é um protocolo stateless
• Sessão é identificada por um cookie
(contendo uma identificação e um hash)
• Enviado do servidor para o cliente, e do
cliente para o servidor
10. Roubo de Sessão
• Roubo de um arquivo de cookie por um
“atacante”
• Permite que o atacante aja em nome da vítima
11. Como uma sessão pode ser
roubada?
Roubo Como combater?
Sniffers em uma rede SSL (https)
Utilizar computadores Botão “logout”,
“públicos” expirar sessão
Session Fixation (mais adiante)
XSS (mais adiante)
18. Replay Attack no
CookieStore
1. Usuário ativa um cupom de presente na sua loja
online, ficando com R$50 de crédito (armazenado
na sessão)
2. Usuário compra algo custando R$40
3. Sessão agora armazena que usuário tem R$10
4. Usuário sobreescreve a sessão atual pela sessão
inicial, ficando com R$50 novamente
26. CSRF
• Cross-Site Request Forgery
• Trata-se de aproveitar da sessão de um
usuário, forçando-o (muitas vezes sem
saber) a realizar determinada ação
37. Uploads de arquivos
• Algumas (várias?) aplicações aceitam
uploads, recebendo um arquivo e um nome
de arquivo.
• Se você armazena os arquivos em /var/
www/uploads, imagine se alguém fizer
upload de um arquivo chamado
../../../etc/passwd ?
38. Como combater uploads
maliciosos?
Evite receber o nome do arquivo, ou crie um
filtro com expressão regular.
40. DoS por uploads
• Se seu site processa arquivos (como
imagens, gerando miniaturas), nunca faça-o
sincronamente.
• Imagine alguém enviando milhares de
arquivos ao mesmo tempo?
41. Como combater DoS
por uploads?
Processe arquivos assincronamente (em um
daemon ou em um cron); se possível, até em
uma máquina separada.
43. Upload de executáveis
• Você terá problemas se armazenar seus
arquivos em algum local "autorizado" a
executar executáveis (como .CGI no
Apache Document Directory do seu Virtual
Host)
44. Como combater DoS
por uploads?
Simplesmente tenha certeza que seu servidor
web não está executando arquivos naquele
diretório.
49. Como combater downloads
não autorizados?
Opcionalmente, armazene o nome do
arquivo no banco de dados, identificando-
o para o usuário através de um id.
57. Como combater ataque
de força bruta?
CAPTCH depois de determinadas tentativas
falhas de login.
Utilize uma mensagem de erro genérica, como
“usuário OU senha inválido, tente novamente”.
60. Hijacks diversos
• Senhas: requira que o usuário digite a antiga
senha para conseguir mudar.
• Email: requira que o usuário digite a antiga
senha para conseguir mudar
61. Hijacks diversos
• Senhas: requira que o usuário digite a antiga
senha para conseguir mudar.
• Email: requira que o usuário digite a antiga
senha para conseguir mudar
• Outros: lembra do “problema” do GMail?
75. Whitelist rula!
• before_filter :only => [...] ao invés de
before_filter :except => [...]
• attr_accessible ao invés de attr_protected
• Permita somente <strong> ao invés de
remover <script>
80. XSS
• Cross Site Scripting
• Atualmente é o tipo de ataque mais comum,
segundo a Symantec Global Internet Security
Threat Report.
• Mais de 510.000 sites tiveram este tipo de
ataque só em abril de 2008.
• Diversas ferramentas para auxiliar estes
ataques, como o MPack.
87. Como combater estes
ataques XSS?
Limpe a “entrada” do usuário com o método
sanatize.
Limpe a “saída” (impressão) com
escapeHTML(), também chamado de h().
<%=h @user.name %>
92. Dicas sobre a interface
administrativa
• Coloque-a em um subdomínio distinto,
como admin.campusparty.com.br. Isso evita
truques com Cookies.
• Se possível, limite o acesso administrativo a
um número restritos de IP (ou a uma faixa).
• Que tal uma senha especial para ações
importantes, como deletar usuários?