Este documento discute segurança de aplicações web, definindo o que são aplicações web e webservices, e abordando riscos, vulnerabilidades e exemplos comuns, como parâmetros inválidos, controle de acesso falho e injeção de comando/SQL. O foco é que a segurança começa com o código da aplicação e que a maioria das invasões ocorrem devido a vulnerabilidades na codificação.

1. Segurança de aplicações Web
Alex Hübner, CFUG-SP
alex@cfugsp.com.br

2. 2
O que são aplicações web?
 Softwares (sites) na arquitetura
cliente/servidor em protocolo HTTP
 Cliente universal: o browser (IE/Netscape)
 Servidor: vários sabores e soluções
 Dividido em 3 camadas:
 Apresentação
 Aplicação
 Dados e armazenamento

3. 3
O que são aplicações web?
Fonte: The Open Web Applications Security Project – http://www.owasp.org

4. 4
O que são aplicações web?
 Exemplos de aplicações web:
 CNN.com, Internet Banking, Previsão do
Tempo, Google e Yahoo!, Intranets,
extranets, invente uma!
 Não confunda aplicações web com
produtos específicos (ex: Apache, IIS, JSP,
PHP, ColdFusion, Windows 2000 Server,
SQL Server, MySQL etc).

5. 5
O que são webservices?
 Softwares arquitetura aplicação/aplicação
em protocolo SOAP (XML sobre HTTP)
 Cliente: outras aplicações web
 Servidor: vários sabores e soluções
 Apenas duas camadas:
 Aplicação
 Dados e armazenamento

6. 6
Segurança de aplicações web
 Algumas afirmações paradoxais tiradas de
listas de discussão na web:
 “Não existe sistema operacional ou
aplicação insegura, existem administradores
inseguros...”
 “Os bons admistradores são bons pois
precisam lidar com aplicações e sistemas
que se parecem com queijos suíços...”
 Má notícia: ambas são verdadeiras!

7. 7
Risco, ameaça e vulnerabilidade
 Vulnerabilidade → Ameaça → Risco
 Risco:
 “A possibilidade de sofrer dano, perda”
 Ameaça:
 “Um risco eminente, provável, factível”
 Vulnerabilidade:
 “Estar suscetível a uma ameaça”

8. 8
Avaliando os Riscos
 Não existe uma métrica quantitativa exata
 Quanto a Microsoft perderia com o site
invadido?
 Quanto o “Toninho’s Armazém Online”
perderia com o site invadido?
 Conheça o negócio do cliente
 Avalie as vulnerabilidades, ameaças e
riscos inerentes

9. 9
Avaliando os Riscos
 Pergunte-se:
 As ameaças são internas (funcionários) ou externas
(visitantes)? Cuidado, o mordomo é sempre
suspeito!
 Quais são as motivações para um ataque ao
site/aplicação (pessoais, financeiras, diversão)?
 Qual será o impacto financeiro se o site/aplicação
estiver fora do ar em conseqüência destes ataques
(ex: loja virtual)?
 Qual será o impacto na imagem e reputação do
negócio como um todo?
 Você é odiado por alguém?

10. 10
Avaliando os Riscos
 Decida-se e defina:
 Quanto gastar com a proteção?
 Provedor de hospedagem de qualidade
comprovada (+ caro), arquitetura utilizada, firewall,
IDS, logs detalhados, código meticulosamente
preparado e testado (+ tempo de codificação) etc.
 Quem são os responsáveis pela proteção?
 O desenvolvedor/programador (webmaster)?
 O provedor de hospedagem?
 O cliente?

11. 11
Avaliando os Riscos
 Avaliar riscos é uma arte, consultores
abastados que o digam!
 Use o bom senso na sua avaliação
 Não gaste milhões para proteger centavos
 Uma aplicação 100% segura é 100%
impraticável
 O segredo é ser paranóico na medida
certa, comece com o seu próprio código

12. 12
Onde usar a paranóia?
 Onde uma aplicação web é mais
vulnerável?
 Camada de Apresentação
 HTML/formulários/input e output de dados de e
para o cliente. Servidores web IIS, Apache.
Browsers, pluggins, seu código
 Camada de Aplicação
 Sevidores de aplicação ASP, TomCat, IBM
WebSphere, ColdFusion, seu código
 Ambas são responsabilidades do
desenvolvedor

13. 13
Aplicações web: riscos e vulnerabilidades
“Optei por um plano de hospedagem
Linux com PHP e MySQL porque é bem
mais seguro que hospedar num plano
Windows com ASP e SQL Server...”
Historinha para boi dormir...

14. 14
Aplicações web: riscos e vulnerabilidades
“Agora posso dormir tranqüilo, meu site
está rodando atrás de um firewall muito
potente e calibrado. Atrás dele eu ainda
tenho um IDS (intrusion detection
system) de última geração, que custou
30 mil dolares...”
Cliente satisfeito é outra coisa...

