Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Testes de Segurança de Software (tech-ed 2008)

7,552 views

Published on

Palestra proferida no Tech-Ed 2008 em São Paulo

  • Be the first to comment

Testes de Segurança de Software (tech-ed 2008)

  1. 2. Como fazer revisão e testes de código para identificar problemas (bugs) de segurança. Wagner Elias Research & Development Manager Conviso IT Security http://wagnerelias.com SEG303:
  2. 3. Agenda <ul><li>Introdução </li></ul><ul><li>Os principais problemas de segurança de software </li></ul><ul><li>Por que testes de segurança de software? </li></ul><ul><li>O papel do testador de segurança de software </li></ul><ul><li>Abordagens de testes de segurança de software </li></ul><ul><li>Criando planos de testes com base na Modelagem de Ameaças </li></ul><ul><li>Padrões de Ataques </li></ul>
  3. 4. Introdução Os testes de segurança de software são essenciais para garantir a Confidencialidade, integridade e disponibilidade das informações que serão tratadas pelo software Testes de segurança de software garantem que requisitos de segurança de software foram garantidos mesmo quando estes requisitos não fazem parte das especificações funcionais
  4. 5. Os principais problemas de segurança de Software <ul><li>Buffer Overflow </li></ul><ul><li>SQL Injection </li></ul><ul><li>XSS (Cross Site Scripting) </li></ul>
  5. 6. Buffer Overflow buffer overflow ou buffer overrun acontece quando o tamanho de um buffer ultrapassa sua capacidade máxima de armazenamento
  6. 7. Exemplo de Buffer Overflow void CopyStuff(string data) { char buffer[128]; strcpy(buffer,data); // do other stuff } Se este dado é maior do que o buffer Então esta função irá estourar o buffer
  7. 8. SQL Injection SQL injection é um tipo de ataque muito simples, baseia-se na execução de comandos SQL. Comandos de manipulação de dados - DML (select, insert, update, delete) ou comandos de definição de dados - DDL (create, drop, alter). Os comandos são injetados em campos de formulários que são disponibilizados para o usuário inserir/tratar informações
  8. 9. Exemplo de SQL Injection string Status = &quot;No&quot;; string sqlstring =&quot;&quot;; try { SqlConnection sql= new SqlConnection( @&quot;data source=localhost;&quot; + &quot;user id=sa;password=password;&quot;); sql.Open(); sqlstring=&quot;SELECT HasShipped&quot; + &quot; FROM detail WHERE ID='&quot; + Id + &quot;'&quot;; SqlCommand cmd = new SqlCommand(sqlstring,sql); if ((int)cmd.ExecuteScalar() != 0) Status = &quot;Yes&quot;; } catch (SqlException se) { Status = sqlstring + &quot; failed &quot;; foreach (SqlError e in se.Errors) { Status += e.Message + &quot; &quot;; } } catch (Exception e) { Status = e.ToString(); }
  9. 10. XSS (Cross Site Scripting) Uma falha no servidor que leva a um comprometimento do cliente. A falha é simplesmente ecoar input do usuário sem uma validação adequada.
  10. 11. Exemplo de XSS (Cross Site Scripting) Welcome.asp Hello, <%= request.querystring(‘name’)%> Mantém o badsite.com
  11. 12. Por que testes de segurança? <ul><li>Os testes “tradicionais” buscam avaliar as funcionalidades do software. </li></ul><ul><li>Testes de segurança buscam garantir: </li></ul><ul><ul><li>Não repudio </li></ul></ul><ul><ul><li>Controle de acesso adequado </li></ul></ul><ul><ul><li>Que informações não sejam “vazadas” </li></ul></ul>
  12. 13. O papel do testador de segurança? <ul><li>Participar de todo o processo de desenvolvimento de software </li></ul><ul><li>Ter capacidade técnica e conhecimento de segurança para testar software </li></ul><ul><li>Acompanhar o desenho e implementação dos controles para garantir a segurança do software </li></ul><ul><li>Atestar que o software está pronto para ser distribuído </li></ul>
  13. 14. Abordagens para teste de segurança? <ul><li>White-Box </li></ul><ul><li>Black Box </li></ul><ul><li>Fuzzing </li></ul>
  14. 15. White-Box <ul><li>Teste onde o testador tem amplo conhecimento do software e acesso a código fonte </li></ul><ul><li>Vantagens </li></ul><ul><li>Permite um teste completo de todas as características do software </li></ul><ul><li>Desvantagens </li></ul><ul><li>O teste pode ficar inviável com um número grande de linhas de código </li></ul>
  15. 16. Black Box <ul><li>Teste onde o testador tem o mesmo conhecimento e privilégios de acesso de um usuário comum. </li></ul><ul><li>Vantagens </li></ul><ul><li>Pode ser executado sem acesso a “solution” (código fonte compilavel) </li></ul><ul><li>É possível testar controles em “run-tyme” </li></ul><ul><li>Desvantagens </li></ul><ul><li>O testador necessita de conhecimentos avançados em segurança de software </li></ul><ul><li>Pode ser necessário realiazar um engenharia reversa do software </li></ul>
  16. 17. Fuzzing <ul><li>Técnica para injeção de falhas </li></ul><ul><li>Escalável – funciona com qualquer linguagem </li></ul><ul><li>Versátil – Host ou Rede </li></ul>
  17. 18. Verbo == 4 (valid) && Conteúdo > 110 bytes (Cl:Ll) Verbo Conteúdo Exemplo de Teste Fuzzing Testando a interface da porta 1433 do SQL Server Valores Válidos: 1-9 Valores Válidos: Nome da Instância (string) <ul><li>Tamanho (Cl) </li></ul><ul><ul><li>Longo (Ll) </li></ul></ul><ul><ul><li>Curto (Ls) </li></ul></ul><ul><ul><li>Zero (Lz) </li></ul></ul><ul><li>Randômico (Cr) </li></ul><ul><li>NULL (Cn) </li></ul><ul><li>Zero (Cz) </li></ul><ul><li>Tipo Errado (Cw) </li></ul><ul><li>Sinal Errado (Cs) </li></ul><ul><li>Fora dos Limites (Co) </li></ul>Estouro de Buffer
  18. 19. Criando planos de testes com base na Modelagem de Ameaças Para um teste eficaz é necessário utilizar as características que foram identificadas e documentadas na modelagem de ameaças que é realizada na fase de design do desenvolvimento de software
  19. 20. Modelagem de Ameaças <ul><li>Abordagem estruturada usada para identificar e mensurar riscos aos recursos gerenciados pelo software </li></ul><ul><ul><li>Permite que o design enderece os riscos de segurança </li></ul></ul><ul><ul><li>Define os requisitos e recursos de segurança </li></ul></ul><ul><ul><li>Ajuda a revisar os testes e revisões de código </li></ul></ul>
  20. 21. Processo de Modelagem de Ameaças (1 de 3)
  21. 22. Processo de Modelagem de Ameaças (2 de 3) 1.Identificar os bens . Identifique os bens valiosos que seus sistemas devem proteger. 2.Criar uma visão geral da arquitetura . Utilize diagramas e tabelas simples para documentar a arquitetura de seu aplicativo, inclusive subsistemas, limites de confiança e fluxo de dados. 3.Decompor o aplicativo . Decomponha a arquitetura do aplicativo, inclusive a rede subjacente e o projeto de infra–estrutura do host para criar um perfil de segurança para o aplicativo. O objetivo do perfil de segurança é revelar vulnerabilidades do projeto, implementação ou configuração de implantação do aplicativo.
  22. 23. Processo de Modelagem de Ameaças (3 de 3) 4.Identificar as ameaças . Conhecendo os objetivos de um invasor, a arquitetura e as possíveis vulnerabilidades de seu aplicativo, identifique as ameaças que poderiam afetar o aplicativo. 5.Documentar as ameaças . Documente cada ameaça utilizando um modelo comum de ameaça que defina um conjunto central de atributos a capturar para cada ameaça. 6.Classificar as ameaças . Classifique as ameaças de modo a priorizar e tratar as ameaças mais significativas primeiro. Essas ameaças apresentam riscos maiores. O processo de classificação considera a probabilidade dos danos que ela poderia causar no caso de um ataque. Pode acontecer de determinadas ameaças não justificarem nenhuma ação quando você compara o risco causado pela ameaça com os custos resultantes da atenuação.
  23. 24. Modelagem de Ameaças Wagner Elias Research & Development Manager Conviso IT Security http://wagnerelias.com demo
  24. 25. Padrões de Ataques Uma série de passos repetitivos que podem ser aplicados de uma forma consistente e confiável para simular um ataque contra um sistema de software. “ Attack Patterns – http://www.attackpatterns.org ” Projeto que, tem como objetivo identificar e documentar padrões de ataques que possam ser utilizados para testes de segurança de software
  25. 26. Padrões de Ataques Comuns <ul><li>“ By-Pass” de client </li></ul><ul><li>Modificação de arquivos de configuração </li></ul><ul><li>Alterar caminhos de busca para acessar executáveis </li></ul><ul><li>Manipular variáveis de ambiente para alterar execução de programas ou caminho de busca </li></ul><ul><li>Embutir um script dentro de outro script </li></ul><ul><li>Fuga de diretórios e pastas permitidas em site web </li></ul><ul><li>SQL ou Script Injections </li></ul><ul><li>Injetar código executável em conteúdo de banco de dados ou de arquivos </li></ul><ul><li>Manipulação de HTTP Query Strings </li></ul><ul><li>Buscar URL que aponta para arquivo local </li></ul><ul><li>Utilizar codificação alternativa de caracteres </li></ul><ul><li>Análise e envenenamento de Cookies HTTP </li></ul><ul><li>Alteração de parâmetros </li></ul>
  26. 27. Testando SQL Injection com Scrawlr Wagner Elias Research & Development Manager Conviso IT Security http://wagnerelias.com demo
  27. 28. Testando XSS com XSSDetect Wagner Elias Research & Development Manager Conviso IT Security demo
  28. 29. Testando .net com Fxcop Wagner Elias Research & Development Manager Conviso IT Security demo
  29. 30. O que fazer com o resultado dos testes? <ul><li>Identifique suas deficiências e capacite os recursos envolvidos no desenvolvimento de software </li></ul><ul><li>Identifique e desenvolva políticas com padrões que garantam o desenvolvimento de um software mais seguro </li></ul><ul><li>Trabalhe e busque a viabilização da inclusão de requisitos de segurança no processo de desenvolvimento de software </li></ul>
  30. 31. Conclusões <ul><li>Testes de segurança irão garantir que o software desenvolvido terá sua garantia de funcionalidade e não trará riscos aos seus beneficiados </li></ul><ul><li>Que o processo de resposta a incidentes após a entrega do software não será traumático devido a falhas que não foram identificadas durante o processo de desenvolvimento </li></ul><ul><li>Que todas as informações e expectativas de seguranças do cliente serão garantidas </li></ul>
  31. 32. Wagner Elias Research & Development Manager Conviso IT Security http://wagnerelias.com
  32. 33. Recursos <ul><li>www.microsoft.com/teched </li></ul><ul><ul><li>Tech·Talks Tech·Ed Bloggers </li></ul></ul><ul><ul><li>Live Simulcasts Virtual Labs </li></ul></ul><ul><li>http://www.microsoft.com/brasil/technet </li></ul><ul><ul><li>Avaliação de produtos finais e betas, conteúdo técnico em português e MUITO MAIS! </li></ul></ul><ul><li>http://www.microsoft.com/brasil/msdn </li></ul><ul><ul><li>Developer’s Kit, conteúdo técnico em português, e MUITO MAIS! </li></ul></ul>
  33. 34. Sessões Relacionadas SEG201 - Windows Server 2008 - Por que é Realmente Seguro (Análise Técnica) SEG307 - Defesa em Profundidade ? O NAP (Network Access Protection) Pode Ajudar ! SVR307 - Virtualização e Segurança: Como Conciliar os dois Mundos ? SEG308 - Estamos no Século 21: É Hora de Jogar Fora seus Gateways Medievais !
  34. 35. Outros Recursos Relacionados <ul><li>Recurso 1 </li></ul><ul><li>Recurso 2 </li></ul><ul><li>Recurso 3 </li></ul>Livro: Modelagem de Ameaças (Frank Swiderski e Window Snyder) Livro: Escrevendo Código Seguro (Michael Howard e David LeBlanc) Livro: Como Quebrar Códigos (Greg Hoglund e Gary McGraw)
  35. 36. Por favor preencha a avaliação
  36. 37. © 2008 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

×