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