Engenharia de Software II - Teste de segurança de software

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

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

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.

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

INTRODUÇÃO
 Abordagem de Teste de Segurança

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.

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.

ABORDAGENS PARA TESTE DE
SEGURANÇA
White Box
Black Box
Fuzzing

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.

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.

SEGURANÇA

SEGURANÇA
Fuzzing
 Técnica para injeção de falhas
 Escalável – funciona com qualquer linguagem
 Versátil – Host ou Rede

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

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.

PROCESSO DE MODELAGEM DE
AMEAÇAS

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.

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.

PRINCIPAIS PROBLEMAS DE
 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…

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 os
usuários inserir/tratar informações.
 Ocorre por haver a falta de validação de parâmetros
fornecidos por usuários.

SQL Injection

SQL 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.

XSS (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.

 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.

 Tipos:
• Persistente
• Não-Persistente
• DOM (Document Object Model)

 Persistente

 Não-Persistente

 DOM

 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?

 Como proteger-se contra ataques XSS?
• Validação de entrada
• Validação de saída
• Validação de elementos DOM

Quebra 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.

Referê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.

 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.

 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;

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

 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.

 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.

• Exemplo: 10/12/2012

 Prevenção
- Realizar atividades Corretivas;
- Patches e Atualizações;
- Equipe de Testes;
- Especialista em cada Software/Aplicação.

Proteçã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

Transporte
• Como prevenir-se contra de falha de proteção
da Camada de Transporte?
• Utilize criptografia
• Certificado Digital
• Confidencialidade e Autenticidade
• Algoritmos seguros

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

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

Redirecionamentos 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

• 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

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

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

 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.

 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.

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.

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

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.

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.

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

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

Engenharia de Software II - Teste de segurança de software

Mais conteúdo relacionado

Mais procurados

Semelhante a Engenharia de Software II - Teste de segurança de software

Mais de Juliano Padilha

Engenharia de Software II - Teste de segurança de software