Teste de Segurança em Aplicações Prontas

Teste de Segurança em Aplicações Prontas

Apresentação Albene Teixeira Chaves Borges Carlos Henrique de Barros Carlos Henrique Oliveira Bispo Eduardo Henrique Pontes Humberto Luis Floriano de Toledo Leonardo Santana Gunes Amorim Paulo Henrique Borges Megda

Agenda Introdução. Testes de segurança em aplicações. SFR - Security Functional Requirements. Modelo de ameaças. Testes de penetração. Tipos de testes de penetração. Conclusão. Bibliografia.

Introdução Expansão da Internet Globalização

Introdução e Motivação: Entre os principais requisitos de qualidade de software segundo Pressman [1] estão a reusabilidade, manutenabilidade, portabilidade, confiabilidade, usabilidade e interoperabilidade. Dentre estes, a reusabilidade representa uma alternativa significativa para incrementar a produtividade e a qualidade no desenvolvimento e na manutenção do software. O desenvolvimento de software com reuso é uma abordagem que tenta maximizar a reutilização de componentes de software já existentes [3], ou seja, o desenvolvimento baseado em componentes permite que uma aplicação seja construída através da reutilização de componentes de software que já foram bem especificados e testados anteriormente. Um dos principais motivos para este reuso é a diminuição dos custos durante o processo de desenvolvimento [2]. Interface: A especificação de todas as funcionalidades de um componente de software é representada através de suas interfaces. Uma interface é uma coleção de operações que são utilizadas para especificar um serviço do componente [5]. Uma interface resume como um cliente deve interagir com o componente, escondendo detalhes de implementação (idéia da caixa preta), fornecendo ao cliente todas as informações que ele precisa para utilizar o componente. Métodos get_Quanquer_Coisa() e set_Quanquer_Coisa () podem ser utilizados para ler ou modificar os dados do componente [6]. Componente como uma Caixa preta: Um componente de software pode ser considerado como uma caixa preta onde suas interações ocorrem através de sua interface. Empresa gera demandas Software gera Solução

INFORMAÇÃO = BEM DE ALTO VALOR

NECESSIDADE Informação RÁPIDA Informação CONFIÁVEL O desenvolvimento do software é baseado em componentes que já existem: o principal objetivo do sistema baseado no desenvolvimento de componentes(CBD) é a reutilização de componentes já existentes para a construção de um sistema [7,8], ou seja, componentes são partes de software que podem ser combinadas para formar um sistema maior [8]. Fornecimento de interfaces bem definidas: a única maneira de um componente interagir com outro é através de suas interfaces. A especificação do componente deve descrever explicitamente todas as interfaces que o cliente pode acessar [8]. Completa separação entre interfaces e implementação: componentes de software necessitam que a especificação das suas interfaces estejam completamente separadas da sua implementação, pois a especificação da interface, ao invés do código, define o que o componente realmente irá fazer e o que esperar do mesmo quando ele for utilizado [8]. Reutilização de especificação e projeto do componente: a reutilização de um componente não significa, apenas, a reutilização do código. É possível, também, reutilizar a especificação e o projeto do componente [3]. Projeto Baseado em Componentes versus Projeto OO: quando a construção de um software é baseada no projeto de componentes, não existe a necessidade de saber como o sistema é representado na forma de objetos ou como instâncias de uma classe. Objetos são instâncias criadas durante a execução do sistema, através da execução de um código, este código faz parte de um componente. Considerando esta diferença, um objeto não é um componente. Ele é o código interno do componente que pode ser reutilizado [8]. DESAFIO Informação SEGURA

+ Segurança = tecnologia Cuidados com aplicações

Testes de segurança em aplicações Teste sistemático de avaliação de um software - Independente da plataforma de desenvolvimento. Objetivo - Garantir que o desenvolvimento seguiu práticas de segurança. Possibilita encontrar falhas - Interface; - Código.

Erros - Comprometem a confiabilidade e segurança das aplicações. Origens - Cronogramas apertados; - Alto nível de complexidade da aplicação; - Orçamentos reduzidos. Processo de teste eficiente - Verifica adequação(software) aos requisitos de segurança (SFR); - Revisão / criação e teste do modelo de ameaças; - Testes de ataque e penetração no sistema.

SFR - Security Functional Requirements Fase de desenvolvimento -Identificação dos objetivos de segurança para atender ao nível EAL (Evaluation Assurance Level). Fase de teste - Identificação dos requisitos funcionais; - Testes dos itens; - Garantia de conformidade com EAL.

Modelo de ameaças - permite identificar e estimar ameaças à aplicação. Fase de testes - Levantado e atualizado; - Filtra; - Direciona para áreas críticas.

Testes de penetração Avaliar a segurança de uma aplicação. * Simulação de um ataque. Objetivos - Encontrar falhas técnicas; - Fragilidades; - Vulnerabilidades. Problemas + Riscos + Impactos + Solução técnica = Relatório

