Engenharia de Software II - Teste de segurança de software

60
TESTE DE SEGURANÇA Equipe: Danilo Galvão Emanuel Pantoja Juliano Padilha Luiz Venicio Ricardo Arthur

Transcript of Engenharia de Software II - Teste de segurança de software

Page 1: Engenharia de Software  II - Teste de segurança de software

TESTE DE SEGURANÇAEquipe:• Danilo Galvão• Emanuel Pantoja• Juliano Padilha• Luiz Venicio• Ricardo Arthur

Page 2: Engenharia de Software  II - Teste de segurança de software

SUMÁRIO

Introdução Por que testes de segurança de software? O papel do testador de segurança de software Abordagens de testes de segurança de software Criando planos de testes com base na Modelagem de Ameças Padrões de Ataques Os pricipais problemas de segurança de software Demonstração Conclusão

Page 3: Engenharia de Software  II - Teste de segurança de software

INTRODUÇÃO

Os testes de segurança de software são esseciais para garantir:

• Confidencialidade;• Integridade;• Disponibilidade;• Autencidade;• Não-repúdio.

Asseguram que requisitos de segurança de software foram garantidos no desenvolvimento, mesmo quando estes requisitos não fazem parte das especificações funcionais.

Page 4: Engenharia de Software  II - Teste de segurança de software

INTRODUÇÃO

“Testes de segurança ajudam a descobrir brechas que podem causar a perda de informações importantes.”

Page 5: Engenharia de Software  II - Teste de segurança de software

INTRODUÇÃO Abordagem de Teste de Segurança

Page 6: Engenharia de Software  II - Teste de segurança de software

POR QUE TESTE DE SEGURANÇA ?

Os testes “tradicionais” buscam avaliar as funcionalidades do software.

Validar a capacidade de proteção do software contra acessos internos ou externos não autorizados.

Os testes de segurança podem ser considerado o “alicerce” para os demais testes.

Page 7: Engenharia de Software  II - Teste de segurança de software

POR QUE TESTE DE SEGURANÇA ?

Page 8: Engenharia de Software  II - Teste de segurança de software

O PAPEL DO TESTADOR DE SEGURANÇA DE SOFTWARE

Participar de todo o processo de desenvolvimento de software.

Ter capacidade técnica e conhecimento de segurança para testar software.

Atestar que o software está pronto para ser distribuído.

Page 9: Engenharia de Software  II - Teste de segurança de software

ABORDAGENS PARA TESTE DE SEGURANÇA

White Box

Black Box

Fuzzing

Page 10: Engenharia de Software  II - Teste de segurança de software

ABORDAGENS PARA TESTE DE SEGURANÇA

White Box

Teste onde o testador tem amplo conhecimento do software e acesso a código fonte.

Vantagem Permite um teste completo de todas as

características do software. Desvantagem

O teste pode ficar inviável com um número grande de linhas de código.

Page 11: Engenharia de Software  II - Teste de segurança de software

ABORDAGENS PARA TESTE DE SEGURANÇA

Black Box

Teste onde o testador tem o mesmo conhecimento e privilégios de acesso de um usuário comum.

Vantagens Pode ser executado sem acesso a “solution”

(código fonte compilável). É possível testar controles em “run-time”

Desvantagens O testador necessita de conhecimentos

avançados em segurança de software. Pode ser necessário realizar uma engenharia

reversa de software.

Page 12: Engenharia de Software  II - Teste de segurança de software

ABORDAGENS PARA TESTE DE SEGURANÇA

Page 13: Engenharia de Software  II - Teste de segurança de software

ABORDAGENS PARA TESTE DE SEGURANÇA

Fuzzing

Técnica para injeção de falhas Escalável – funciona com qualquer linguagem Versátil – Host ou Rede

Page 14: Engenharia de Software  II - Teste de segurança de software

PLANOS DE TESTES COM BASE NA MODELAGEM DE AMEAÇA

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

Page 15: Engenharia de Software  II - Teste de segurança de software

MODELAGEM DE AMEAÇA

Abordagem estruturada usada para identificar e mensurar riscos aos recursos gerenciados pelo software.

Permite que o design enderece os riscos de segurança.

Define os requisitos e recursos de segurança.

Ajuda a revisar os testes e revisões de código.

Page 16: Engenharia de Software  II - Teste de segurança de software

