Baixado 11 vezes
Carregado porMarcio Cunha
Seguranca web Testday2012
O documento discute a importância da segurança de aplicações web ao longo do ciclo de desenvolvimento de software. Apresenta os principais vetores de ataque a aplicações web, como injeção de código e cross-site scripting. Defende a necessidade de testes de segurança desde as primeiras fases do desenvolvimento para identificar e corrigir vulnerabilidades.
Seguranca web Testday2012
- 1. Segurança de aplicaçõesweb, Conhecendo e Considerando dentro ciclo de vida do desenvolvimento do software
- 2. Quando se falaem 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. Geral
- 3. Ataques em vulnerabilidadesweb 2011
- 4. Usamos Scanners de vulnerabilidadeda rede Usamos Scanners de vulnerabilidade da rede Temos Firewalls na infra-estrutura Temos Firewalls na infra-estrutura Nós auditamos 1 vez por semestre com PenTestes Nós auditamos 1 vez por semestre com PenTestes O Mito: Nosso site é Seguro Usamos Criptografia SSL Usamos Criptografia SSL
- 5. Anatomia de umainvasão de segurança Desenvolvedor de aplicativos Inclui defeito de segurança por falta de especialização no que se refere à conformidade e aos requisitos e métodos de segurança Hacker O hacker cria solicitações específicas para a URL a fim de explorar a falha do software: https://w3.ibm.com/w3logi n.html? login=sam@us.ibm.com&pass =“foo ' or 1=1—” Resultado Falha em aplicativo da Web resulta em roubo de identidade, exposição de dados pessoais, responsabilidade legal e perante a imprensa - Perda de receita - Impacto sobre as ações - Responsabilidade perante os clientes - Custo de correção Exemplo: Custo total relatado da violação >US$ 250 milhões Vendedor do varejo Origem do Problema!
- 6. • Aplicações Websã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 Porque Aplicações web são uma alta prioridade?
- 7. Network Server Web Applications % de Ataques% de Dólares 75% 10% 25% 90% Fontes: Gartner, Watchfire Segurança Gastos De todos os ataques a Segurança da Informação são direcionados para a camada de aplicação Web 75%75% De todas as aplicações web são vulneráveis2/32/3 Realidade: Maioria dos ataques são Apps Web
- 8. Fonte: WASC 2010Web Application Security Statistics Realidade: Maioria das aplicações web são vulneráveis
- 9. (Apresentação) App Server (lógicaNegocio) Base de dados Camada cliente (Browser) Camada Intermediaria Camada Dados Firewall Dados sensitivos são armazenados aqui SSL Protege Transporte App Cliente é deployed aqui. InternetInternet Analise arquitetura aplicação web em alto nível Protege Rede
- 10. Desktop Firewall IDS/IPSApplications SQL Injection Cross Site Scripting Pattern- based Attack Web Server Known Vulnerabilities Parameter Tampering Cookie Poisoning Segurança da camada frontal não para todos os vetores de ataque Hacker Users Anti- spoofing DoS Port Scanning Privileged users (DBAs,developers) Databases Suspicious Activity Sensitive Data Unauthorized Access Como ocorre ataque aplicações web e base dados
- 11. E AGORA QUEMPODERA NOS DEFENDER ?????
- 13. Analista de teste(Especialista em segurança, especializado em PENTEST)
- 14.
- 15. Ferramentas scaneamento WEB Oque é 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. Faz a varredurade aplicativos da Web / sites Análise (identificação de problemas) Relatório (detalhado e acionável) Como trabalha Ferramenta Teste de Segurança? WEB SCANNING
- 17. NetworkNetwork Operating SystemOperating System ApplicationsApplications DatabaseDatabase WebServer Web Server Configuration Web Server Web Server Configuration Third-party ComponentsThird-party Components Web Applications Client-Side Custom Web Services Web Applications Client-Side Custom Web ServicesNetwork Nessus ISS QualysGuard eEye Retina Foundstone Host Symantec NetIQ ISS CA Harris STAT Database AppSec Inc NGS Software App Scanners Rational AppScan HP WebInspect Cenzic NT Objectives Acunetix WVS Code Scanning Emerging Tech AppScan DE/BE Fortify Ounce Labs Klockwork Parasoft® Network Operating System Applications Database Web Server Web Server Configuration Third-party Components Web Applications Client-Side Custom Web Services
- 18. Desenvolvimento Desenvolvedores SDLCSDLC Desenvolvedores Desenvolvedores Codificação QA SegurançaProdução Possibilita que os especialistas de segurança levem a correção de volta para o desenvolvimento Fornece aos desenvolvedores e testadores o conhecimento para detecção e a capacidade de correção Garante que as vulnerabilidades sejam tratadas antes de os aplicativos serem colocados em produção Ciclo de vida desenvolvimento de software
- 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. Hacking 102: IntegratingWeb Application Security Testing into Development 21 Demonstração XSS Código HTML:
- 22. Hacking 102: IntegratingWeb Application Security Testing into Development 22 Código HTML: Demonstração XSS
- 23. XSS – OProcesso Exploit Evil.org User bank.com 1) Link para bank.com enviado pelo usuário via E-mail ou HTTP 2) usuário envia script incorporado como dados 3) Script/dado retornou, executou pelo browser 4) Script envia cookie usuários e informações de sessão sem consentimento ou conhecimento do usuário 5) Evil.org usa informações da sessão roubado para representar o usuário
- 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. Hacking 102: IntegratingWeb Application Security Testing into Development 26 SQL Injection Demonstration SELECT true FROM users WHERE username = ‘ jsmith ’ AND password = ‘’ Demo1234AAAAAAAA ’
- 27.
- 28.
- 29.
Notas do Editor
- #5 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.
- #10 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.
- #11 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.
- #22 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
- #23 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)
- #24 Palestrante Dica:Este é um exemplo de phising-Vamos dar uma olhada na cadeia de eventos durante um ataque XSSO 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 maliciosoA vítima, clica neste link, uma vez que ele / ela confia no site bank.comO 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ãoO 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.
- #26 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 em1 = 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 --
- #27 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árioAgora, 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.netPágina de login:admin' -'Ou 1 = 1 -Transações recentes2010/01/01 união ID de usuário selecione, 'username:' + username, 'password:' + senha nula, de usuários-