O modelo de testes - Testador: quem executa as atividades; - A metodologia e ferramentas: guia de testes; - Aplicação: testes de caixa preta (Black Box Testing).

Testadores - Pessoas qualificadas na área de segurança; - Hackers e crackers; - Experiência; - Conhecimento aprofundado. Metodologia e as ferramentas - Guia define um caminho mais rápido e fácil; - Guia mostra como utilizar as ferramentas de testes.

TIPOS DE TESTES DE PENETRAÇÃO

Coleta de Informações - levantar informações sobre a aplicação a ser testada; - ferramentas públicas; - scanners; - envio de requisições http. Impressão digital da aplicação - descobrir a versão e o tipo do servidor web; - direcionar testes; - analisa o cabeçalho das respostas HTTP do servidor; - "httprint".

Identificação das aplicações - identificar aplicações hospedadas em um servidor web; - explorar as vulnerabilidades; - verificar atualização; - checar configuração. Spidering e Googling(poderosas e úteis) - bem/mal; - Data Minings(tags/dados/url/link).

Código de erros - revelam informações sobre bd; - bugs. DB Listener - componente do Oracle; - trata conexões remotas dos clientes. Teste da lógica do negócio - ataques perigosos; - difíceis de detectar e especificar. Ex. Transferência de valor em dinheiro > maior que permitido.

Casos de abuso - testar os controles da aplicação; - verifica bloqueio nas operações fora do casos de abuso. Ex. Vender produto por um preço negativo. Testes de autenticação - confirmar algo como sendo autêntico. Ex. Solicitação de usuário e senha para verificação de autenticidade. Constas de usuários previsíveis - nomes de usuários e senhas fáceis; - senhas fracas com pouca ou nenhuma atualização periódica.

Força bruta - diferentes caracteres. Esquema de autenticação - burlar o processo de autenticação; - SQL injection. Acesso a diretórios - testa de acesso a diretórios e arquivos. Reset de senhas - testa esta funcionalidade do sistema. Teste de logout - encerramento de sessão após logout; - logout automático por inatividade.

Testes de gerenciamento de sessão - mantém estado desde a autenticação até o fechamento. Esquema de gerenciamento - avaliar a confiabilidade. Cookies - ganhar sessão. Variáveis de sessão - verifica exposição; - transmissão cliente servidor segura; - usa protocolos com criptografia. Validação de dados - tratamento e validação de dados.

Cross site scripting - execução de scripts indesejáveis. Métodos HTTP - métodos não seguros de acesso habilitados(PUT, DELETE, CONNECT, TRACE). SQL Injection - injeção de código SQL na entrada de dados da aplicação. Bd Oracle - acesso pelo PL/SQL ; - pontos falhos no gateway.

XML Injection - XML parser trata corretamente entradas inválidas. IMAP/SMTP Injection - comandos IMAP/SMTP nos servidores de (dados não tratados). Buffer Overflow - verificar como a aplicação trata as tentativas de buffer overflow.

Negação de serviço(DoS) - ataque comum; - indisponibiliza servidor. DDoS (Distruibuted Denial of Service) - ataque de máquinas zumbis. Bloqueio de contas válidas - bloqueio devido password inválido.

Alocação de objetos - paralisação do servidor devido alocação de grande nro de objetos. Loop por contador - loops por contador na aplicação. Estouro de logs - enchimento do disco de dados da aplicação através do envio de alto volume de dados ao servidor. Liberação de recursos - memória; - arquivos. Estouro de sessão - encher a sessão com dados e esgotar recursos de memória do servidor.

Conclusão Concluímos que o teste de segurança é uma operação essencial e indispensável para garantir que uma aplicação não possua falhas que possam permitir a uma pessoa maliciosa atacar tanto o hardware quanto o software. Também foi possível concluir que para realizar teste de alto nível é necessário planejamento, organização e, documentação de resultados e de soluções. Além disso, é extremamente necessário ter profissionais com experiência e conhecimento em segurança para que, utilizando boas ferramentas, possam realizar diversos tipos de testes em aplicações e assim pontuar níveis de segurança.

Referências Ebook: Addison.Wesley, Software.Security.Building.Security.In. (2006).BBL -testing - acesso em 25/06/2007 Ebook: OWASP Testing Guide v2 (2007) acesso em 25/06/2007

Teste de Segurança em Aplicações Prontas

Apresentações semelhantes

Apresentação em tema: "Teste de Segurança em Aplicações Prontas"— Transcrição da apresentação:

Apresentações semelhantes

Sobre projeto

Feedback

Login

Autorizar-se através da rede social:

Teste de Segurança em Aplicações Prontas

Apresentações semelhantes

Apresentação em tema: "Teste de Segurança em Aplicações Prontas"— Transcrição da apresentação:

Apresentações semelhantes

Sobre projeto

Feedback