PROCESSO DE MODELAGEM DE AMEAÇAS

Page 17: Engenharia de Software  II - Teste de segurança de software

PROCESSO DE MODELAGEM DE AMEAÇAS

Identify Assets Identificar os bens valiosos que seu sistema deve

proteger. Create a Architecture Overview

Utilizar diagramas e tabelas simples para documentar a arquitetura de seu aplicativo, inclusive subsistemas, limites de confiança e fluxo de dados

Decompose the Application Decompor a arquitetura do aplicativo para criar um

perfil de segurança para o aplicativo. O objetivo do perfil é revelar vulnerabilidades do projeto, implementação ou configuração de implementação do aplicativo.

Page 18: Engenharia de Software  II - Teste de segurança de software

PROCESSO DE MODELAGEM DE AMEAÇAS

Identify the Threats Conhecer os objetivos de um invasor, a arquitetura e

as possíveis vulnerabilidades da aplicação, identificar as ameças que poderiam afetar a aplicação.

Document the Threats Documentar cada ameaça utilizando um modelo

comum de ameaça que defina um conjunto central de atributos a capturar para cada ameaça.

Rate the Threats Classificar as ameaças de modo a priorizar e tratar

as ameaças mais significativas primeiro. Essas ameaças apresentam riscos maiores. Considera-se a probabilidade de danos que ele

causaria.

Page 19: Engenharia de Software  II - Teste de segurança de software

PRINCIPAIS PROBLEMAS DE SEGURANÇA DE SOFTWARE

SQL Injection XSS (Cross Site Scripting) Quebra de Autenticação e Gerenciamento de Sessão Referência direta à objetos Cross-Site Request Forgery (CSRF) Falhas de Configuração Armazenamento Inseguro Falha na Restrição de Acesso à URLs Canal Inseguro Redirecionamentos Não-Validados Entre outros…

Page 20: Engenharia de Software  II - Teste de segurança de software

PRINCIPAIS PROBLEMAS DE SEGURANÇA DE SOFTWARESQL 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 os usuários inserir/tratar informações.

Ocorre por haver a falta de validação de parâmetros fornecidos por usuários.

Page 21: Engenharia de Software  II - Teste de segurança de software

PRINCIPAIS PROBLEMAS DE SEGURANÇA DE SOFTWARESQL Injection

Page 22: Engenharia de Software  II - Teste de segurança de software

PRINCIPAIS PROBLEMAS DE SEGURANÇA DE SOFTWARESQL Injection

Page 23: Engenharia de Software  II - Teste de segurança de software

PRINCIPAIS PROBLEMAS DE SEGURANÇA DE SOFTWARESQL Injection – Como Resolver

Validação sozinha não resolve!• Mesmo com as expressões regulares mais

complexas, há meios de burlá-la.

Forma recomendada! Like a Jedi.. • Interface padronizada para trabalhar com bancos de

dados, como:• PDO -> PHP• JDBC -> Java• Abstrair a complexidade e fornecer um conjunto de

padrões.

Page 24: Engenharia de Software  II - Teste de segurança de software

PRINCIPAIS PROBLEMAS DE SEGURANÇA DE SOFTWAREXSS (Cross Site Scripting)

Consiste em uma vulnerabilidade causada pelas falhas nas validações dos parâmetros de entrada do usuário e resposta do servidor na aplicação web.

Este ataque permite que scripts seja inserido de maneira arbitrária no navegador do usuário alvo.

Page 25: Engenharia de Software  II - Teste de segurança de software

PRINCIPAIS PROBLEMAS DE SEGURANÇA DE SOFTWAREXSS (Cross Site Scripting)

Page 26: Engenharia de Software  II - Teste de segurança de software

PRINCIPAIS PROBLEMAS DE SEGURANÇA DE SOFTWAREXSS (Cross Site Scripting) Qual o impacto e as principais consequências do

ataque?• Sequestro de sessão de usuários;

• Alteração do código HTML do aplicativo (visível somente do lado do cliente);

• Redirecionar o usuário para sites maliciosos;

• Alteração do objeto DOM(Modelo de Objetos do Documento) para captura de dados ou envio de malware.

Page 27: Engenharia de Software  II - Teste de segurança de software

PRINCIPAIS PROBLEMAS DE SEGURANÇA DE SOFTWAREXSS (Cross Site Scripting)

Tipos:

• Persistente