15. 15
Aplicações web: riscos e vulnerabilidades
 Para quê firewall e IDS mais moderno e eficiente
do mercado? O seu site roda na porta 1589?
 Esqueça aquela “distro” Linux ultra segura e
complicada que você comprou na banca de jornal.
Não sabendo usá-la, ela será mais perigosa que o
Windows 95 como servidor de hospedagem
 “Ignore” os patches do Windows 2000 Server. Sua
aplicação vai ser mais segura só por que a
Microsoft corrigiu a rebinboca da parafuseta do
sistema de autenticação XYZ do protocolo IPXext?

16. 16
Aplicações web: riscos e vulnerabilidades
 Preocupe-se primeiro com o código de sua
aplicação. Ele é, em última instância, o que você
expõe ao público geral e também às figurinhas do
mundo underground da internet (script kiddies)
 Enquanto você perde seu tempo olhando os
fundos da casa, o ladrão está entrando pela porta
da frente (vamos chamá-la de porta 80), que ficou
aberta e desprotegida
 Um número absurdo de aplicações e sites na web
possuem algum tipo de vulnerabilidade
relacionadas à má codificação ou arquitetura ruim,
não seja o criador de um deles

17. 17
Aplicações web: riscos e vulnerabilidades
 Como vão os formulários, parâmetros URL,
queries SQL e cookies do seu site?
 Você sabia que sua base de dados pode
ser totalmente deletada ou alterada (o que
é pior), através de um simples campo de
“preencha seu nome”?
 Sabia que usuários malandros podem se
passar por usuários legítimos apenas
colocando um cookie editado no browser
deles?

18. 18
Aplicações web: riscos e vulnerabilidades
70%* das invasões de sites e aplicações web
começam ou se dão totalmente através da
má codificação das mesmas
* The Open Web Applications Security Project – http://www.owasp.org

19. 19
Aplicações web: riscos e vulnerabilidades
“Este site é 100% seguro, usamos
criptografia de 128 bits, você pode
perceber isso clicando no “cadeado
fechado” na barra de status do seu
browser...”
Onze entre dez sites de comércio eletrônico...

20. 20
Alguns exemplos
 Parâmetros inválidos | teoria
 Informações enviadas pelo usuário não
são devidamente validadas e checadas
quando recebidas e tratadas pela
aplicação/site
 Manipulação de campos de FORM
 Manipulação de cookies
 Manipulação de parâmetros URL
 Manipulação de headers HTTP

21. 21
Alguns exemplos
 Parâmetros inválidos | exemplo
 http://www.site.com.br/cesta/fecha_pedido.php?IDprodu
to=12&valor=7763 (o produto custa isso mesmo?)
 <form action=“fecha_pedido.php” method=“post”>
<input type=“hidden” name=“IDproduto” value=“12”>
<input type=“hidden” name=“valor” value=“7763”>
</form>
 Cookie: lang=pt-br; ADMIN=no; y=1 ; time=10:30GMT
Cookie: lang=pt-br; ADMIN=yes; y=1 ; time=12:30GMT
(o usuário é mesmo um administrador?)

22. 22
Alguns exemplos
 Controle de acesso falho | teoria
 Controle de acesso a uma aplicação/site
ruim e falho e pode ser burlado
 Profusão de sistemas e métodos de autenticação
facilitam muito
 Inconsistent and Past Control Checks: pastas
internas não protegidas como deveriam
 Inconsistência de credenciais/IDs inseguros
 Path traversal
 Permissão de arquivos
 Cache de browser não limpo

23. 23
Alguns exemplos
 Controle de acesso falho | exemplo
 http://www.site.com.br/admin/ (ok)
http://www.site.com.br/admin/modulox (?)
http://www.site.com.br/admin/moduloy/action.asp (?)
 http://www.site.com.br/adm/pegar_arquivo.cfm?arquiv
o=../../../winnt/system32/certmgr.reg
 http://www.site.com.br/adm/upload_arquivo.cfm?arqui
vo=iislog_safado.dll&destino=../../../winnt/system32/ine
tserv/isslog.dll

24. 24
Alguns exemplos
 Quebra de autenticação | teoria
 O usuário é capaz de burlar o sistema de
autenticação do site/aplicação
 Esqueceu a senha?
 Redefinição de senha
 Sequestro de sessão (tokens e cookies)
 Relações de confiança entre o front-end e o back-
end (banco de dados, LDAP, email etc) muito alta
comprometendo todas as outras aplicações do
servidor

25. 25
Alguns exemplos
 Quebra de autenticação | exemplo
SELECT username, senha
FROM tb_usuarios
WHERE usuario=‘$INPUT[usr]’
AND senha=‘$INPUT[pwd]’

26. 26
Alguns exemplos
 Cross-site Scripting | teoria
 Ataque que usa uma aplicação web para
