Seguranca web testday2012
•Descargar como PPT, PDF•
1 recomendación•684 vistas
Apresentacao de Seguranca Web para evento testday2012 by Marcio Cunha
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (17)
Similar a Seguranca web testday2012
Similar a Seguranca web testday2012 (20)
Seguranca web testday2012
- 1. Segurança de aplicações web, Conhecendo e Considerando dentro ciclo de vida do desenvolvimento do software
- 2. Geral Quando se fala em segurança, as pessoas voltam o pensamento para a infra estrutura, como antivírus, firewall e etc. É necessário também olhar para segurança dos dados, a segurança dos pacotes XML que trafegam, a segurança das aplicações, ou seja deve-se trazer uma visão mais holística de todo o cenário.
- 3. Ataques em vulnerabilidades web 2011
- 4. O Mito: Nosso site é Seguro Temos Firewalls na infra-estrutura Nós auditamos 1 vez por semestre com PenTestes Usamos Criptografia Usamos Scanners de SSL vulnerabilidade da rede
- 5. Anatomia de uma invasão de segurança Exemplo: Resultado Falha em aplicativo da Desenvolvedor de Hacker aplicativos O hacker cria solicitações Web resulta em roubo de identidade, exposição de Vendedor Inclui defeito de segurança específicas para a URL a fim de explorar a falha do dados pessoais, do varejo por falta de especialização no responsabilidade legal e que se refere à conformidade software: perante a imprensa e aos requisitos e métodos de https://w3.ibm.com/w3logi - Perda de receita Custo total relatado segurança n.html? - Impacto sobre as ações login=sam@us.ibm.com&pass - Responsabilidade da violação >US$ =“foo ' or 1=1—” perante os clientes 250 milhões - Custo de correção Origem do Problema!
- 6. Porque Aplicações web são uma alta prioridade? • Aplicações Web são o foco n º 1 de hackers: – 75% dos ataques são na camada da aplicação (Gartner®) – XSS e SQL Injection são #1 e #2 vulnerabilidades reportadas (Mitre®) • Maioria dos sites são vulneráveis: – 90% dos sites estão vulneráveis a ataques de aplicações (Watchfire®) – 78% por cento das vulnerabilidades exploráveis facilmente afetados aplicações Web (Symantec™) – 80% das organizações vai experimentar um incidente de segurança de aplicativos em 2012 (Gartner) • Aplicações web são alvos de alto valor para hackers : – Dados do usuário, Cartões de Credito, Roubo ID, fraudes, site defacement, etc
- 7. Realidade: Maioria dos ataques são Apps Web Segurança Gastos % de Ataques % de Dólares Web 10% Applications 75% 90% Network 25% Server 75% De todos os ataques a a camada de aplicação Web são direcionados para Segurança da Informação 2/3 De todas as aplicações web são vulneráveis Fontes: Gartner, Watchfire
- 8. Realidade: Maioria das aplicações web são vulneráveis Fonte: WASC 2010 Web Application Security Statistics
- 9. Analise arquitetura aplicação web em alto nível Dados App Cliente é sensitivos são deployed aqui. armazenados aqui Internet Internet Firewall Camada cliente (Browser) SSL (Apresentação) App Server Base de dados (lógica Negocio) Protege Protege Transporte Rede Camada Intermediaria Camada Dados
- 10. Como ocorre ataque aplicações web e base dados Desktop Firewall IDS/IPS Applications Databases Hacker Privileged users Cross Site Sensitive Data (DBAs,developers) Scripting Unauthorized Access Web Server DoS Parameter Known Tampering Vulnerabilities Anti- spoofing Port Scanning Pattern- Cookie Suspicious based Attack Poisoning Activity Users SQL Injection Segurança da camada frontal não para todos os vetores de ataque
- 11. E AGORA QUEM PODERA NOS DEFENDER ?????
- 13. Analista de teste (Especialista em segurança, especializado em PENTEST)
- 14. COMO?
- 15. Ferramentas scaneamento WEB O que é isso? São ferramentas para automatização usadas para executar avaliações de vulnerabilidade em aplicações Web Por que eu preciso disso? Para simplificar, encontrar e corrigir problemas de segurança da Web da aplicação. O que elas fazem? Digitaliza aplicações Web, encontra problemas de segurança e relatórios sobre eles de uma forma amigável. Quem usa? Auditores de Segurança - Os principais usuários de hoje Engenheiros de QA - Quando os auditores se tornam o “Bottle Neck” Desenvolvedores - Para encontrar as falhas o mais cedo possível.
- 16. Como trabalha Ferramenta Teste de Segurança? Faz a varredura de aplicativos da Web / sites Análise (identificação de Relatório problemas) (detalhado e acionável) WEB SCANNING
- 17. Code Scanning App Scanners Database Network Host Client-Side Custom Web Services Emerging Tech Rational AppScan Symantec Nessus Web Applications AppScan DE/BE HP WebInspect NetIQ ISS AppSec Inc Fortify Cenzic ISS QualysGuard NGS Software Ounce Labs Third-party Components NT Retina CA Objectives eEye Klockwork Foundstone Acunetix WVS Harris STAT Parasoft® Web Server Configuration Web Server Database Applications Operating System Network
- 18. Ciclo de vida desenvolvimento de software SDLC Codificação Desenvolvimento QA Segurança Produção Desenvolvedores Possibilita que os especialistas de segurança levem a correção de volta para o desenvolvimento Desenvolvedores Garante que as vulnerabilidades sejam tratadas antes de os aplicativos serem colocados em produção Desenvolvedores Fornece aos desenvolvedores e testadores o conhecimento para detecção e a capacidade de correção
- 19. OWASP TOP 10 – Falhas Segurança Web
- 20. Cross-Site Scripting – (XSS) O que é isso? Falhas XSS ocorrem sempre que uma aplicação obtém as informações não confiáveis e envia para um navegador Web sem a devida validação. O XSS permite aos atacantes executarem scripts no navegador da vítima que pode seqüestrar sessões de usuários, sites desfigurar, ou redirecionar o usuário para sites maliciosos Quais são as implicações? Tokens de sessão roubado (segurança do navegador contornado) Conteúdo da página completa comprometida Futuras páginas no navegador comprometida
- 21. Demonstração XSS Código HTML: Hacking 102: Integrating Web Application Security Testing into Development 21
- 22. Demonstração XSS Código HTML: Hacking 102: Integrating Web Application Security Testing into Development 22
- 23. XSS – O Processo Exploit Evil.org 5) Evil.org usa 1) Link para bank.com informações da sessão enviado pelo usuário via roubado para E-mail ou HTTP representar o usuário 4) Script envia cookie usuários e informações de sessão sem consentimento ou conhecimento do usuário User bank.com 2) usuário envia script incorporado como dados 3) Script/dado retornou, executou pelo browser
- 24. Injection Flaws O que é isso? Falhas na injeção, tais como SQL, sistemas operacionais e injeção LDAP, ocorrem quando os dados não confiáveis é enviado a um intérprete como parte de um comando ou consulta. Dados hostis do atacante pode enganar o intérprete para executar comandos mal intencionados ou acessar dados não autorizados Quais são as implicações? 1. SQL Injection – Acessa/modifica dados na DB 2. XPath Injection – Acessa/modifica dados Formato XML 3. SSI Injection – Executa comandos no servidor e acessa dados sensitivos 4. LDAP Injection – Ignora a autenticação (ByPass) 5. MX Injection – Usa servidor e-mail como uma maquina spam 6. HTTP Injection – Modifica ou envenena cache web 7. Etc.
- 25. SQL Injection - Exploit
- 26. SQL Injection Demonstration jsmith ’ AAAAAAAA Demo1234 SELECT true FROM users WHERE username = ‘ ’ AND password = ‘’ Hacking 102: Integrating Web Application Security Testing into Development 26
- 27. Perguntas?
- 28. Contatos: http://www.facebook.com/marcio.cunha.739 http://www.linkedin.com/profile/view?id=71356290
- 29. Obrigado
Notas del editor
- Firewalls abre as portas 80/443 para que você possa se comunicar com o servidor web, aplicação também está usando HTTP, um protocolo válido. Assim, um firewall não oferecem proteção para vulnerabilidades aplicações web tradicionais. Auditoria uma vez por trimestre é ineficaz porque ele diz, naquele dia, com os testes que foram feitos, você parece seguro. Mas como se proteger da nova vulnerabilidade descoberta no dia seguinte? E sobre patches, novos recursos, etc. Auditamos na semana seguinte? Novas aplicações implantadas? Embora este teste é valioso, ele certamente tem risco se este é o seu único método de teste. Scanners de vulnerabilidade da rede, estão focados em infra-estrutura e não navegar na aplicação e fazer uma análise profunda. SSL - Secure Sockets Layer (SSL) . conjunto com o protocolo Secure HTTP, que garante a transmissão segura de informações individuais, famoso cadeado amarelo e pela sigla “ https:// ” , mas este recurso apenas protege a confidencialidade e integridade dos dados durante uma conexão estabelecida entre um cliente e um servidor web. Pense em SSL como o envelope, mas não faz nada para impedir que algo perigoso a ser entregue para a aplicação.
- Em um típico cenário de segurança de aplicativos da Web, o usuário no lado esquerdo interage com o ambiente de servidor, à direita. Os dados que são trocados e para trás entre o usuário e o ambiente de servidor pode ser criptografada usando SSL, ou pode não ser, mas ele se move através dos firewalls, sistemas de detecção de intrusão, sistemas de prevenção de intrusão, roteadores, switches para o servidor web no outro lado. Note que é a aplicação web que facilita a troca de dados entre o ambiente do servidor e do usuário. É interessante parar e observar que, embora os dados recebidos do cliente não é confiável, a aplicação web em si é implicitamente confiável pelo ambiente de back-end e é permitido para se comunicar com tudo a partir do banco de dados para um sistema de autenticação LDAP ou para o rede básica. Vamos dar uma olhada mais de perto as proteções de rede que podem ser associados a este intercâmbio de dados.
- A primeira barreira que uma solicitação HTTP encontra ao atravessar a rede é um firewall. Firewalls são configurados para permitir que estranhos o acesso a recursos específicos, e para impedi-los de acessar outros recursos. Por exemplo, um indivíduo de fora não teria permissão para se conectar diretamente a um banco de dados, mas eles podem fazer um pedido para um servidor web. Isto significa que o firewall deve ser configurado para negar o tráfego em um banco de dados padrão porta 1443, mas permitir o tráfego através das portas 80 e 443 - portas de aplicação web. Este sistema é claramente nenhuma proteção contra ataques maliciosos. A Próxima proteção vem uma solicitação HTTP encontra é um sistema de detecção de intrusão. O IDS foi criado para procurar assinaturas no tráfego que podem indicar um ataque. Por exemplo, eles podem olhar para uma instrução SQL embutido dentro de um pedido, ou eles podem olhar para uma marca de script para indicar um ataque XSS potencial. O desafio com estes sistemas é que, se o pedido é codificada em algum formato alternativo (digamos UTF-7) ou, talvez, o tráfego é criptografada usando SSL, o sistema de detecção de intrusão muitas vezes não é capaz de interpretar ou entender os pedidos. O IDS oferece pouca ou nenhuma proteção contra o ataque de aplicações web. A proteção seguinte que uma solicitação HTTP pode encontrar é um sistema de prevenção de intrusão ou IPS. Estes sistemas são projetados para bloquear explicitamente pedidos que são considerados maliciosos. É muito semelhante ao IDS, exceto que ele tem um papel activo, em vez de um passivo. Novamente, se o tráfego é codificado ou encriptado, os sistemas não podem ser capazes de bloquear os pedidos maliciosos. O IPS oferece pouca proteção contra o ataque de aplicações web. As linhas estão a esbater, na verdade, entre os sistemas de IDS e IPS. O último sistema que a solicitação HTTP pode encontrar antes que o servidor web é, provavelmente, um firewall de aplicação. Estes são o mais inteligente de todas as proteções de rede e pode ser configurado explicitamente para permitir apenas o tráfego através certeza de que ele sabe ser bom. O problema com esses sistemas é que é muito caro manter as configurações corretas ou algoritmos válidos para reconhecer um bom tráfego. Se o firewall de aplicação web foi projetado para falhar de forma segura (uma teia princípio de segurança de aplicativos), ou seja, se você não tem certeza do que fazer, eles bloqueiam o usuário, o firewall de aplicação web pode bloquear o tráfego legítimo. Por esta razão, a maioria dos firewalls de aplicativos são normalmente projetados para quebrar um dos princípios fundadores da segurança (falha segura), permitindo que através de tráfego que eles não entendem. Há um outro problema com firewalls de aplicativos web. Eles não entendem a aplicação. Como exemplo, eles podem ser configurados para permitir um valor numérico para um valor de cookie certo, mas eles não sabem que o meu usuário só é permitido um valor de 6014, mas não 6015. Um princípio fundamental em defesa da web aplicação é que o aplicativo da Web deve defender-se. São os firewalls de aplicativos web valioso? Absolutamente! Outro desafio enfrentado por implícita a proteção de rede é que eles acelerador e diminuir o tráfego de dados. Algumas organizações são avessos a descriptografar e re-criptografar, ou implementar sistemas que têm degradação visível da experiência do usuário. Todos estes sistemas de alimentar o incidente de segurança e sistema de gestão de eventos. Você pode considerar esses dispositivos como controles operacionais ou em tempo real, de defesa contra o ataque em tempo real. Eles não são usados para encontrar vulnerabilidades, mas sim para proteger a aplicação em tempo real.
- Se o apresentador tem a capacidade, ele é muito mais poderoso para esconder este eo próximo slide e mostrar uma demonstração deste ao vivo no site de demonstração Altoro (http://demo.testfire.net) usando EVILSITE, um proxy HTTP personalizado ferramenta utilizada para demonstrar essa vulnerabilidade. O primeiro passo é identificar o furo. Digite ASDF na caixa de pesquisa. Isso se reflete de volta? Ou seja, na página de resultados, você vê ASDF é refletida de volta a partir do servidor. E se eu tentar <h1> asfd </ h1>, faz o render html? E se eu colocar no script -> Veja o próximo slide
- Neste exemplo, vamos colocar alerta <script> (document.cookie) </ script> na caixa de pesquisa e clique em enviar. A solicitação vai até o servidor, é processado e retorna uma resposta. Aviso logo que a solicitação começa renderização, lança um alerta para mostrar o cookie. Agora imagine o código correu silenciosamente e enviado a um site de terceiros, ou mudou o conteúdo na tela .. As possibilidades são infinitas. Também olhar para a url, repare que eu possa copiar e colar isso em e-mail SPAM, ou colocá-lo em um site, se um usuário clica nele, o código será executado no seu navegador. Ok, nós vimos como identificar o problema, vamos ver como você poderia explorá-lo. Nota instrutor - Não importa se é na consulta (url), pode ser dados de postagem para (campos de entrada ocultos, basicamente qualquer coisa no cabeçalho HTTP é o jogo justo)
- Palestrante Dica: Este é um exemplo de phising-Vamos dar uma olhada na cadeia de eventos durante um ataque XSS O ataque cria e envia a vítima um link para bank.com (um site confiável). O link contém uma seqüência de pesquisa (ou de qualquer outra seqüência que é ecoado de volta), que contém um código JavaScript malicioso A vítima, clica neste link, uma vez que ele / ela confia no site bank.com O bank.com aplicação web, ecoa o código JavaScript malicioso dentro da página de resposta. Esta JavaScript é executado no contexto de segurança de bank.com, uma vez que é ecoado pelo do site. Isto significa que ele tem acesso a elementos DOM pertencente a este domínio / sessão O script malicioso, envia o cookie atual e informações de sessão, sem o consentimento da vítima, para o site evil.org, onde o hacker está esperando por ele.
- Agora, o hacker tenta enviar o username: 'ou 1 = 1 - Nota: o apóstrofo é usado para fechar o contexto string em que a nossa entrada é incorporado em 1 = 1 é um verdadeiro Boolean - É usado em MS SQL comentar tudo após o sinal -, por isso não tem que se preocupar com o resto da consulta SQL Login Page : admin’-- ‘ or 1=1-- Injetar : 1/1/2010 union select userid, 'username: ' + username , 'password: ' + password,null from users --
- Se o apresentador tem a capacidade, é uma apresentação muito mais poderosa e cativante para mostrar uma falha de injeção levando ao roubo de dados ao vivo no navegador usando o site demo Altoro. Então, nesta animação, ver se eu digitar jsmith, seria injetado no parâmetro nome de usuário Agora, se eu digitar uma única citação, e em AAAAAA a senha, repare que eu recebo um erro. Mas espere um segundo, que tipo de erro é? Quando olhamos para ela, vemos que eu quebrei a sintaxe. Isso significa que eu injetado algo que quebrou o formato de um comando! O próximo passo é ver se eu possa injetar algo significativo, como um comando de meu próprio! Instrutor nota-show de login de injeção SQL, observe também vão ver isso no laboratório mais tarde .... Algumas demonstrações interessantes sobre demo.testfire.net Página de login: admin' - 'Ou 1 = 1 - Transações recentes 2010/01/01 união ID de usuário selecione, 'username:' + username, 'password:' + senha nula, de usuários-