• Não-Persistente

• DOM (Document Object Model)

Page 28: Engenharia de Software  II - Teste de segurança de software

PRINCIPAIS PROBLEMAS DE SEGURANÇA DE SOFTWAREXSS (Cross Site Scripting)

Persistente

Page 29: Engenharia de Software  II - Teste de segurança de software

PRINCIPAIS PROBLEMAS DE SEGURANÇA DE SOFTWAREXSS (Cross Site Scripting)

Não-Persistente

Page 30: Engenharia de Software  II - Teste de segurança de software

PRINCIPAIS PROBLEMAS DE SEGURANÇA DE SOFTWAREXSS (Cross Site Scripting)

DOM

Page 31: Engenharia de Software  II - Teste de segurança de software

PRINCIPAIS PROBLEMAS DE SEGURANÇA DE SOFTWAREXSS (Cross Site Scripting) Como proteger-se contra ataques XSS?

• Não há meios concretos de proteger-se (usuário), pois são ataques que ocorrem devido a vulnerabilidade de aplicações web que o host está executando.

• SSL pode protegê-lo de um ataque XSS = MITO!

• Encriptação de dados não significa nada para um atacante que explora vulnerabilidades a XSS.

• Então não existe uma solução?

Page 32: Engenharia de Software  II - Teste de segurança de software

PRINCIPAIS PROBLEMAS DE SEGURANÇA DE SOFTWAREXSS (Cross Site Scripting) Como proteger-se contra ataques XSS?

• Validação de entrada

• Validação de saída

• Validação de elementos DOM

Page 33: Engenharia de Software  II - Teste de segurança de software

PRINCIPAIS PROBLEMAS DE SEGURANÇA DE SOFTWAREQuebra de Autenticação e Gerenciamento de

Sessão

Ocorre quando a falha na segurança permite que login’s, senhas ou dados de conexão (como cookies) sejam capturados por terceiros.

Page 34: Engenharia de Software  II - Teste de segurança de software

PRINCIPAIS PROBLEMAS DE SEGURANÇA DE SOFTWAREReferência direta a objetos

Ocorre quando a referência a um objeto interno fica exposta, permitindo que ela seja manipulada em função de acesso não autorizados a dados.

Page 35: Engenharia de Software  II - Teste de segurança de software

PRINCIPAIS PROBLEMAS DE SEGURANÇA DE SOFTWARE

Cross Site Request Forgery (CSRF)

É uma classe de ataques que explora a relação de

confiança entre um aplicativo web e seu usuário legítimo;

O Ataque mais comum utiliza uma tag de imagem (img src)

no documento HTML. No “src” é inserido link’s maliciosos;

A vítima acessa um site malicioso enquanto está logada no

sistema vulnerável;

O atacante “induz” a vítima a fazer tal requisição.

Page 36: Engenharia de Software  II - Teste de segurança de software

PRINCIPAIS PROBLEMAS DE SEGURANÇA DE SOFTWARE

Cross Site Request Forgery (CSRF)

Etapas de exploração em Aplicações Vulneráveis:

1. Autenticação do Usuário;

2. Acesso ao Aplicativo Malicioso;

3. Requisição à Aplicação Alvo;

4. Execução da Operação;

Page 37: Engenharia de Software  II - Teste de segurança de software

PRINCIPAIS PROBLEMAS DE SEGURANÇA DE SOFTWARE Cross Site Request Forgery (CSRF)

Page 38: Engenharia de Software  II - Teste de segurança de software

PRINCIPAIS PROBLEMAS DE SEGURANÇA DE SOFTWARE Cross Site Request Forgery (CSRF)

Exemplo;

<img src="http://bank.co/transfer.do?acct=HACKER&amount=100000" width="1" height="1" border="0">

Page 39: Engenharia de Software  II - Teste de segurança de software

PRINCIPAIS PROBLEMAS DE SEGURANÇA DE SOFTWARE Cross Site Request Forgery (CSRF)

Prevenção

• Não exibir imagens externas;

• Não clicar em links de Spam ou não confiáveis nos

e-mails, bate-papo e etc;

• Exigir um segredo, específico do token do usuário;

• Limitar o tempo de vida de cookies da sessão;

• Exigir que o cliente forneça dados de autenticação.

Page 40: Engenharia de Software  II - Teste de segurança de software