atingir um outro visitante/usuário
 Stored
 Reflected
 É uma das vulnerabilidades mais
exploradas em aplicações web

27. 27
Alguns exemplos
 Cross-site Scripting | exemplo
 Campo de
comentário (stored)
 Campo “envie esta
notícia por e-mail”
(reflected)

28. 28
Alguns exemplos
 Buffer Overflows | teoria
 Depentendes do servidor de aplicação
 Difíceis de explorar, porém muito
divulgados
 Podem ser evitados ou minimizados com
o auxílio de filtragem de dados inseridos
pelo usuário

29. 29
Alguns exemplos
 Buffer Overflows | exemplo

30. 30
Alguns exemplos
 Command/SQL Injection | teoria
 Informações (parâmetros dinâmicos)
enviadas para construção de queries e
interações com o banco de dados não são
devidamente validadas e checadas
quando recebidas e tratadas pela
aplicação/site ou pelo banco de dados
 Bastante comum
 Muitos programadores a ignoram completamente
 Grande risco

31. 31
Alguns exemplos
 Command/SQL Injection | exemplo
 http://www.site.com/noticia.cfm?id=122
 <cfquery name=“qNoticias”
datasource=“bancoDeNoticias”>
SELECT * FROM noticias
WHERE id=#url.id#
</cfquery>
 http://www.site.com.br/noticias.cfm?id=122
;DROP TABLE noticias
(tem certeza de que quer deletar a tabela de notícias?)

32. 32
Alguns exemplos
 Tratamento de erros | teoria
 Informações ou operações que gerem
erros no site/aplicação não são
devidamente tratados e informados ao
usuário de forma crua e sem cuidado
 Muitos servidores de aplicação (ASP, PHP,
ColdFusion) possuem mensagens de erro
em formato debug, “informando” muita
coisa útil para quem tem más intenções
 Desabilite-as, trate os erros (try/catch)!

33. 33
Alguns exemplos
 Tratamento de erros | exemplo
 O usuário
precisa saber de
tudo isso?

34. 34
Alguns exemplos
 Erro no uso de criptografia | teoria
 Ocorre quando o webmaster/programador
não entende onde e como deve fazer uso
de criptografia (SSL, por exemplo) em
suas aplicações
 Envio de senha e informações sensíveis para só
depois criptografar a página/resultado
 Forwards estúpidos
 Acreditar que usando 128bits está “protegido”,
lembre-se de todos os outros exemplos!

35. 35
Alguns exemplos
 Erro no uso de criptografia | exemplo
 HTTP HTTP HTTPS
(login) (autenticação) (aplicação)
“Este site é 100% seguro, usamos
criptografia de 128 bits, você pode
perceber isso clicando no “cadeado
fechado” na barra de status do seu
browser...”

36. 36
Alguns exemplos
 Administração remota | teoria
 Quanto menor o número de “ferramentas”
disponíveis para uma invasão, melhor
 Não deixe o IISAdmin, ColdFusion Administrator,
MyPHPAdmin etc disponíveis nas suas posições
padrões. Proteja-os!
 Remova qualquer aplicação de exemplos ou
documentação sobre o que você têm instalado
 Limite ao máximo quem e como as interfaces de
administração remota são acessíveis (IPs
autorizados, por exemplo)

37. 37
Alguns exemplos
 Administração remota | exemplo
 Um prato cheio...
 Com 5 horas de brute-
force foi possível
invadir uma interface
de administração
remota como esta
 Estamos apenas a um
mísero “password
field” de distância de
obter controle total do
servidor e aplicações
contidas nele
 Esconda tudo que
puder!

38. 38
Alguns exemplos
 Má configuração do servidor | teoria
 Quando um servidor ou software necessário para
rodar uma aplicação é mal administrado ou mal
configurado
 IIS sem patches de correção
 Apache 1.3 em Windows (inseguro)
 Sistema Operacional “caixa preta”
 Etc!
 Responsabilidade do administrador de sistemas e do
programador em conhecer o ambiente em que
trabalha e certificar-se de que ele está devidamente
configurado para uma maior segurança

39. 39
Moral da história
 Conheça, planeje e controle os riscos de manter sua
aplicação pública (disponível na web)
 Cuide primeiro da porta de entrada, depois dos
fundos
 Ao revisar seu código, use o boné do vândalo, e
tente quebrar sua aplicação pela porta da frente
 Sempre valide toda e qualquer entrada e saída de
dados da sua aplicação (forms, url, etc)
 Use e abuse de soluções/scripts prontos
 Use a cabeça e seja malvado na hora de escrever
códigos
 Estude e participe de listas de discussão sobre o
assunto

40. 40
Perguntas e respostas

41. 41
Referência básica sobre o assunto
 The Open Web Application Security Project
 http://www.owasp.org