Aplicações Web ‐ Seu site está seguro?

363 visualizações

Publicada em

Apresentação na feira Digital Design World 2003, São Paulo Agosto 2003

Publicada em: Tecnologia
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
363
No SlideShare
0
A partir de incorporações
0
Número de incorporações
7
Ações
Compartilhamentos
0
Downloads
8
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Aplicações Web ‐ Seu site está seguro?

  1. 1. Segurança de aplicações Web Alex Hübner, CFUG-SP alex@cfugsp.com.br
  2. 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. 3 O que são aplicações web? Fonte: The Open Web Applications Security Project – http://www.owasp.org
  4. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 25 Alguns exemplos  Quebra de autenticação | exemplo SELECT username, senha FROM tb_usuarios WHERE usuario=‘$INPUT[usr]’ AND senha=‘$INPUT[pwd]’
  26. 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. 27 Alguns exemplos  Cross-site Scripting | exemplo  Campo de comentário (stored)  Campo “envie esta notícia por e-mail” (reflected)
  28. 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. 29 Alguns exemplos  Buffer Overflows | exemplo
  30. 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. 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. 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. 33 Alguns exemplos  Tratamento de erros | exemplo  O usuário precisa saber de tudo isso?
  34. 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. 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. 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. 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. 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. 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. 40 Perguntas e respostas
  41. 41. 41 Referência básica sobre o assunto  The Open Web Application Security Project  http://www.owasp.org

×