PRINCIPAIS PROBLEMAS DE SEGURANÇA DE SOFTWARE Falhas de Configuração• Aplicações Rodam em Cimas de Serviçoes que

rodam em cima de SO’s;• Todos Sistemas podem ser vetores de ataques;• Falhas Humanas;• Versões Desatualizadas.

Page 41: Engenharia de Software  II - Teste de segurança de software

PRINCIPAIS PROBLEMAS DE SEGURANÇA DE SOFTWARE Falhas de Configuração• Exemplo: 10/12/2012

Page 42: Engenharia de Software  II - Teste de segurança de software

PRINCIPAIS PROBLEMAS DE SEGURANÇA DE SOFTWARE Falhas de Configuração

Prevenção

- Realizar atividades Corretivas;

- Patches e Atualizações;

- Equipe de Testes;

- Especialista em cada Software/Aplicação.

Page 43: Engenharia de Software  II - Teste de segurança de software

PRINCIPAIS PROBLEMAS DE SEGURANÇA DE SOFTWAREProteção Insuficiente da Camada de

Transporte

• A internet pública é hostil

• Tráfego de dados pode ser capturado

• Visualização / Modificação de informações

Page 44: Engenharia de Software  II - Teste de segurança de software

PRINCIPAIS PROBLEMAS DE SEGURANÇA DE SOFTWAREProteção Insuficiente da Camada de

Transporte

• Como prevenir-se contra de falha de proteção da Camada de Transporte?

• Utilize criptografia

• Certificado Digital

• Confidencialidade e Autenticidade

• Algoritmos seguros

Page 45: Engenharia de Software  II - Teste de segurança de software

PRINCIPAIS PROBLEMAS DE SEGURANÇA DE SOFTWAREProteção Insuficiente da Camada de

Transporte

• Exemplo 1:

• Um site que não usa SSL em todas as páginas que requerem autenticação

• Um atacante pode monitorar o tráfego da rede e observar os cookies de autenticação de sessão da vítima

• O atacante pode então copiar o cookie e assumir o controle da sessão da vítima

Page 46: Engenharia de Software  II - Teste de segurança de software

PRINCIPAIS PROBLEMAS DE SEGURANÇA DE SOFTWAREProteção Insuficiente da Camada de

Transporte

• Exemplo 2:• Um site com configurações de certificado SSL

inválidas

• Usuários tem que aceitar avisos para poder usar o site, e se acostumam com eles

• Sites maliciosos exibem avisos semelhantes

• Se as vítimas estiverem acostumadas com estes avisos, elas podem entrar em sites maliciosos e fornecerem senhas ou outros dados privados

Page 47: Engenharia de Software  II - Teste de segurança de software

PRINCIPAIS PROBLEMAS DE SEGURANÇA DE SOFTWARERedirecionamentos Não-Validados

• Requisição forjada com instrução de redirecionamento

• Aplicação não valida o parâmetro e redireciona a vítima para site malicioso

Page 48: Engenharia de Software  II - Teste de segurança de software

PRINCIPAIS PROBLEMAS DE SEGURANÇA DE SOFTWARERedirecionamentos Não-Validados

• Como proteger-se de redirecionamentos não validados

• Simplesmente evite usar redirects e forwards

• Se usar, não envolva parâmetros do usuário no cálculo do destino

• Se parâmetros do usuário não puderem ser evitados, certifique-se os valores fornecidos são válidos e autorizados para o usuário

Page 49: Engenharia de Software  II - Teste de segurança de software

PRINCIPAIS PROBLEMAS DE SEGURANÇA DE SOFTWARERedirecionamentos Não-Validados

• Exemplo 1:

http://www.example.com/redirect.jsp?url=evil.com

Page 50: Engenharia de Software  II - Teste de segurança de software

PRINCIPAIS PROBLEMAS DE SEGURANÇA DE SOFTWARERedirecionamentos Não-Validados

• Exemplo 2:

http://www.example.com/boring.jsp?fwd=admin.jsp

Page 51: Engenharia de Software  II - Teste de segurança de software

PRINCIPAIS PROBLEMAS DE SEGURANÇA DE SOFTWARE Armazenamento Criptográfico Inseguro

Falhas de implementação de mecanismos de criptografia podem colocar em risco as informações armazenadas;

Um atacante pode aproveitar essa vulnerabilidade e tentar obter acesso aos conteúdos de dados sensíveis à aplicação;

