Post on 17-Aug-2015
Segurança de aplicações Web
Alex Hübner, CFUG-SPalex@cfugsp.com.br
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
O que são aplicações web?
Fonte: The Open Web Applications Security Project – http://www.owasp.org
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
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
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
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
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
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
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
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
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çãoSevidores de aplicação ASP, TomCat, IBM
WebSphere, ColdFusion, seu código
Ambas são responsabilidades do desenvolvedor
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
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
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
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
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
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
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
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
Alguns exemplos
Parâmetros inválidos | exemplo http://www.site.com.br/cesta/fecha_pedido.php?
IDproduto=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:30GMTCookie: lang=pt-br; ADMIN=yes; y=1 ; time=12:30GMT(o usuário é mesmo um administrador?)
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
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?arquivo=../../../winnt/system32/certmgr.reg
http://www.site.com.br/adm/upload_arquivo.cfm?arquivo=iislog_safado.dll&destino=../../../winnt/system32/inetserv/isslog.dll
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
Alguns exemplos
Quebra de autenticação | exemplo
SELECT username, senha
FROM tb_usuarios
WHERE usuario=‘$INPUT[usr]’
AND senha=‘$INPUT[pwd]’
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
Alguns exemplos
Cross-site Scripting | exemplo
Campo de comentário (stored)
Campo “envie esta notícia por e-mail” (reflected)
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
Alguns exemplos
Buffer Overflows | exemplo
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
Alguns exemplos
Command/SQL Injection | exemplo http://www.site.com/noticia.cfm?
id=122 <cfquery name=“qNoticias”
datasource=“bancoDeNoticias”>SELECT * FROM noticiasWHERE 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
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
Alguns exemplos
Tratamento de erros | exemplo
O usuário precisa saber de tudo isso?
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
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
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
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
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
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
Perguntas e respostas
?
41
Referência básica sobre o assunto
The Open Web Application Security Project http://www.owasp.org