Utilizar algoritmos reconhecidos; Não utilizar algoritmos fracos.

Page 52: Engenharia de Software  II - Teste de segurança de software

PRINCIPAIS PROBLEMAS DE SEGURANÇA DE SOFTWARE Falha ao Restringir Acesso à URLs

Essa falha permite que usuários não autorizados acessem páginas restritas da aplicação;

Caso um mecanismo de controle de acesso não seja implementado de forma adequada, é possível que um usuário tenha acesso a páginas ou informações que não deveriam ser permitidas;

Implementar controles de acessos, adequados a lógica de negócio e funções da aplicação;

Realizar testes de penetração.

Page 53: Engenharia de Software  II - Teste de segurança de software

PADRÕES DE ATAQUE

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

“CAPEC” - http://capec.mitre.org/

Projeto que tem como objetivo identificar e documentar padões de ataques de possam ser utilizados para testes de segurança de software.

Page 54: Engenharia de Software  II - Teste de segurança de software

PADRÕES DE ATAQUE

Page 55: Engenharia de Software  II - Teste de segurança de software

ATAQUES MAIS COMUNS

DDoS ATTACK Maneira relativamente simples de derrubar algum service.

Port Scanning Attack Técnica bastante utilizada para encontrar fraquezas

em um determinado servidor. Cavalos de Tróia, vírus e outros malwares

Normalmente desenvolvidos com o único objetivo de gerar destruição do alvo.

Ataques de Força Bruta É uma estrategia usada para quebrar a cifragem de

um dado percorrendo uma lista de possíveis chaves com um algoritmo de busca até que a chave seja encontrada

Page 56: Engenharia de Software  II - Teste de segurança de software

DEMONSTRAÇÃO

Page 57: Engenharia de Software  II - Teste de segurança de software

CONCLUSÃO

Testes de segurança irão garantir: Que o software desenvolvido terá sua garantia

de funcionalidade e não trará riscos aos seus beneficiados.

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.

Que todas as informações e expectativas de segurança do cliente serão entregues.

Page 58: Engenharia de Software  II - Teste de segurança de software

CONCLUSÃO O Que fazer com os resultados dos testes?

Identificar suas deficiências e capacitar os recursos envolvidos no desenvolvimento de software.

Identificar e desenvolver políticas com padrões que garatem o desenvolvimento de um software mais seguro.

Trabalhar e buscar a viabilização da inclusão de recursos de segurança no processo de desenvolvimento de software.

Page 59: Engenharia de Software  II - Teste de segurança de software

REFERÊNCIAS• http://codigofonte.uol.com.br/artigos/evite-sql-injection-usando-

prepared-statements-no-php• http://www.blogcmmi.com.br/engenharia/top-10-vulnerabilidades-em-

aplicativos-web-owasp• http://pt.slideshare.net/clavissecurity/principais-ameas-aplicaes-web-

como-explorlas-e-como-se-proteger• http://pt.slideshare.net/Qualister/testes-de-segurana• http://pt.slideshare.net/conviso/testes-de-segurana-de-software-

teched-2008-presentation• http://www.redesegura.com.br/2012/01/saiba-mais-sobre-o-cross-

site-scripting-xss/• http://imasters.com.br/artigo/9879/seguranca/xss-cross-site-scripting/• http://www.documentoeletronico.com.br/faqTEC010.asp• http://parul.info/fuzzing-mutation-vs-generation/• http://capec.mitre.org/index.html• http://www.devmedia.com.br/evitando-sql-injection-em-aplicacoes-

php/27804• http://www.devmedia.com.br/sql-injection-em-ambientes-web/9733

Page 60: Engenharia de Software  II - Teste de segurança de software

REFERÊNCIAS• www.redesegura.com.br%2F2012%2F03%2Fserie-ataques-os-ataques-

cross-site-request-forgery-csrf%2F&h=ZAQEJv-aw• www.pt.wikipedia.org%2Fwiki%2FCrosssite_request_forgery&h=ZAQEJv-

aw• http://www.slideplayer.com.br%2Fslide%2F391589%2F&h=ZAQEJv-aw• https://www.owasp.org/index.php/Top_10_2010-A9

Insufficient_Transport_Layer_Protection

• https://www.owasp.org/index.php/Top_10_2010-A10-Unvalidated_Redirects_and_Forwards