Instituto de Ciências Exatas Departamento de Ciência da Computação Curso de Especialização em Gestão da Segurança da Informação e Comunicações

Tamanho: px
Começar a partir da página:

Download "Instituto de Ciências Exatas Departamento de Ciência da Computação Curso de Especialização em Gestão da Segurança da Informação e Comunicações"

Transcrição

1 Instituto de Ciências Exatas Departamento de Ciência da Computação Curso de Especialização em Gestão da Segurança da Informação e Comunicações TARCIZIO VIEIRA NETO Incorporando as APIs de segurança da OWASP no Demoiselle Framework Brasília 2011

2 Tarcizio Vieira Neto Incorporando as APIs de segurança da OWASP no Demoiselle Framework Brasília 2011

3 Tarcizio Vieira Neto Incorporando as APIs de segurança da OWASP no Demoiselle Framework Monografia apresentada ao Departamento de Ciência da Computação da Universidade de Brasília como requisito parcial para a obtenção do título de Especialista em Ciência da Computação: Gestão da Informação e Comunicações. Orientador: Prof. Dr. Rodrigo Bonifácio de Almeida Universidade de Brasília Instituto de Ciências Exatas Departamento de Ciência da Computação Brasília Dezembro de 2011 Segurança da

4 Desenvolvido em atendimento ao plano de trabalho do Programa de Formação de Especialistas para a Elaboração da Metodologia Brasileira de Gestão da Segurança da Informação e Comunicações - CEGSIC 2009/ Tarcizio Vieira Neto. Qualquer parte desta publicação pode ser reproduzida, desde que citada a fonte. Neto, Tarcizio Vieira Incorporando as APIs de segurança da OWASP no Demoiselle Framework / Tarcizio Vieira Neto. Brasília: O autor, p.; Ilustrado; 25 cm. Monografia (especialização) Universidade de Brasília. Instituto de Ciências Exatas. Departamento de Ciência da Computação, Inclui Bibliografia. 1. Demoiselle Framewok. 2. OWASP ESAPI. 3. OWASP AppSensor. CDU

5 Errata

6 Ata de Defesa de Monografia Monografia de Especialização Lato Sensu, defendida sob o título Incorporando a API corporativa de segurança da OWASP (ESAPI), por Tarcizio Vieira Neto, em 09 de Dezembro de 2011, no Auditório do Departamento de Ciência da Computação da UnB, em Brasília - DF, e aprovada pela banca examinadora constituída por: Prof. Dr. Rodrigo Bonifácio de Almeida UnB Orientador Profa. Dra. Genaína Nunes Rodrigues UnB Prof. Ms. André Luiz Peron Martins Lanna UnB Prof. Dr. Jorge Henrique Cabral Fernandes Coordenador do Curso de Especialização em Gestão da Segurança da Informação e Comunicações CEGSIC 2009/2011

7 Dedicatória Dedico este trabalho a minha esposa, Aline, por todo apoio que me deu durante a execução deste trabalho.

8 Agradecimentos Gostaria de agradecer primeiramente a Deus pela vida e por proporcionar-me saúde, ânimo e força, especialmente durante o tempo que estive trabalhando na conclusão deste trabalho. Não poderia deixar de agradecer também: Aos meus pais, grandes lutadores que sempre batalharam para dar o melhor possível para mim. À minha esposa, Aline, que teve paciência e compreensão durante o tempo que me dediquei a este trabalho e também durante a realização do curso, sempre me motivando a dar o melhor de mim em tudo que faço. Ao meu orientador, Prof. Dr. Rodrigo Bonifácio por ter me orientado com grande paciência na elaboração deste trabalho. Aos colegas de curso Lucélia e João Batista, que me deram apoio para continuar o curso em momentos em que estive desanimado. Ao professor Jorge Fernandes, coordenador do curso, pelas orientações e pelos esforços que empreendeu em busca da melhoria da qualidade do curso. Aos colegas Cleverson, Hendi e Victor que me auxilaram no esclarecimento de dúvidas que tive sobre o funcionamento do Demoiselle Framework e do JSF. Aos colegas de trabalho que tiveram contribuição fundamental para o meu crescimento profissional dentro do SERPRO e que me ajudaram durante a realização do curso, entre eles destaco: Marcos Allemand, Gleyner Novaes, Silvio Filho e Leandro Resende. Ao SERPRO, à UnB e ao GSI-PR pela oportunidade de realizar este curso de pós-graduação.

9 A ciência humana de maneira nenhuma nega a existência de Deus. Quando considero quantas e quão maravilhosas coisas o homem compreende, pesquisa e consegue realizar, então reconheço claramente que o espírito humano é obra de Deus, e a mais notável. Galileu Galilei ( )

10 Lista de Figuras Figura 1: Como uma vulnerabilidade de segurança gera impacto no negócio. Adaptado de (WILLIAMS e WICHERS, 2010)...25 Figura 2: Relacionamento entre os principais módulos do framework. Adaptado de LISBOA (2009)...32 Figura 3: Relacionamento das extensões com o framework. Adaptado de LISBOA (2009)...34 Figura 4: Componente Shiro no Framework. Adaptado de LISBOA (2009)...35 Figura 5: Arquitetura da Biblioteca ESAPI (WILLIAMS, 2008)...40 Figura 6: Diferença entre o uso de uma API de segurança corporativa e o modo convencional (SCHMIDT, 2010)...43 Figura 7: Integração do mecanismo de autenticação com os mecanismos de controle de acesso, log e detecção de intrusão (WILLIAMS, 2008)...44 Figura 8: Métodos do mecanismo de controle de acesso invocados nas diversas camadas da aplicação (WILLIAMS, 2008)...45 Figura 9: Integração das Exceções de Segurança com mecanismo de Log e Detecção de Intrusão (WILLIAMS, 2008)...54 Figura 10: Exemplo de atacante de SQL Injection na aplicação...57 Figura 11: SQL Injection evitado através do mecanismo de validação dos dados de entrada. Adaptado de WEB... (2008)...60

11 Figura 12: SQL Injection evitado através do mecanismo de codificação dos dados de entrada. Adaptado de WEB... (2008)...60 Figura 13: Atacante consegue persistir um script XSS nobanco de Dados da aplicação. Adaptado de WEB... (2008)...62 Figura 14: O script XSS persistido pelo atacante é renderizadona tela do usuário (alvo do ataque). Adaptado de WEB... (2008)...62 Figura 15: Script XSS refletido é renderizado na tela do usuário (alvo do ataque). Adaptado de WEB... (2008)...64 Figura 16: Ataque XSS é evitado através de um mecanismo de validação dos dados de entrada. Adaptado de WEB... (2008)...65 Figura 17: Ataque XSS persistido é evitado através da codificação dos dados renderizados na tela do usuário. Adaptado de WEB... (2008)...66 Figura 18: Ataque XSS refletido é evitado através da codificação dos parâmetros renderizados na tela do usuário. Adaptado de WEB... (2008)...67 Figura 19: Exemplo de mapa de referência...71 Figura 20: Arquitetura do AppSensor (COATES, 2009)...80 Figura 21: Combinação de diferentes filtros tratando requisições distintas (WEB..., 2008)...82 Figura 22: Correlacionamento entre Pontos de Detecção, AppSensor e Base de Usuários (COATES, 2011)...87 Figura 23: AppSensor detectando usuários maliciosos. Adaptado de COATES (2011)...89 Figura 24: Interface da aplicação OWASP ZAP...92 Figura 25: Lista de Alertas da ferramenta OWASP ZAP...93 Figura 26: Visão arquitetural do componente esapi integrado à arquitetura do Demoiselle Framework...98 Figura 27: Hierarquia de classes associadas a autenticação Figura 28: Hierarquia de classes associadas a definição do usuário no sistema...102

12 Figura 29: Hierarquia de classes associadas ao mecanismo de Figura 30: Hierarquia de classes associadas a logging...105

13 Índice de Listagens Listagem 1: Exemplo de uso da (SACRAMENTO et al., 2011)...37 Listagem 2: Exemplo de uso da Adaptado de SACRAMENTO et al. (2011)...38 Listagem 3: Exemplo de uso de restrições de segurança utilizando Expression Language (SACRAMENTO et al., 2011)...38 Listagem 4: Exemplo de uso da interface Logger (SACRAMENTO et al., 2011)...39 Listagem 5: Configuração padrão da classe ESAPI.properties...41 Listagem 6: Arquivo de configuração referenciando outras classes...42 Listagem 7: Exemplo de configuração do arquivo URLAccessRules.txt...47 Listagem 8: Exemplo de uso do método getvalidsafehtml da interface Validator (NETO, 2010)...50 Listagem 9: Exemplo de uso do método getvalidinput da interface Validator (NETO, 2010)...50 Listagem 10: Trecho de configuração do arquivo validator.properties (NETO, 2010) Listagem 11: Exemplo de uso do método encryptor() da interface Encryptor...51 Listagem 12: Resultado do processo de criptografia...51 Listagem 13: Exemplo de configuração das variáveis MasterKey e MasterSalt no arquivo ESAPI.properties...52

14 Listagem 14: Criptografia da query string utilizando o método encryptquerystring da interface HTTPUtilities (NETO, 2010)...52 Listagem 15: Resultado da operação realizada pelo metodo encryptquerystring() da interface HTTPUtilities...53 Listagem 16: Exemplo de uso do método decryptquerystring() da interface HTTPUtilities (NETO, 2010)...53 Listagem 17: Exemplo de configuração dos limiares do detector de intrusão. Adaptado de NETO (2010)...55 Listagem 18: Exemplo de forma inadequada de construir uma consulta SQL (NETO, 2010)...57 Listagem 19: Exemplo de ataque do tipo SQL Injection (NETO, 2010)...58 Listagem 20: Exemplo de consulta SQL gerada pela aplicação (NETO, 2010)...58 Listagem 21: Exemplo de renderização de dados persistidos sem prévia codificação dos dados...61 Listagem 22: Forma inadequada de renderizar uma página HTML (NETO, 2010)...63 Listagem 23: Exemplo de script XSS na URL construída pelo atacante (NETO, 2010) Listagem 24: Exemplo de execução do processo de codificação. Adaptado de NETO (2010)...64 Listagem 25: Exemplo de uso do parâmetro da query string para explorar vulnerabilidade XSS (NETO, 2010)...67 Listagem 26 Trecho de configuração que força o uso do HTTPs (RODRIGUES, 2011)...68 Listagem 27: Exemplo de URL construída pela aplicação vulnerável (NETO, 2010) Listagem 28: Exemplo de execução de consulta sem prévia verificação de controle de acesso (NETO, 2010)...70 Listagem 29: Exemplo de modificação maliciosa do parâmetro userid. Adaptado de NETO (2010)...70

15 Listagem 30: Exemplo de URL construída utilizando referência indireta...71 Listagem 31: Exemplo de modificação maliciosa realizada no parâmetro destinationaccount (NETO, 2010)...72 Listagem 32: Exemplo de código HTML contendo requisições CSRF (WILLIAMS e WICHERS, 2010)...72 Listagem 33: Exemplo de token CSRF armazenado em um campo do tipo HIDDEN. Adaptado de NETO (2010)...73 Listagem 34: Exemplo de token CSRF armazenado em um parâmetro da query string. Adaptado de NETO (2010)...73 Listagem 35: Exemplo de exploração da vulnerabilidade através da adulteração da URL (NETO, 2010)...76 Listagem 36: Exemplo de uso do mecanismo de redirecionamento para página maliciosa (NETO, 2010)...78 Listagem 37: Exemplo de ataque que utiliza o mecanismo de redirecionamento para acessar página sensível da aplicação (NETO, 2010)...79 Listagem 38: Forma de lançar os pontos de detecção (NETO, 2011)...83 Listagem 39: Padrões de detecção de ataques do tipo XSS e SQL Injection (NETO, 2011)...84 Listagem 40: Exemplo de configuração dos pontos de detecção. Adaptado de NETO (2011)...88 Listagem 41: Requisição HTTP gerada pelo ZAP Proxy...94 Listagem 42: Resumo da resposta HTTP gerada pela aplicação...94 Listagem 43: Exemplo de configuração do arquivo ResourceAccessRules.txt Listagem 44: Exemplo de configuração do arquivo ESAPI.properties associando as classes integradoras Listagem 45: Configuração do arquivo pom.xml do projeto demoiselle-esapi Listagem 46: Configuração do arquivo beans.xml do projeto demoiselle-esapi...107

16 Listagem 47: Substituição do mecanismo padrão de detecção de intrusão da ESAPI pelo mecanismo do AppSensor (NETO, 2011) Listagem 48: Exemplo de configuração do filtro MalformedRequestDetectionFilter Listagem 49: Exemplo de configuração do filtro AuthenticationFilter Listagem 50: Exemplo de configuração do filtro URLAccessControlFilter Listagem 51: Exemplo de configuração do servlet AppSensor404ErrorPage Listagem 52: Regras de validação padrão fornecidos no arquivo de configuração ESAPI.properties (NETO, 2011) Listagem 53: Exemplo de configuração do filtro SecurityFilter...115

17 Lista de Tabelas Tabela 1: Correlacionamento entre os pontos de detecção e as vulnerabilidades descritas no OWASP Top 10 (WATSON, 2011)...86 Tabela 2: Correlacionamento dos filtros e componentes com os pontos de detecção lançados...116

18 16 Sumário Errata...3 Ata de Defesa de Monografia...4 Dedicatória...5 Agradecimentos...6 Lista de Figuras...8 Índice de Listagens...11 Lista de Tabelas Sumário Resumo Abstract Delimitação do Problema Introdução Formulação da situação problema (Questões de pesquisa) Objetivos e escopo Objetivo Geral Objetivos Específicos Escopo Justificativa Hipóteses Segurança do Demoiselle Framework...27

19 Facilidade de Integração entre o Demoiselle Framework e as bibliotecas OWASP ESAPI e OWASP AppSensor Metodologia Busca de vulnerabilidades em uma aplicação exemplo Construção da extensão de segurança ESAPI Organização do Documento Revisão de Literatura e Fundamentos Demoiselle Framework Segurança no Demoiselle Framework Autenticação Autorização / Controle de Acesso Log de Eventos Biblioteca OWASP ESAPI Controle de Autenticação e Gerenciamento de Sessão Controle de Acesso Codificação dos Dados Validação dos Dados Criptografia Tratando vulnerabilidades HTTP Detector de Intrusão OWASP Top Injeção de código - (A1) Cross Site Scripting (XSS) - (A2) Falha na Autenticação e no Gerenciamento de Sessão - (A3) Referência Insegura a Objetos - (A4) Cross Site Request Forgery (CSRF) - (A5) Configuração de segurança deficiente - (A6)... 70

20 Armazenamento criptográfico inseguro - (A7) Falha ao restringir o acesso às URLs - (A8) Proteção ineficaz da camada de transporte - (A9) Redirecionamentos inseguros - (A10) Detecção e resposta a ataques com o uso do AppSensor Pontos de detecção Ações de Resposta Teste de Vulnerabilidade no Demoiselle Framework Planejamento dos testes Ferramentas utilizadas nos testes OWASP ZAP Firebug Resultados dos testes Resultados dos testes automatizados Resultados dos testes manuais Análise dos resultados dos testes Integração da ESAPI no Demoiselle Framework EsapiWrapperAuthenticator EsapiWrapperAuthorizer EsapiWrapperLogger Integração dos componentes na biblioteca ESAPI Integração do componente demoiselle-esapi no framework Integração do AppSensor no Demoiselle Framework MalformedRequestDetectionFilter AuthenticationFilter URLAccessControlFilter AppSensor404ErrorPage...107

21 SecurityFilter EncoderAppSensor Discussão Conclusões e Trabalhos Futuros Conclusões Trabalhos Futuros Referências e Fontes Consultadas Apêndice A Pontos de Detecção

22 20 Resumo Desenvolver aplicações web com um nível de segurança adequado tem se tornado uma tarefa cada vez mais difícil, pois, além do conhecimento sobre as vulnerabilidades de segurança que devem ser conhecidas e evitadas, o desenvolvedor precisa ter acesso a ferramentas que auxiliam na construção de controles de segurança que sejam bem implementados, fáceis de serem utilizados e eficazes na redução dos riscos de segurança. Apesar do aumento significativo no número de frameworks disponíveis para auxiliar no desenvolvimento de aplicações web, muitos destes não foram concebidos com o foco em segurança, ou atendem apenas a um subconjunto de requisitos de segurança. Este trabalho busca analisar os aspectos de segurança do Demoiselle Framework e Integrar as bibliotecas OWASP ESAPI e OWASP AppSensor para permitir o uso dos controles de segurança complementares aos que estão previstos no framework. Como resultado deste trabalho, apresentamos os principais aspectos técnicos destas bibliotecas, alguns princípios empregados no controle de detecção e resposta a ataques e disponibilizamos os componentes desenvolvidos e que integram as bibliotecas de segurança ESAPI e AppSensor no Demoiselle Framewok.

23 21 Abstract Developing web applications with an appropriate level of security has become an increasingly difficult task because, besides the knowledge about security vulnerabilities that must be known and avoided, the developer must have access to tools that assist in building security controls that are well implemented, easy to use and effective in reducing security risks. Despite the significant increase in the number of frameworks available to assist in the development of web applications, many of these were not designed with a focus on safety, or serve only a subset of security requirements. This project analyzes the security aspects of the Demoiselle Framework and integrates the library OWASP ESAPI and OWASP AppSensor to allow the use of security controls to complement those security controls that are implemented in the framework. As a result of this work, we present the main technical aspects of these libraries, some principles used for detect and respond to attacks and provide components for integrate ESAPI and AppSensor libraries in Demoiselle Framewok.

24 22 1 Delimitação do Problema 1.1 Introdução Construir software com um nível adequado de segurança tem se tornado uma tarefa cada vez mais difícil devido ao tamanho, complexidade e ritmo de crescimento na demanda de desenvolvimento de novas aplicações, bem como devido ao crescimento do número e nível de habilidade dos usuários mal intencionados que possuem o potencial de encontrar e explorar alguma vulnerabilidade na aplicação. Atualmente as aplicações são responsáveis pela execução de operações críticas para atender necessidades individuais e corporativas, alcançando organizações públicas e privadas em todo o mundo, fazendo com que as aplicações web tenham que lidar com enorme quantidade de dados sensíveis, como dados financeiros, cartões de crédito, dados médicos, etc. Apesar do papel fundamental que estas desempenham, as defesas de segurança costumam ser deficientes. Contudo, os aspectos de segurança são extremamente relevantes quando se trata desse tipo de tecnologia, pois, a maior parte das vulnerabilidades são causadas por erros comuns no desenvolvimento e podem ameaçar significativamente a segurança da aplicação e do negócio como um todo (KUNST e RIBEIRO, 2004). Os atacantes podem explorar diversas vulnerabilidades para afetar negativamente um negócio, podendo causar uma série de impactos, entre os quais podemos citar: Perdas financeiras; Perda da integridade dos dados; Perda da confidencialidade dos dados; Perda da disponibilidade da aplicação;

25 23 Perda da confiança e lealdade dos clientes associados aos danos à imagem institucional. Acerca das vulnerabilidades em aplicações, (SANS, 2009) relata o seguinte fato: Nos últimos anos, a quantidade de vulnerabilidades descobertas em aplicações é muito maior que as descobertas em sistemas operacionais. Proteger os recursos críticos das aplicações tem se tornado uma tarefa cada vez mais importante, pois, o foco dos ataques tem migrado para a camada de aplicação. Segundo um estudo do instituto SANS (acrônimo de SysAdmin, Audit, Networking, Security), os ataques contra aplicações web constituem mais de 60% do total das tentativas de ataque observados na Internet (SANS, 2009). Atualmente existem mais de formas conhecidas de ataques que são baseados em vulnerabilidades típicas em aplicações web que se concentram em requisições HTTP e HTTPs direcionadas para as portas públicas (80 e 443) que não podem ser bloqueadas pelos firewalls comuns, pois, caso fossem, os usuários não conseguiriam acessar os recursos de uma aplicação web (PINHEIRO, 2009). A solução é projetar e integrar um sistema de detecção e resposta a ataques na camada de aplicação. Desta forma, dentro da aplicação é possível ter uma completa compreensão da ação iniciada pelo usuário, o alvo dessa ação e os meios de verificar se uma ação pode ser permitida ou não para determinado usuário. Portanto, dentro da aplicação, o sistema de proteção pode identificar ataques avançados que estão tentando explorar características específicas da aplicação. A OWASP (Open Web Application Security Project) desenvolveu os projetos ESAPI (Enterprise Security API) e AppSensor, que são projetos de código aberto, desenvolvidos pela comunidade OWASP. A ESAPI contém um conjunto de funções úteis que auxiliam na implementação de controles de segurança com o propósito de evitar as vulnerabilidades de segurança comumente encontradas em aplicações web (NETO, 2010).

26 24 O AppSensor define um framework conceitual que auxilia na detecção de atividades maliciosas, com o propósito de evitar que um usuário malicioso identifique e explore uma vulnerabilidade na aplicação (COATES, 2009). Segundo BIRD (2011), além da ESAPI existe diversas outras bibliotecas de segurança, como é o caso do Apache Shiro 1, que atende as principais funções de segurança (autenticação, autorização, gerenciamento de sessão e criptografia), porém não trata de funções importantes, presentes na biblioteca ESAPI, como validação de dados de entrada e codificação dos dados de saída. Estas funções serão explicadas em maiores detalhes nas próximas seções. 1.2 Formulação da situação problema (Questões de pesquisa) A OWASP publica periodicamente o documento, chamado Top 10, que faz um levantamento das 10 vulnerabilidades que mais ocorrem em aplicações web. Para cada uma delas, o documento mostra como ocorrem e como evitá-las. Este documento teve sua primeira versão lançada em 2004 e é atualizado periodicamente a cada 3 anos, sendo a última versão do documento lançada em Acerca dos riscos de segurança em aplicações, o OWASP Top 10 (WILLIAMS e WICHERS, 2010), apresenta os seguintes fatos: 1. Os atacantes podem usar diversos caminhos através da aplicação que potencialmente podem prejudicar o negócio ou a organização. 2. Cada um desses caminhos representa um risco que pode ser prejudicial o suficiente para justificar a sua atenção. A Figura 1 ilustra como uma vulnerabilidade pode ser explorada por um atacante para acessar algum ativo crítico que gera algum impacto no negócio. 1

27 25 Figura 1: Como uma vulnerabilidade de segurança gera impacto no negócio. Adaptado de (WILLIAMS e WICHERS, 2010). O objetivo da segurança em aplicações é manter a confidencialidade, integridade e disponibilidade dos recursos de informação, com o propósito de permitir que as operações de negócios sejam bem sucedidas (GOMES et. al, 2010). Esse objetivo é alcançado através da implementação de controles de segurança na aplicação. Muitas vezes, estes controles não estão integrados aos frameworks de desenvolvimento, como o Demoiselle Framework, que possui o potencial de tornarse um framework de referência para o desenvolvimento de aplicações web, por ser independente de tecnologia e promover a integração de diferentes tecnologias nas diversas camadas da aplicação. Portanto, faz-se necessário responder às seguintes questões de pesquisa: Quais das principais vulnerabilidades de segurança conhecidas as aplicações desenvolvidas utilizando o Demoiselle Framework estão sujeitas? Quais as formas de tratar estas vulnerabilidades com o uso da biblioteca de segurança OWASP ESAPI e OWASP AppSensor? 1.3 Objetivos e escopo Objetivo Geral O objetivo deste trabalho é aprimorar os controles de segurança do Demoiselle Framework através do desenvolvimento de uma extensão que permita

28 26 integrar as bibliotecas OWASP ESAPI e OWASP AppSensor no framework, com o propósito de reduzir a complexidade do uso destes componentes e facilitar a integração e definição de controles de segurança nas aplicações desenvolvidas utilizando o Demoiselle Framework Objetivos Específicos Esse trabalho contempla os seguintes objetivos específicos: 1. Investigar as vulnerabilidades, baseado no OWASP Top 10, que o Demoiselle Framework está sujeito. 2. Elencar os controles de segurança básicos da biblioteca ESAPI. 3. Implementar uma extensão que integra as bibliotecas OWASP ESAPI e OWASP AppSensor no Demoiselle Framework. 4. Apresentar os benefícios do uso das bibliotecas OWASP ESAPI e OWASP AppSensor no Demoiselle Framework Escopo O escopo desse trabalho se restringe a uma investigação das potenciais vulnerabilidades do Demoiselle Framework, considerando as 10 principais vulnerabilidades de aplicações Web discutidas no OWASP TOP 10. Foram integrados ao Demoiselle Framework apenas os recursos de autenticação, controle de acessos e filtros de validação dos dados de entrada da biblioteca OWASP ESAPI. Além disso, um mecanismo de monitoramento e resposta a eventos maliciosos, relacionados à validação de dados de entrada, foi implementado utilizando o OWASP AppSensor. 1.4 Justificativa Esse projeto se justifica pela importância de compreender as vulnerabilidades mais comuns presentes em aplicações web e apresentar propostas de integração

29 27 dos controles de segurança da biblioteca OWASP ESAPI e detecção de resposta a ataques utilizando a biblioteca OWASP AppSensor no Demoiselle Framework. Outra importância deste projeto é o enfoque arquitetural de segurança, onde, além do uso das bibliotecas, serão abordadas as boas práticas de segurança no desenvolvimento de aplicações web, principalmente no que se refere às práticas utilizadas para desenvolver aplicações web seguras utilizando os controles de segurança fornecidos pela biblioteca ESAPI. 1.5 Hipóteses Segurança do Demoiselle Framework O Demoiselle Framework não oferece recursos que possibilitam tornar as aplicações robustas em relação às principais vulnerabilidades apresentadas no OWASP TOP Facilidade de Integração entre o Demoiselle Framework e as bibliotecas OWASP ESAPI e OWASP AppSensor Devido aos recursos de extensão presentes no Demoiselle Framework e nas bibliotecas OWASP ESAPI e OWASP AppSensor, é viável a integração de mecanismos mais abrangentes de segurança no Demoiselle Framework Metodologia Essa pesquisa do tipo Estudo de Caso visa, a partir de uma análise dos detalhes técnicos e arquiteturais do Demoiselle Framework e da biblioteca ESAPI, promover a integração dos controles de segurança providos pela biblioteca ESAPI no Demoiselle Framework a partir do desenvolvimento de um componente que poderá ser acoplado ao framework.

30 Busca de vulnerabilidades em uma aplicação exemplo Para testar a hipótese (Segurança no Demoiselle Framework) foi utilizado uma aplicação de exemplo, neste caso a ContactList que é uma aplicação construída pela equipe de desenvolvimento do Demoiselle Framework e tem o propósito de apresentar as principais funcionalidades e facilidades do Demoiselle Framework, versão 2.0. A aplicação consiste em um repositório de lista de contatos que possui usuários com dois perfis: administrador cria, edita e remove contatos. guest - visualiza os contatos cadastrados Construção da extensão de segurança ESAPI Com o intuito de testar a hipótese 1.5.2, foi implementado um componente do Demoiselle Framework, com o propósito de realizar a integração da biblioteca ESAPI e da biblioteca AppSensor no framework. O processo de construção do componente visa projetar e implementar classes que deverão facilitar o uso das bibliotecas de segurança da ESAPI no framework, implementando alguns controles de segurança na forma de filtros, com o propósito de implementar os principais pontos de detecção discutidos na seção Os requisitos básicos previstos a serem cumpridos para implementar o que pode ser considerado uma versão básica de um componente que incorpora a biblioteca ESAPI no Demoiselle são: Mecanismo de integração dos componentes de Autenticação. Mecanismo de integração dos componentes de Autorização. Mecanismo de integração dos componentes de Log. Filtros de segurança.

31 Organização do Documento O próximo capítulo apresenta uma revisão da literatura que objetiva apresentar os principais conceitos necessários à compreensão do restante da monografia. O Capítulo 3 apresenta o resultado dos testes de segurança executados em uma aplicação desenvolvida utilizando o Demoiselle Framework. O Capítulo 4 apresenta as classes que provêm a integração dos mecanismos de autenticação e controle de acesso da biblioteca ESAPI no Demoiselle Framework. O Capítulo 5 apresenta as classes responsáveis por gerar eventos de segurança, conhecidos como pontos de detecção, baseados no comportamento do usuário, que são monitorados pelo AppSensor para gerar uma resposta aos eventos. O Capítulo 6 apresenta uma breve discussão acerca do resultado dos testes e das classes implementadas para realizar a integração das bibliotecas de segurança. Finalmente, no Capítulo 7 é apresentado a conclusão do trabalho e os trabalhos futuros.

32 30 2 Revisão de Literatura e Fundamentos 2.1 Demoiselle Framework A necessidade de construir software de forma ágil e com qualidade faz com que o processo de desenvolvimento de software seja apoiado pelo reuso de estruturas pré-existentes, como os frameworks. Um framework é um conjunto de classes que colaboram para realizar uma responsabilidade para um domínio de um subsistema da aplicação (FAYAD, 1997) e, de acordo com LISBOA (2010):...um framework define parâmetros de projeto; a forma como é realizada a divisão em classes e objetos e suas responsabilidades; a maneira como colaboram entre si, e o fluxo de controle, ditando, assim, a arquitetura de software das aplicações que os utilizam. Do ponto de vista da segurança de software, os frameworks podem auxiliar o desenvolvedor no sentido de fornecer serviços de segurança, como: 1. Autenticação/Autorização 2. Validação/Codificação de dados 3. Tratamento de erros 4. Logs 5. Detecção de intrusão 6. Criptografia

33 31 O Demoiselle Framework é uma integração de várias tecnologias de desenvolvimento de software para tecnologia Java e também consiste em uma arquitetura de referência para o desenvolvimento de aplicações (LISBOA, 2010). Ainda segundo LISBOA (2010), podemos destacar algumas características importantes das aplicações construídas utilizando o Demoiselle Framework: As camadas são independentes, porque referências a objetos são obtidas indiretamente por meio de injeção de dependências2 (FOWLER, 2004). Independência da interface gráfica e do gerenciador do banco de dados. Com o uso do Demoiselle Framework é possível obter diversas vantagens, como reuso de componentes e independência de fornecedores (LISBOA, 2010). A Figura 2 mostra os principais módulos do framework. Figura 2: Relacionamento entre os principais módulos do framework. Adaptado de LISBOA (2009). A técnica de injeção de dependência permite reduzir o acoplamento entre as camadas da aplicação, fazendo com que determinada camada apenas tenha conhecimento sobre as funcionalidades (interfaces) disponibilizadas por outra camada, sem a necessidade de conhecer como foi implementada, garantido que seja possível modificar o comportamento (implementação) de uma camada sem que a camada cliente sofra alterações. A técnica de Injeção de dependência tem como responsabilidade instanciar as classes concretas para prover a comunicação entre as camadas (XIMENES, 2009). 2

34 32 A seguir, uma breve descrição dos módulos apresentados na Figura 2 (LISBOA, 2009): Core Este módulo contém funcionalidades comuns a todas as extensões e componentes. O core é simples e é formado majoritariamente por interfaces e poucas implementações. Web Este módulo contém implementações de algumas especificações do módulo lógico core e também utilitários comuns de aplicações web que facilitam tratamento de sessões de usuário e suas requisições. Persistence O objetivo deste módulo é criar abstrações de persistência visando o baixo acoplamento nas camadas superiores. View Este módulo contém implementações de componentes específicos de interface com usuário. Transaction - Especificação de mecanismo de controle transacional. Define um contexto transacional que atua no início e fim de cada ação executada pelos artefatos de cada camada. Util Este módulo contém componentes utilitários que facilitam o trabalho de outras funcionalidades do framework e seus módulos lógicos. O framework está dividido em dois módulos principais, o primeiro é o framework arquitetural (core, util, web, persistence e view) e o segundo é um conjunto de extensões e componentes (LISBOA, 2009). As extensões e os componentes complementam o core com funcionalidades extras e bem específicas a um domínio ou tecnologia. A diferença entre extensão e componente é apenas conceitual. As extensões geralmente modificam o funcionamento de determinados módulos do Demoiselle, alteram o comportamento padrão e são baseadas em especificações J2EE. Deste modo, caso a aplicação necessite realizar persistência com JPA (Java Persistence API), o framework fornece a extensão demoiselle-jpa que facilita a integração com essa tecnologia. De modo semelhante, temos a integração com o JSF (Java Server Faces), através da extensão demoiselle-jsf e a integração com o JTA (Java Transaction API), através da extensão demoiselle-jta.

35 33 As extensões não são autônomas, pois estão diretamente ligadas ao núcleo do framework, fazendo com que o ciclo de vida das extensões esteja totalmente dependente com o do core (SACRAMENTO et al., 2011). A Figura 3 mostra o relacionamento das extensões jsf, jpa, jta e jaas com os módulos view, persistence, transaction e security. Figura 3: Relacionamento das extensões com o framework. Adaptado de LISBOA (2009). Os componentes funcionam como acessórios que podem ser incorporados e reutilizadas pelos desenvolvedores e geralmente fazem uso de outras bibliotecas. O objetivo de criar componentes é disponibilizar novas funcionalidades que sejam úteis aos desenvolvedores, onde estes componentes podem ter seu ciclo de vida independente das demais camadas do framework (LISBOA, 2010).

36 34 A Figura 4 mostra a integração da biblioteca de segurança Apache Shiro no Framework Demoiselle, implementada através do componente demoiselle-shiro. Figura 4: Componente Shiro no Framework. Adaptado de LISBOA (2009). Neste caso, o componente demoiselle-shiro implementa as interfaces de segurança Authenticator e Authorizator do Demoiselle com o propósito de integrar a biblioteca Apache Shiro no framework. Como exemplo de componentes, temos também o demoisell e o demoiselle-report que, respectivamente, auxiliam no envio e recebimento de s e geração de relatórios 2.2 Segurança no Demoiselle Framework A implementação de segurança do Demoiselle foi projetada de forma simples e flexível, independente de camada de apresentação ou tecnologia, deixando o desenvolvedor livre para implementar a própria solução ou utilizar extensões ou componentes prontos, como é o caso do componente demoiselle-shiro, baseada no Apache Shiro (SACRAMENTO et al., 2011).

37 35 O framework especifica uma forma padrão de acesso aos dados de segurança referente a autenticação e autorização através de papeis. Cada implementação desta especificação deverá prover uma solução de acesso ao contexto (LISBOA, 2009). Ainda segundo LISBOA (2009), a funcionalidade de autenticação agrupa elementos para promover a extensibilidade da solução, possibilitando definir estratégias. Neste caso, o core é quem define o orquestrador do mecanismo, os pontos de extensão e lança eventos relacionados com o processo de autenticação Autenticação O mecanismo de autenticação busca verificar a identidade do usuário do sistema. A forma mais comum de executar essa verificação se dá por meio de um formulário de login, geralmente solicitando um nome de usuário e senha cadastrados. Os detalhes da autenticação devem ser realizados através de uma classe que implementa a interface Authenticator (br.gov.frameworkdemoiselle.security.authenticator), que contém os seguintes métodos (SACRAMENTO et al., 2011): authenticate() - é responsável por executar os passos necessários para validar a identidade de um usuário. unauthenticate() - é responsável por fazer o processo de logout da conta do usuário. getuser() - é responsável por retornar a instância do usuário autenticado Autorização / Controle de Acesso O mecanismo de autorização é responsável por garantir que apenas usuários autorizados tenham acesso a determinados recursos de um sistema (SACRAMENTO et al., 2011). Neste caso, o controle de acesso foi implementado visando a conformidade com o padrão RBAC (Role Based Access Control Controle de Acesso Baseado em Papéis). No modelo de segurança do Demoiselle 2.0, a restrição do acesso a um determinado recurso/operação pode ser vinculado através das seguintes anotações:

38 36 Para executar o processo de verificação, o mecanismo de controle de acesso deve implementar a interface Authorizator (br.gov.frameworkdemoiselle.security.authorizator), Esta interface contém os seguintes métodos (SACRAMENTO et al., 2011): haspermission(object resource, String operation) - verifica se o usuário autenticado possui permissão para executar uma operação sobre um recurso. hasrole(string role) - verifica se o usuário autenticado está associado a um papel específico. A implementação padrão da interface SecurityContext (br.gov.frameworkdemoiselle.security.securitycontext) realiza a vinculação das com os métodos haspermission() e hasrole() da implementação da interface Authorizator. A pode ser utilizada tanto em classes como em métodos e possui dois parâmetros opcionais: operation e resource. O primeiro define a operação para a qual se deseja permissão e o segundo define em qual recurso essa operação será realizada. A Listagem 1 mostra as formas de utilização da anotação RequiredPermission: class ClasseExemplo public void requiredpermissionwithoutdeclaredresourceandoperation() { = "contact", operation = "insert") public void requiredpermissionwithdeclaredresourceandoperation() { } } Listagem 1: Exemplo de uso da (SACRAMENTO et al., 2011). No método cuja anotação não possui parâmetros serão considerados como recurso e operação, respectivamente, o nome da classe e o nome do método. Uma

39 37 alternativa seria utilizar a tanto na classe como no método para indicar respectivamente o recurso e a operação (SACRAMENTO et al., 2011). A possui um parâmetro obrigatório, no qual pode ser definido um papel (role) ou um conjunto de papéis, ex: class ClasseExemplo public void requiredrolewithsinglerole() { "rolea", " roleb", " rolec", " roled", " rolee" }) public void requiredrolewitharrayofroles() { } } Listagem 2: Exemplo de uso da Adaptado de SACRAMENTO et al. (2011). As restrições de segurança podem ser utilizadas em páginas web com o auxílio de EL (Expression Language), como mostrado na Listagem 3. <p:commandbutton value="#{messages['button.save']}" action="#{contacteditmb.insert}" rendered="#{!contacteditmb.updatemode}" ajax="false" disabled="#{!securitycontext.haspermission('contact', 'insert')}" /> Listagem 3: Exemplo de uso de restrições de segurança utilizando Expression Language (SACRAMENTO et al., 2011). Nesse caso, a habilitação de um botão está condicionada à existência de permissão para o usuário autenticado executar a operação insert no recurso contact. Conforme o que será abordado nas seções e 2.4.8, ocultar ou desabilitar um botão não é suficiente para evitar ataques que visam explorar falhas nos mecanismos de controle de acesso da aplicação, fazendo com que um atacante faça uma requisição forjada para a aplicação, seja habilitando o botão através de plugins no navegador que permite alterar as propriedades dos componentes exibidos na página, seja através de ferramentas que geram requisições forjadas

40 38 para a aplicação, semelhante à requisição gerada ao pressionar o botão (caso estivesse habilitado) Log de Eventos Uma API de logging é um recurso interessante para informar o usuário e o desenvolvedor sobre os erros, alertas, resultados de operações, os recursos acessados e outras informações importantes do sistema. O Demoiselle Framework possui (a partir da versão 2.1) uma fábrica de log presente no core e isso visa permitir a incorporação desse recurso, através da técnica de injeção de dependências, baseado na interface Logger ( org.slf4j.logger), conforme exemplo de código a seguir: public class MinhaClasse private Logger logger; public void meumetodo() { logger.debug("logando meu metodo"); logger.warn("mensagem de alerta do meu metodo"); } } Listagem 4: Exemplo de uso da interface Logger (SACRAMENTO et al., 2011) Biblioteca OWASP ESAPI Segundo NETO (2010), a OWASP é uma iniciativa aberta para tratar aspectos de segurança de aplicações web que trabalha para criar artigos, metodologias, documentação, ferramentas e tecnologias para a segurança das aplicações web. A ESAPI agrega um conjunto de implementações de referência que são projetadas para funcionar sem necessidade de qualquer outra infraestrutura, como banco de dados, servidor LDAP (Lightweight Directory Access Protocol), etc. No entanto, é possível integrar as tecnologias de backend que a aplicação depende com os módulos de segurança através da implementação de novas classes que substituem as classes padrão oferecidas pela biblioteca.

41 39 A Figura 5 apresenta a arquitetura da ESAPI, distribuída em módulos que podem ser utilizados isoladamente, conforme o interesse e necessidade do desenvolvedor. Figura 5: Arquitetura da Biblioteca ESAPI (WILLIAMS, 2008) Alguns destes módulos interagem com outros módulos visando a integração entre os controles de segurança e o reuso de funcionalidades. A biblioteca está dividida em diversas interfaces com funções coesas extremamente especializadas. Assim, temos a seguinte descrição das principais interfaces (NETO, 2011): AccessController realiza o controle de acessos dos usuários aos recursos (url, dados, funções). Authenticator realiza a autenticação do usuário e o gerenciamento da sessão. Encoder provê funções de codificação de entrada e saída de dados. Validator provê funções de validação dos dados de entrada. Encryptor provê funcionalidades de criptografia/decriptografia de dados e funções de hash. HTTPUtilities provê funções úteis para tratar questões de segurança que envolvem o protocolo HTTP

42 40 IntrusionDetector realiza a detecção de intrusão através da análise de comportamento. Logger realiza o registro dos eventos comuns e dos eventos de segurança. Randomizer módulo responsável pela geração de valores aleatórios. A biblioteca ESAPI oferece controles de segurança complementares, não implementados no Demoiselle Framework. Caso seja necessário substituir alguma implementação padrão da ESAPI por uma nova implementação, basta modificar a referência da classe presente no arquivo de configuração ESAPI.properties 3, substituindo a referência padrão pela referência à nova implementação. A Listagem 5 mostra o trecho original do arquivo de configuração da ESAPI (ESAPI.properties), referenciando classes que implementam o comportamento padrão da biblioteca: (...) ESAPI.AccessControl=org.owasp.esapi.reference.DefaultAccessController ESAPI.Authenticator=org.owasp.esapi.reference.FileBasedAuthenticator ESAPI.Encoder=org.owasp.esapi.reference.DefaultEncoder ESAPI.Encryptor=org.owasp.esapi.reference.JavaEncryptor ESAPI.CipherText=org.owasp.esapi.reference.DefaultCipherText ESAPI.PreferredJCEProvider=SunJCE ESAPI.Executor=org.owasp.esapi.reference.DefaultExecutor ESAPI.HTTPUtilities=org.owasp.esapi.reference.DefaultHTTPUtilities ESAPI.IntrusionDetector=org.owasp.esapi.reference.DefaultIntrusionDetector ESAPI.Logger=org.owasp.esapi.reference.Log4JLogFactory ESAPI.Randomizer=org.owasp.esapi.reference.DefaultRandomizer ESAPI.Validator=org.owasp.esapi.reference.DefaultValidator (...) Listagem 5: Configuração padrão da classe ESAPI.properties. A Listagem 6 mostra o trecho de configuração que ilustra como se faz para modificar a referência das classes fornecidas por padrão, substituindo-as por referências a classes que contenham um modo particular de implementar as funções de controle de acesso, autenticação e log: (...) ESAPI.AccessControl=myapp.security.authenticator.MyAccessController ESAPI.Authenticator=myapp.security.authenticator.MyAuthenticator ESAPI.Encoder=org.owasp.esapi.reference.DefaultEncoder ESAPI.Encryptor=org.owasp.esapi.reference.JavaEncryptor Um exemplo de configuração contendo explicação detalhada de cada parâmetro de configuração do arquivo ESAPI.properties pode ser consultado em: 3

43 41 ESAPI.CipherText=org.owasp.esapi.reference.DefaultCipherText ESAPI.PreferredJCEProvider=SunJCE ESAPI.Executor=org.owasp.esapi.reference.DefaultExecutor ESAPI.HTTPUtilities=org.owasp.esapi.reference.DefaultHTTPUtilities ESAPI.IntrusionDetector=org.owasp.esapi.reference.DefaultIntrusionDetector ESAPI.Logger=myapp.security.log.MyLogger ESAPI.Randomizer=org.owasp.esapi.reference.DefaultRandomizer ESAPI.Validator=org.owasp.esapi.reference.DefaultValidator (...) Listagem 6: Arquivo de configuração referenciando outras classes. A Figura 6 mostra a diferença do uso isolado de bibliotecas de segurança que visam atender propósitos específicos em cada camada da aplicação, em contraposição à proposta com uso de uma biblioteca de segurança corporativa que centraliza e integra os diversos controles de segurança que a aplicação requer. Figura 6: Diferença entre o uso de uma API de segurança corporativa e o modo convencional (SCHMIDT, 2010). Neste caso, a ESAPI realiza o papel de biblioteca corporativa de segurança, provendo através desta arquitetura uma centralização e integração entre os componentes de segurança, permitindo o reuso de funcionalidades entre os componentes e permitindo também a redução do impacto da substituição de qualquer componente de segurança, fazendo com que os módulos da ESAPI

44 42 funcionem para a aplicação e entre si como uma fachada, conforme padrão Facade (GAMMA et al, 1995). Portanto, a ESAPI tem como principal característica ser altamente configurável, pois, além dos parâmetros anteriormente descritos, o arquivo de configuração da biblioteca contém diversos parâmetros que permitem maior customização da biblioteca e consequentemente uma maior aderência às particularidades das aplicações Controle de Autenticação e Gerenciamento de Sessão A autenticação é requisito fundamental para realizar o controle de acesso que tem por objetivo restringir o acesso dos usuários a determinadas operações e informações críticas. A interface Authenticator (org.owasp.esapi.authenticator) define um conjunto de métodos para a geração e manipulação de credenciais da conta e identificadores de sessão. O objetivo desta interface é fornecer um conjunto de métodos que realizam de maneira segura a autenticação e o gerenciamento de sessão dos usuários. A Figura 7 mostra como a ESAPI realiza a integração dos mecanismos de autenticação com os mecanismos de controle de acesso (AccessControl), log de eventos (Logger) e detecção de intrusão (Intrusion Detector). Figura 7: Integração do mecanismo de autenticação com os mecanismos de controle de acesso, log e detecção de intrusão (WILLIAMS, 2008).

45 43 A Figura 7 mostra através da ligação do componente de autenticação com a base de dados4 dos usuários que este componente deve consultar e manipular a base de usuários. Neste caso, os usuários da aplicação devem implementar a interface User (org.owasp.esapi.user). Deste modo, os controles de verificação de autenticação devem preceder o acesso a qualquer recurso do sistema quando for necessário a autenticação e o controle de acesso aos recursos. Após verificação das credenciais fornecidas pelos usuários, a ESAPI passa a criar um vínculo (através da variável de sessão) com o usuário autenticado, onde os demais módulos (controle de acesso, log e detecção de intrusão) podem utilizar esse vínculo com a instância do usuário para realizar a tomada de decisão de controle de acesso, realizar o registro de log associando o usuário que executou a ação e executar ações de resposta através do detector de intrusão, como encerrar a sessão do usuário, bloquear a conta do usuário, etc. Portanto, o objetivo é minimizar a responsabilidade do desenvolvedor para as questões de segurança que envolvem a autenticação e implementar alguns controles necessários, como controlar o número máximo de tentativas de autenticação, timeout da sessão, etc Controle de Acesso A interface AccessController (org.owasp.esapi.accesscontroller) contém um conjunto de métodos que podem ser usados em uma ampla variedade de propósitos para realizar o controle de acesso às URLs, funções de negócios, dados, serviços e arquivos. A Figura 8 mostra um exemplo de como as chamadas aos métodos da interface AccessController podem ser invocadas nas diversas camadas da aplicação para realizar o controle de acesso em diversos recursos da aplicação. Neste caso não se restringe apenas às base de dados relacionais, mas também qualquer outra forma de armazenamento da informação, como arquivo de texto, LDAP, XML, etc. 4

46 44 Figura 8: Métodos do mecanismo de controle de acesso invocados nas diversas camadas da aplicação (WILLIAMS, 2008). As chamadas aos métodos tem o propósito de auxiliar no processo de verificação das permissões de acesso do usuário a fim de verificar se o mesmo está autorizado a acessar uma determinada URL, função de negócio ou serviço. O propósito da interface de controle de acesso da ESAPI é centralizar a lógica de controle de acesso através de chamadas a funções simples que permitem que o controle de acesso seja de fácil utilização e configuração. A interface AccessController da ESAPI por padrão permite realizar 5 formas de verificação de controle de acessos: 1. Baseado nos tipos de dados - verifica se o usuário está autorizado a executar determinada ação sobre determinada classe. A verificação é realizada através dos seguintes métodos: - assertauthorizedfordata (String action, java.lang.object data) - isauthorizedfordata (String action, java.lang.object data) 2. Baseado nos arquivos - verifica se o usuário está autorizado a acessar determinado arquivo identificado pelo seu caminho na árvore de diretórios. A verificação é realizada através dos seguintes métodos:

47 45 - assertauthorizedforfile (String filepath) - isauthorizedforfile (String filepath) 3. Baseado em funções - verifica se o usuário está autorizado a acessar determinada função. A verificação é realizada através dos seguintes métodos: - assertauthorizedforfunction (String functionname) - isauthorizedforfunction (String functionname) 4. Baseado em serviços - verifica se o usuário está autorizado a acessar um determinado serviço. Ideal para aplicações que provêm acesso diferenciado para uma variedade de serviços de backend. A verificação é realizada através dos seguintes métodos: - assertauthorizedforservice(string servicename) - isauthorizedforservice (String servicename) 5. Baseado na URL - Verifica se o usuário está autorizado a acessar a URL da aplicação. A verificação é realizada através dos seguintes métodos: - assertauthorizedforurl(string url) - isauthorizedforurl (String url) Cada forma de realizar o controle de acesso possui métodos do tipo assertauthorizedfor* e isauthorizedfor*, onde na primeira forma é lançado uma exceção de segurança caso o usuário não possua permissão para acessar determinado recurso, enquanto no segundo caso a função apenas retorna verdadeiro ou falso como resultado da verificação de controle de acesso. A implementação padrão da interface AccessController (DefaultAccessController), faz uso dos seguintes arquivos de configuração associados com os tipos de controle de acesso: 1. DataAccessRules.txt 2. FileAccessRules.txt 3. FunctionAccessRules.txt 4. ServiceAccessRules.txt 5. URLAccessRules.txt A Listagem 7 mostra como configurar o controle de acesso às URLs no arquivo de configuração URLAccessRules.txt.

48 46 #path role,role allow/deny comment # /banking/* user,admin allow authenticated users can access /banking /admin admin allow only admin role can access /admin / any deny default deny rule Listagem 7: Exemplo de configuração do arquivo URLAccessRules.txt. Neste caso, o primeiro parâmetro é a expresão regular da URL, o segundo parâmetro os papéis (roles) envolvidos na regra e o terceiro parâmetro a permissão de acesso positiva (allow) ou negativa (deny). Os demais arquivos de configuração mencionados seguem um padrão similar de configuração ao que foi apresentado e exemplos de configuração podem ser consultados no seguinte endereço: waf/source/browse/trunk/src/test/resources/.esapi/fbac-policies?spec=svn3&r= Codificação dos Dados A interface Encoder (org.owasp.esapi.encoder) executa as funções de codificação e decodificação dos dados. Essas funções dependem de um conjunto de codecs que podem ser encontrados no pacote org.owasp.esapi.codecs. Estes incluem suporte para codificação nos formatos5: CSS, HTML, JavaScript, MySQL, Oracle, Percent Encoding (URL Encoding), VBScript, Unix e Windows. A interface Encoder da ESAPI possui diversos métodos que auxiliam no processo de codificação dos dados para diversos contextos, listados anteriormente. A seguir alguns dos métodos disponíveis: 5 encodeforbase64(byte[] input, boolean wrap) encodeforcss (String input) encodefordn (String input) encodeforhtml (String input) encodeforhtmlattribute (String input) encodeforjavascript (String input) encodeforvbscript (String input) encodeforos (Codec codec, String input)

49 47 encodeforldap (String input) Cada método é responsável por realizar codificação dos dados para cada contexto a fim de evitar que combinações de caracteres sejam utilizadas a fim de atingir determinados objetivos maliciosos na aplicação Validação dos Dados A interface Validator (org.owasp.esapi.validator) define um conjunto de métodos para canonicalização6 e validação de entrada de dados. A complexidade necessária para evitar que um conteúdo malicioso seja renderizado nas páginas HTML vem aumentando à medida que aumenta a complexidade dos novos formatos utilizados. Portanto, utilizar um analisador robusto e um conjunto de regras de Lista Branca (White List7) são formas mais apropriadas para detectar e prevenir contra as vulnerabilidades, em contraposição ao método de validação por Lista Negra (Black List8). A Listagem 8 mostra como implementar uma abordagem de validação para dados de entrada que contém conteúdo formatado (rich text) a ser renderizado no formato HTML: (...) String safemarkup = ESAPI.validator().getValidSafeHTML( "input", request.getparameter( "richtext" ), 2500, true ); // armazena ou renderiza o conteúdo da variável safemarkup (...) Listagem 8: Exemplo de uso do método getvalidsafehtml da interface Validator (NETO, 2010). A Listagem 9 mostra o uso do método getvalidinput() da interface Validator que pode ser utilizado para realizar a validação de um dado através da técnica de Processo no qual várias formas de um nome são transformadas em uma forma única (AFONSO et. al., 2009). 7 Validação pelo método de WhiteList ou Lista Branca, são empregados por mecanismos de validação de entrada de dados que utilizam uma lista ou expressão regular que contém valores que devem ser aceitos pela aplicação. https://www.owasp.org/index.php/permissive_whitelist 8 Validação pelo método de BlackList ou Lista Negra são empregados por mecanismos de validação de entrada de dados que utilizam uma lista ou expressão regular que contém valores que devem ser rejeitados pela aplicação. https://www.owasp.org/index.php/data_validation#sanitize_with_blacklist 6

50 48 lista branca, utilizando uma expressão regular definida pelo identificador SafeString armazenado no arquivo de configuração validator.properties: (...) //variável nome sujeita a validação atraves do metodo getvalidinput String safeinput = ESAPI.validator().getValidInput( "validacaoactionxpto", //contexto da operação request.getparameter("input"), //dados de entrada "SafeString", //identificador da expressão regular 1024, //indica o número máximo de caracteres false //flag que informa se deve ou não aceitar valores nulos ); // uso seguro da variável safeinput pela aplicação (...) Listagem 9: Exemplo de uso do método getvalidinput da interface Validator (NETO, 2010). A Listagem 10 mostra um exemplo de configuração das expressões regulares presentes no arquivo de configuração validator.properties. Validator.SafeString=^[\p{L}\p{N}.]{0,1024}$ Validator.IPAddress=^(?\:(?\:25[0-5] 2[0-4][0-9] [01]?[0-9][0-9]?)\\.){3}(?\:25[0-5] 2[0-4][0-9] [01]?[0-9][0-9]?)$ Validator.URL=^(ht f)tp(s?)\\\:\\/\\/[0-9a-za-z]([-.\\w]*[0-9a-za-z])*(\:(0-9)*)*(\\/?)([a-za-z09\\-\\.\\?\\,\\\:\\'\\/\\\\\\+\=&%\\$\#_]*)?$ Validator.CreditCard=^(\\d{4}[- ]?){3}\\d{4}$ Validator.SSN=^(?\!000)([0-6]\\d{2} 7([0-6]\\d 7[012]))([ -]?)(?\!00)\\d\\d\\3(?\!0000)\\d{4}$ Listagem 10: Trecho de configuração do arquivo validator.properties (NETO, 2010). Assim, caso for necessário definir uma nova expressão regular de validação na aplicação, basta incluí-la no arquivo de configuração e invocar o método getvalidinput() referenciando o identificador da regra Criptografia O módulo Encryptor da biblioteca ESAPI facilita o processo de criptografia/ decriptografia de dados sensíveis, utilizando parâmetros globais de criptografia que

51 49 envolvem algoritmos adequados e chaves fortes guardadas em um arquivo de configuração protegido. O trecho de código da Listagem 11 permite visualizar a simplicidade do uso da interface Encryptor. (...) String secret = "Secret Message"; CipherText encrypted = ESAPI.encryptor().encrypt( new PlainText( secret ) ); PlainText decrypted = ESAPI.encryptor().decrypt( encrypted ); (...) Listagem 11: Exemplo de uso do método encryptor() da interface Encryptor. O resultado do processo de criptografada executado no exemplo anterior sobre a mensagem original Secret Message, é: o66iwmh+f/jtazqr/k0wow== Listagem 12: Resultado do processo de criptografia. A chave de criptografia é definida no arquivo de configuração ESAPI.properties, conforme ilustrado na Listagem 13, onde além da chave de criptografia, pode ser definido o sal9 a ser usado na geração de hashes: (...) #============================================================== Encryptor.MasterKey=a6H9is3hEVGKB4Jut+lOVA== Encryptor.MasterSalt=SbftnvmEWD5ZHHP+pX3fqugNysc= #============================================================== (...) Listagem 13: Exemplo de configuração das variáveis MasterKey e MasterSalt no arquivo ESAPI.properties Tratando vulnerabilidades HTTP Um sal (salt) consiste no uso de um valor, geralmente aleatório ou conhecido da aplicação, utilizado para compor uma das entradas para uma função de hash. O uso do sal dificulta o processo de quebra do hash através de ataques de dicionário. 9

52 50 A interface HTTPUtilities contém uma coleção de métodos que provêm segurança adicional relacionadas com as requisições, respostas, sessões, cookies, headers e log HTTP. Além disso, a interface HTTPUtilities possui o seguinte conjunto de métodos que auxiliam na criptografia/decriptografia dos dados: Criptografia/Decriptografia da query string10: o encryptquerystring(string query) o decryptquery(string encrypted) Criptografia/Decriptografia de campos escondidos (Hidden Fileds): o encrypthiddenfield(string value) o dencrypthiddenfield(string encrypted) A Listagem 14 mostra como fazer a criptografia da query string utilizando o método encryptquerystring(): (...) <% String url = "http://example.com/pagina.jsp?encquery="; String querystring = "field1=value1&field2=value2&field3=value3"; String urlenc = url + ESAPI.httpUtilities().encryptQueryString(queryString); %> <a href=<%= urlenc %> > Link para pagina </a> (...) Listagem 14: Criptografia da query string utilizando o método encryptquerystring da interface HTTPUtilities (NETO, 2010). Esse processo pode ser útil quando se quer proteger os valores dos parâmetros contra adulteração maliciosa dos parâmetros, ou mesmo quando se quer evitar que os detalhes internos da aplicação sejam expostos nos parâmetros, como é o caso de exposição de: chaves das entidades, referências a arquivos, etc. Assim, isso permite que estes detalhes de implementação não sejam desnecessariamente expostos para os usuários. A Listagem 15 mostra o resultado da criptografia realizada sobre a query string do exemplo anterior utilizando o método encryptquerystring(): Tudo que vem após o marcador? na URL contendo um ou mais parâmetros compostos por campo/valor, ex: 10

53 f504b e bdc5c2e0d442d644b99d37839acd ccc ae0f06e462175ad4d87e0cb63e45c5f3c1bc120e26003e60b 2a9f0bcc837eead4c ed d31c a bbe87ec5abd89df3 a24 Listagem 15: Resultado da operação realizada pelo metodo encryptquerystring() da interface HTTPUtilities. Para decriptografar a query string, basta fornecer o valor contido no parâmetro que contém a string criptografada (encquery) para o método decryptquerystring(), conforme ilustrado na Listagem 16. (...) String encqueryparam = request.getparameter("encquery"); java.util.map<string, String> mapquerystring = ESAPI.httpUtilities().decryptQueryString(encQueryParam); (...) Listagem 16: Exemplo de uso do método decryptquerystring() da interface HTTPUtilities (NETO, 2010) Detector de Intrusão É o mecanismo que monitora as requisições e toma ações pré-configuradas para determinados eventos de segurança. A Figura 9 mostra a interação entre a classe EnterpriseSecurityException (org.owasp.esapi.errors.enterprisesecurityexception), que define as exceções de segurança lançados pela biblioteca, o mecanismo de registros de Log e o mecanismo de detecção de intrusão.

54 52 Figura 9: Integração das Exceções de Segurança com mecanismo de Log e Detecção de Intrusão (WILLIAMS, 2008). As exceções lançadas pelos diversos módulos invocam o mecanismo de log e o módulo de detecção de intrusão (IntrusionDetector) que realiza a contagem dos eventos e executa ações de resposta aos ataques baseado nos limiares definidos nos arquivos de configuração da biblioteca. Cada evento possui os parâmetros count, interval, e action que definem a quantidade de eventos tolerável para cada usuário, intervalo entre os eventos e a ação de resposta ao ataque. Os limiares são configurados no arquivo ESAPI.properties, conforme mostrado na Listagem 17. (...) IntrusionDetector.org.owasp.esapi.errors.IntrusionException.count=1 IntrusionDetector.org.owasp.esapi.errors.IntrusionException.interval=1 IntrusionDetector.org.owasp.esapi.errors.IntrusionException.actions=log,disable,logout IntrusionDetector.org.owasp.esapi.errors.AuthenticationHostException.count=5 IntrusionDetector.org.owasp.esapi.errors.AuthenticationHostException.interval=90 IntrusionDetector.org.owasp.esapi.errors.AuthenticationHostException.actions=log,logout (...) Listagem 17: Exemplo de configuração dos limiares do detector de intrusão. Adaptado de NETO (2010).

55 53 As ações de resposta previstos no componente padrão fornecido pela ESAPI são: log apenas faz log da requisição feita pelo usuário. logout invoca a ação de logout para conta do usuário que gerou a exceção. disable bloqueia a conta do usuário que gerou a exceção. Observe que no exemplo anterior, após a ocorrência de cinco exceções do tipo AuthenticationHostException, no intervalo de 3 minutos (90 segundos), fará com que o detector de intrusão realize o log e logout da conta do usuário. Enquanto que na primeira ocorrência de uma exceção do tipo IntrusionException, o detector de intrusão realizará, além das ações de log e logout, o bloqueio da conta. Essa diferença na severidade da ação de resposta caracteriza a diferenciação que a aplicação deve fazer entre os eventos suspeitos e eventos de ataque, a serem discutidos em maiores detalhes na seção OWASP Top 10 A OWASP possui um projeto chamado OWASP TOP 10, que descreve as 10 vulnerabilidades que mais ocorrem em aplicações web. A classificação das vulnerabilidades vão desde A1 até A10, indicando de modo ordenado as 10 vulnerabilidades mais críticas em aplicações web. O conteúdo dos tópicos apresentados a seguir foram extraídos de WILLIAMS e WICHERS (2010) Injeção de código - (A1) Falhas de injeção, tais como SQL, comandos do Sistema Operacional e comandos LDAP ocorrem quando dados não confiáveis são enviados para um interpretador como parte de um comando ou consulta. Os dados do ataque pode iludir o interpretador a executar comandos indesejáveis ou acessar dados não autorizados.

56 54 Os ataques de injeção baseiam-se na tentativa de utilizar os parâmetros de entrada da aplicação para inserir sequências de caracteres com propósitos maliciosos. Cenário de Ataque: A Figura 10 ilustra como uma requisição gerada por um usuário malicioso contendo injeção de código do tipo SQL Injection, a fim de afetar a integridade da aplicação, neste exemplo através de um comando direcionado a afetar o banco de dados da aplicação. Figura 10: Exemplo de atacante de SQL Injection na aplicação. A Listagem 18 mostra um exemplo de forma inadequada de implementação que utiliza os parâmetros providos pelo usuário sem nenhum tratamento. (...) Statement statement = connection.createstatement("select * FROM users WHERE custid = '"+ request.getparameter("id") + "'"); ResultSet rs = statement.executequery(); (...) Listagem 18: Exemplo de forma inadequada de construir uma consulta SQL (NETO, 2010). A concatenação direta sem nenhum tratamento é inadequada, pois a aplicação utiliza dados não confiáveis proveniente dos usuários na construção da consulta SQL.

57 55 A requisição contendo dados maliciosos nos parâmetros da aplicação pode ser enviada da seguinte forma: Listagem 19: Exemplo de ataque do tipo SQL Injection (NETO, 2010). O resultado da concatenação gera a consulta SQL mostrada na Listagem 20. SELECT * FROM users WHERE user_id = 'a';drop TABLE users;--'; Listagem 20: Exemplo de consulta SQL gerada pela aplicação (NETO, 2010). Como evitar: Realizar a validação de entrada de dados preferencialmente por Lista Branca, no lugar de validação por Lista Negra, com uma adequada normalização dos dados. Os campos escondidos (hidden fields) e os campos do cabeçalho (headers) devem ser validados com o mesmo rigor dos demais campos de formulário da aplicação, pois podem ser utilizados como fonte de dados de entrada e, portanto, devem ser validados. Considerar o uso do wrapper11 de requisição da ESAPI SecurityWrapperRequest implementado com o auxílio de filtros Java para auxiliar no processo de validação dos parâmetros, cabeçalhos, cookies, etc, que fazem parte das requisições HTTP. Utilizar algum mecanismo que facilite o processo de validação, como: o A interface Validator da ESAPI para realizar a validação dos dados de entrada (RODRIGUES, 2011). o A interface Validator (javax.faces.validator.validator) do JSF (CHANDLER, 2008). o Utilizar anotações JSR-3031 (Bean Validation) para realizar a validação dos dados (SACRAMENTO, 2011). Wrapper (empacotador) é um padrão de projeto onde a classe que realiza o papel de empacotador converte a interface de uma classe em outra interface esperada pelo cliente. Neste caso a classe SecurityWrapperRequest implementa a interface HttpServletResponse com reescrita de alguns métodos contendo implementações de segurança. 11

58 56 Realizar o tratamento dos parâmetros provenientes dos usuários ao realizar a concatenação dos dados, principalmente na construção de consultas SQL dinâmicas, mas também deve ser observado no uso de outras tecnologias, como: LDAP, SOAP, HTML, XML, comandos do Sistema Operacional, etc. Utilizar algum mecanismo que facilita o processo de codificação dos dados ao construir consultas SQL dinâmicas, ex: o Construir consultas parametrizadas (MANICO e WICHERS, 2011). o Utilizar o recurso de Named Queries do JPA (SCHAEFER, 2008). o Utilizar o método encodeforsql() da interface Encoder da ESAPI (NETO, 2010). Evitar utilizar interfaces de consultas dinâmicas, como executequery() ou similares (RODRIGUES, 2011). Aplicar o princípio do menor privilégio12. A Figura 11 ilustra como um mecanismo de validação dos dados de entrada pode barrar a tentativa de injeção de código: Figura 11: SQL Injection evitado através do mecanismo de validação dos dados de entrada. Adaptado de WEB... (2008). A Figura 12 ilustra como um mecanismo de codificação dos dados evita um ataque de SQL Injection, transformando os parâmetros enviados pelos usuários em Princípio que afirma que qualquer entidade (usuário, processo, etc.) deve receber os privilégios mínimos e os recursos durante o menor tempo possível para cumprir uma tarefa. Esta abordagem evita que uma entidade receba permissões que elas não precisam ter, reduzindo a oportunidade de acesso não autorizado à informações sigilosas (PAUL, 2011). 12

59 57 uma sequência literal de caracteres que ao serem concatenados na consulta SQL não fornecem riscos à aplicação. Figura 12: SQL Injection evitado através do mecanismo de codificação dos dados de entrada. Adaptado de WEB... (2008) Cross Site Scripting (XSS) - (A2) As falhas XSS ocorrem sempre que uma aplicação recebe dados não confiáveis e os envia para um navegador, sem que os tenha validado ou feito codificação dos caracteres, processo também conhecido como escaping ou encoding13 que correspondem ao processo de substituição de determinados caracteres ASCII pelas suas entidades HTML equivalentes. Por exemplo, a codificação poderia substituir o caractere < pela entidade HTML equivalente <. Essas entidades são inertes na maioria dos interpretadores especialmente em navegadores e podem atenuar ataques do lado do cliente. A vulnerabilidade XSS permite aos atacantes executarem scripts (java script, vb script, etc) no navegador da vítima, para com isso obter informações da sessão do usuário, alterar a aparência dos sites ou redirecionar o usuário para sites maliciosos. Os ataques XSS basicamente ocorrem de duas formas: XSS Persistido e XSS Refletido. Corresponde ao processo de substituição de determinados caracteres ASCII pelas suas entidades HTML equivalentes. Por exemplo, a codificação poderia substituir o caractere < pela entidade HTML equivalente <. Essas entidades são inertes na maioria dos interpretadores especialmente em navegadores e podem atenuar ataques do lado do cliente. 13

60 58 Cenário de ataque: XSS Persistido A aplicação usa dados não confiáveis na construção da página HTML, sem antes realizar a validação dos dados recebidos, ou então a codificação dos dados a serem renderizados na página HTML, conforme mostrado na Listagem 21. <html> (...) <%= Usuario usuario = UsuarioDAO.getUsuarioById (idusuario); %> Nome: <%= usuario.getnome() %> (...) </html> Listagem 21: Exemplo de renderização de dados persistidos sem prévia codificação dos dados. Neste caso, a sequência de caracteres recuperada do banco de dados é concatenada sem nenhum tratamento na construção da página HTML. A Figura 13 mostra um caso onde o atacante consegue persistir um script contendo ataque XSS no banco de dados da aplicação. Figura 13: Atacante consegue persistir um script XSS nobanco de Dados da aplicação. Adaptado de WEB... (2008). O atacante consegue realizar a persistência do script XSS, através de diversas formas, como: Envio de um formulário contendo script XSS nos campos do formulário.

61 59 Manipulação dos parâmetros de uma requisição GET ou POST. Persistência do script XSS através da exploração de uma vulnerabilidade de SQL Injection presente na aplicação. Requisição SOAP ou RESTful (quando se utiliza Web Services), que persiste os dados enviados contendo um script XSS. A Figura 14 mostra um caso onde o usuário acessa a página vulnerável que renderiza o script XSS persistido. Figura 14: O script XSS persistido pelo atacante é renderizadona tela do usuário (alvo do ataque). Adaptado de WEB... (2008). A falha está presente tanto na camada de controle que não realizou a validação dos dados de entrada, como na camada de apresentação que não codificou os dados exibidos na página, permitindo que o script XSS persistido seja renderizado no navegador do usuário. XSS Refletido É um tipo de ataque semelhante ao XSS persistido, porém neste caso a aplicação renderiza o conteúdo enviado nos parâmetros da requisição HTTP sem antes realizar o processo de validação dos dados de entrada ou a codificação dos dados a serem renderizados nas páginas HTML.

62 60 Os atacantes costumam explorar essa vulnerabilidade construindo uma URL que contém um script XSS e, através de técnica de phishing14, ilude os usuários da aplicação a clicar em um link que contém um script XSS malicioso. A Listagem 22 mostra como uma aplicação vulnerável renderiza a página HTML sem prévia validação e codificação dos dados. <html> (...) <p> Nome <%= request.getparameter("nome") %> </p> (...) <html> Listagem 22: Forma inadequada de renderizar uma página HTML (NETO, 2010). A Listagem 23 mostra como um atacante ilude o usuário a clicar no link que contém um script XSS. <script>document.location.href=http://evil.com/fakepage.jsp</script> Listagem 23: Exemplo de script XSS na URL construída pelo atacante (NETO, 2010). O script XSS do exemplo anterior redireciona o navegador do usuário para um site malicioso, do qual pode apresentar as mesmas características do site atacado, fazendo com que o usuário não perceba que está navegando em outro site, podendo fornecer para os atacantes informações sensíveis, como senha de acesso ao sistema, dados pessoais, etc. A Figura 15 ilustra o cenário onde o atacante envia um link contendo um script XSS que ao ser clicado pelo usuário envia uma requisição para uma página vulnerável, que por sua vez renderiza o script XSS. O phishing é uma forma de fraude, caracterizada por tentativas de iludir as pessoas ao se passar por uma pessoa ou organização confiável através do envio de comunicação oficial. Isto ocorre de várias formas, geralmente a forma mais comum é através do envio de s, mas também pode ocorrer com envio de mensagem SMS, links chamativos em sites não confiáveis, carta, etc. 14

63 61 Figura 15: Script XSS refletido é renderizado na tela do usuário (alvo do ataque). Adaptado de WEB... (2008). Como evitar (XSS Persistido e Refletido): Realizar o processo de codificação de caracteres para todos os dados renderizados nas páginas HTML, fazendo com que qualquer script submetido para a aplicação seja renderizado como um texto a ser exibido na tela do usuário, em vez de ser interpretado como um script pelo navegador, conforme mostrado na Listagem 24. <script> alert (); </script> script construído pelo atacante <script> alert() </script> conteúdo gerado pelo processo de codificação que pode ser renderizado com segurança pelo navegador Listagem 24: Exemplo de execução do processo de codificação. Adaptado de NETO (2010). Validar todas as entradas de dados por meio de um White List, incluindo: cabeçalhos, cookies, URL, campos do formulário, campos escondidos, etc. Considerar o uso da interface Validator da ESAPI e do wrapper SecurityWrapperRequest, abordados na seção 2.4.1, para auxiliar no processo de validação por Lista Branca. Considerar o uso do filtro ClickJackFilter15 da biblioteca ESAPI que é útil para controlar o uso de frames internos que geralmente são explorados pelos 15 https://www.owasp.org/index.php/clickjackfilter_for_java_ee

64 62 scripts XSS, através da flag X-FRAME-OPTIONS16 (opcionalmente implementado em alguns navegadores). O filtro pode ser configurado, através da definição do valor da flag, para impedir o uso de qualquer frame interno (modo DENY), ou permitir que os frames façam referências somente às páginas internas da aplicação (modo SAMEORIGIN). Utilizar frameworks que auxiliam na proteção contra XSS, ex: o Uso do método encodeforhtml() da interface Encoder da ESAPI (NETO, 2010). o Uso das tags JSF do tipo <h:outputtext /> e outras variações 17 (CHANDLER, 2008). Tanto o uso do método encodeforhtml da ESAPI, como das tags JSF realizam o tratamento das variáveis de saída através do método de codificação dos dados, explicados anteriormente. A Figura 16 mostra como um esquema de validação de dados pode impedir a persistência de um scripts XSS. Figura 16: Ataque XSS é evitado através de um mecanismo de validação dos dados de entrada. Adaptado de WEB... (2008). 17 Tags JSF do tipo <h:outputformat>, <h:outputlabel>, <h:outputlink> e caixas de seleção, como as do tipo selectone, ex: <h:selectoneradio>, <h:selectonemenu>, <h:selectonelistbox>, <h:selectbooleancheckbox>; e caixas de múltiplas seleção, do tipo selectmany, ex: <h:selectmanycheckbox>, <h:selectmanymenu>, <h:selectmanylistbox>. 16

65 63 A Figura 17 mostra como um processo de codificação de caracteres na camada de interface pode impedir que um script XSS persistido seja renderizado no navegador do usuário. Figura 17: Ataque XSS persistido é evitado através da codificação dos dados renderizados na tela do usuário. Adaptado de WEB... (2008). A Figura 18 mostra como um processo de codificação de caracteres na camada de interface impede que o script XSS refletido seja renderizado no navegador do usuário. Figura 18: Ataque XSS refletido é evitado através da codificação dos parâmetros renderizados na tela do usuário. Adaptado de WEB... (2008) Falha na Autenticação e no Gerenciamento de Sessão - (A3) As funções da aplicação relacionadas com autenticação e gerenciamento de sessões muitas vezes são implementadas de forma incorreta, permitindo que os

66 64 atacantes comprometam senhas, chaves e tokens de sessão ou, ainda, venham a explorar falhas da implementação para assumir a identidade de outro usuário. A autenticação e gerenciamento de sessão são críticos para a segurança na web. Portanto, falhas nesta área geralmente envolvem a falha na proteção de credenciais e nos tokens de sessão durante seu tempo de vida. Cenários de ataque: Cenário 1: Um atacante utiliza uma vulnerabilidade XSS para capturar o cookie de sessão dos usuários, conforme mostrado na Listagem 25. 'http://evil.com/cgi-bin/cookie.cgi?'%20+'document.cookie</script> Listagem 25: Exemplo de uso do parâmetro da query string para explorar vulnerabilidade XSS (NETO, 2010). Esse exemplo de ataque XSS faz com que o identificador de sessão da vítima seja enviado para a aplicação do atacante, permitindo-o capturar a sessão do usuário. Cenário 2: A aplicação não limita a quantidade de tentativas de autenticação no sistema, permitindo que um atacante possa descobrir a combinação login/senha utilizando um processo de tentativa-e-erro, conhecido como ataque por força-bruta, tentando várias combinações de caracteres até conseguir se autenticar no sistema. Como evitar: Levar em consideração os requisitos de autenticação e gerenciamento de sessão definidos nas áreas V2 (Autenticação) e V3 (Gerenciamento de Sessão) do documento OWASP ASVS (Application Security Verification Standard Project) (WILLIAMS e WICHERS, 2010). Fornecer uma interface simples de autenticação para os desenvolvedores, levando em consideração a interface Authenticator e User da ESAPI (NETO, 2010).

67 65 Adicionar uma restrição de segurança no arquivo de configuração web.xml 18 para todas as URLs que utilizam o protocolo HTTPs (RODRIGUES, 2011). A Listagem 26 mostra como declarar a restrição de segurança através da tag security-constraint informando as URLs (através da tag url-pattern) das quais deseja forçar o uso do HTTPs (através da definição do valor CONFIDENCIAL na tag transport-guarantee): <security-constraint> <web-resource-collection> <web-resource-name>páginas em HTTPS</web-resource-name> <url-pattern>/profile</url-pattern> <url-pattern>/register</url-pattern> <url-pattern>/password-login</url-pattern> <url-pattern>/ldap-login</url-pattern> </web-resource-collection> <user-data-constraint> <transport-guarantee>confidencial</transport-guarantee> </user-data-constraint> </security-constraint> Listagem 26 Trecho de configuração que força o uso do HTTPs (RODRIGUES, 2011). Evitar a ocorrência de falhas de XSS que podem ser utilizadas pelos atacantes para obter os identificadores de sessão dos usuários com a finalidade de roubar a sessão dos usuários Referência Insegura a Objetos - (A4) Uma referência insegura a um objeto ocorre quando um programador expõe uma referência à implementação direta de um objeto, como um arquivo, diretório, ou chave de tabelas no banco de dados, sem que para isto haja uma verificação de controle de acesso ou outra proteção. Os atacantes podem manipular estas referências para comprometer dados sensíveis e protegidos. O arquivo web.xml é um descritor de implementação que fica no WAR da aplicação no diretório WEB-INF/. Esse arquivo tem o propósito de descrever as classes, os recursos e a configuração da aplicação web, a fim de descrever como a aplicação deve atender as requisições web. 18

68 66 Geralmente as ferramentas automatizadas não conseguem capturar estas falhas, pois, não conseguem distinguir quais recursos necessitam ou não de proteção de controle de acesso. A prevenção contra as referências inseguras a objetos requerem a seleção de uma abordagem para proteger cada objeto acessado pelo usuário, por exemplo: o identificador do objeto, nome de arquivo, diretórios, etc. Cenário de ataque: O aplicativo constrói uma URL para compor a página de resposta, onde o usuário deve clicar para acessar a página contendo as informações da conta: Listagem 27: Exemplo de URL construída pela aplicação vulnerável (NETO, 2010). O sistema devolve a página contendo as informações da conta, baseado apenas no identificador informado pelo usuário, sem realizar nenhuma verificação de controle de acesso para a informação requisitada. A Listagem 28 mostra um exemplo de implementação deste cenário. (...) int userid = Integer.parseInt( request.getparameter( "userid" ) ); String query = "SELECT * FROM table WHERE userid=" + userid; //execução da consulta SQL (...) Listagem 28: Exemplo de execução de consulta sem prévia verificação de controle de acesso (NETO, 2010). Caso o atacante modifique o parâmetro "userid" no navegador, informando um número de conta válido, é possível consultar informações de outras contas, conforme mostrado na Listagem 29. acesso legítimo acesso indevido Listagem 29: Exemplo de modificação maliciosa do parâmetro userid. Adaptado de NETO (2010).

69 67 Como evitar: Validar referências a objetos internos usando lista de valores válidos para cada usuário. Utilizar a interface AccessReferenceMap da ESAPI para construir um mapa de referência indireta com o propósito de mascarar os valores das referências dos objetos da aplicação (NETO, 2010). Quando utilizar tags JSF de seleção do tipo selctone(...) e selectmany(...), observar as recomendações de segurança presentes em CHANDLER (2008). A Figura 19 mostra um exemplo de mapa de referência de acesso que associa as referências de um objeto da aplicação, com as referências que podem ser expostas para os usuários. Figura 19: Exemplo de mapa de referência. A URL construída pela aplicação passa a referenciar o identificador do mapa de referência, que por sua vez aponta para a chave do objeto interno ao sistema, ex: Listagem 30: Exemplo de URL construída utilizando referência indireta Cross Site Request Forgery (CSRF) - (A5) Um ataque CSRF força a vítima que tenha uma sessão ativa em um navegador a enviar uma requisição HTTP forjada, incluindo o cookie da sessão, bem como outras informações da sessão, a uma aplicação WEB vulnerável. Esta falha permite

70 68 ao atacante forçar o navegador da vítima a disparar requisições que a aplicação vulnerável aceite como requisições legítimas oriundas da vítima. O ataque funciona porque a credencial de autorização do usuário (geralmente o cookie de sessão) é automaticamente incluída nas requisições que o navegador envia para a aplicação (RODRIGUES, 2011). Cenário de ataque: A aplicação permite a um usuário submeter uma requisição de alteração de estado que não possui qualquer token secreto, conforme ilustrado na Listagem 20. Listagem 31: Exemplo de modificação maliciosa realizada no parâmetro destinationaccount (NETO, 2010). O atacante constrói uma requisição que transfere dinheiro da conta da vítima para a sua conta e adiciona esta requisição maliciosa em uma imagem ou frame armazenado em diversos sites, fóruns, ex: <img src="http://example.com/transferfunds?amount=1500&destinationaccount= <conta do atacante>#"width="0" height="0" /> <img src="http://example.com/transferfunds?amount=1500&destinationaccount= #"width="0" height="0" /> Listagem 32: Exemplo de código HTML contendo requisições CSRF (WILLIAMS e WICHERS, 2010). Caso a vítima esteja autenticada no site vulnerável (example.com) e visite qualquer página web contendo requisições maliciosas do tipo CSRF, a requisição enviada pelo navegador irá incluir as informações da sessão do usuário (cookie de sessão), que por sua vez serão executados normalmente pela aplicação. Como evitar: Requisitar senha do usuário nas operações sensíveis.

71 69 o Possui a desvantagem de atrapalhar a usabilidade. Incluir tokens não dedutíveis como parte de cada requisição que gera uma transação crítica. o Os tokens devem ser, no mínimo únicos para cada sessão do usuário, como também podem ser únicos por requisição. o Existem duas formas de inserir o token: incluir um token em um campo escondido (hidden field) nos formulários. Isto faz com que o valor seja enviado no corpo da requisição HTTP para evitar sua inclusão na URL, ex: <html> (...) <input name="token" type="hidden" value="8fd4b2" /> (...) </html> Listagem 33: Exemplo de token CSRF armazenado em um campo do tipo HIDDEN. Adaptado de NETO (2010). incluir o token como parâmetro da URL, ex: destinationaccount= &token=8fd4b2 Listagem 34: Exemplo de token CSRF armazenado em um parâmetro da query string. Adaptado de NETO (2010). o Para facilitar o processo de criação e verificação dos tokens anticsrf, é recomendável o uso dos métodos addcsrftoken(), getcsrftoken() e verifycsrftoken() da interface HTTPUtilities da ESAPI (NETO, 2010). o O JSF implementa algumas proteções contra CSRF através do javax.faces.viewstate, que insere automaticamente um token CSRF criado pelo framework nas páginas de resposta, inserindo automaticamente campos escondidos (do tipo hidden) para armazenar os valores dos tokens. Porém, segundo BAUER (2011) algumas implementações do JSF podem gerar tokens com baixo nível de segurança, como é o caso da implementação do Seam Framework que

72 70 utiliza um identificador sequencial, como também nas versões anteriores à versão 2.0 do JSF que gera tokens que podem ser deduzidos por um atacante Configuração de segurança deficiente - (A6) A segurança da aplicação depende também de como são configurados os aspectos de segurança no sistema operacional, servidor de aplicações, servidor de banco de dados e demais serviços dos quais a aplicação depende para o seu funcionamento. Todas essas configurações devem ser definidas, implementadas e mantidas, pois, muitas vezes, elas não são aplicadas diretamente da fábrica ou não são distribuídas com os padrões de segurança corretamente definidos. Também faz parte deste contexto a atualização das bibliotecas utilizadas pela aplicação. Como trata-se de um problema que envolve apenas aspectos de infraestrutura, não há solução de código que possa reduzir ou mitigar essa vulnerabilidade Armazenamento criptográfico inseguro - (A7) Muitas aplicações não protegem adequadamente dados sensíveis, como números de cartões de créditos, dados pessoais (CPF, endereço, telefone) e credencias de autenticação com algoritmos de encriptação e hashing. Os atacantes podem usar esta vulnerabilidade na proteção dos dados para realizar roubo de identidade, compras fraudulentas com número de cartão de crédito ou outros crimes. É comum não haver criptografia de dados sensíveis na aplicação, ou mesmo haverem aplicações que possuam algoritmos mal concebidos, ou uso de mecanismos de criptografia inapropriados. Cenário de ataque:

73 71 A base de dados de senhas utiliza hash sem salt19 para armazenar as senhas de todos usuários. Uma falha na aplicação permite que um atacante recupere o arquivo contendo a base de senhas. Através de um processo de quebra de hash é possível descobrir as senhas dos usuários. Como evitar: Determinar quais dados são sensíveis o suficiente para justificar o uso de criptografia. Para todos dados sensíveis deve-se assegurar que: o Os backups sejam criptografados e que as chaves sejam gerenciadas e armazenadas separadamente. o Somente usuários autorizados podem acessar as cópias dos dados descriptografados. o Um padrão de algoritmo de criptografia forte esteja sendo utilizado, preferencialmente os recomendados pela e-ping20 e ICP-Brasil21. o Uma chave forte tenha sido gerada, protegida contra acesso não autorizado e que a troca das chaves seja frequente e planejada. Garantir padrões de algoritmos robustos e que as chaves sejam fortes, ou seja, difíceis de serem deduzidas, como também que o gerenciamento das chaves seja feito de modo adequado. Certificar-se que as senhas dos usuários sejam armazenadas no formato de hash com uso de um algoritmo de hash forte e que salts apropriados sejam utilizados na geração dos hashes. Considerar o uso da interface Encryptor da ESAPI para realizar a criptografia/descriptografia dos dados, bem como a geração de hash e assinatura digital nos casos previstos Falha ao restringir o acesso às URLs - (A8) Geralmente a única proteção que a aplicação fornece para o acesso a uma página é simplesmente não exibir os links ou botões que dão acesso às páginas Um hash sem salt pode ser descoberto por ataque de força bruta em aproximadamente 4 semanas, enquanto que um hash gerado com salt poderia levar mais de anos para ser quebrado (WILLIAMS e WICHERS, 2010)

74 72 sensíveis para usuários não autorizados. No entanto, um atacante pode ser capaz de descobrir e acessar estas páginas com o propósito de executar funções e visualizar dados sensíveis. Portanto, a segurança por obscuridade não é suficiente para proteger os dados e funções sensíveis em uma aplicação. Cenário de ataque: O atacante simplesmente modifica o apontamento da URL de destino no navegador para uma URL não autorizada, ex: acesso legítimo acesso indevido à pagina administrativa Listagem 35: Exemplo de exploração da vulnerabilidade através da adulteração da URL (NETO, 2010). Como evitar: Determinar quais páginas devem ser públicas e quais devem ser privadas. Verificar se o aplicativo restringe adequadamente o acesso às URLs para as páginas privadas, determinando quais páginas requerem autenticação e verificação de autorização para garantir que somente usuários autorizados acessem as páginas sensíveis. As políticas de autenticação e autorização devem ser preferencialmente baseadas em papéis (RBAC) para minimizar o esforço necessário da manutenção destas políticas. As políticas devem ser configuráveis, de modo a minimizar qualquer aspecto codificado da política. O mecanismo de execução deve por padrão negar todos os acessos, necessitando de permissões explícitas para usuários e papéis específicos para permitir o acesso a cada página. Se a página estiver envolvida em um fluxo de trabalho, é necessário verificar se as condições estão em um estado apropriado para conceder o acesso aos recursos. Considerar o uso do método isauthorizedforurl() da interface AccessController da ESAPI para realizar o controle de acesso às URLs, conforme abordado na seção

75 73 Considerar o uso dos métodos isauthorizedfordata(), isauthorizedforservice(), isauthorizedforfunction() e isauthorizedforfile() da interface AccessController da ESAPI nos casos em que forem aplicáveis. Utilizar as tags security-constraint e auth-constraint no arquivo de configuração web.xml para definir o controle de acesso a perfis Java EE para a URL (RODRIGUES, 2011). Portanto, a aplicação deve realizar as verificações de controle de acesso antes de permitir que uma solicitação a um recurso (função, arquivo, ou página sensível), com o propósito de garantir que somente os usuários autorizados acessem os recursos que tem direito Proteção ineficaz da camada de transporte - (A9) As aplicações geralmente falham quando realizam a criptografia do tráfego de rede quando é necessário proteger o tráfego de dados sensíveis. A criptografia (geralmente através do SSL) deve ser usada em todas as conexões autenticadas, especialmente páginas web com acesso via internet, mas também conexões com o back-end, caso contrário, o aplicativo irá expor uma autenticação ou o token de sessão. A autenticação deve ser usada sempre que dados sensíveis forem transmitidos. Assim, aplicações cujo modo de encriptação possa ser subvertido, frequentemente tornam-se alvos de ataques. Como evitar: Exigir conexão SSL em todas as páginas sensíveis. As requisições que não fazem uso de SSL para estas páginas devem ser redirecionadas para a respectiva página SSL. o Considerar o uso dos métodos assertsecurerequest() e assertsecuritychannel() da interface HTTPUtilities da ESAPI (NETO, 2010), a fim de garantir o uso do SSL nas páginas críticas. Verificar se o SSL é usado para proteger todo tráfego relacionado a autenticação.

76 74 Verificar se o SSL é usado para todos os recursos em todas as páginas e serviços privados para proteger todos os dados e tokens de sessão que são trocados entre sistemas. Verificar se as conexões de backend e demais conexões utilizam as tecnologias de criptografia SSL ou similares. Verificar se somente algoritmos de criptografia robustos (compatível com o FIPS 140-2) estejam sendo utilizados na comunicação SSL. Verificar se todos os cookies de sessão possuem a flag "secure" definido para o navegador e que nunca sejam transmitidos em claro. o Considerar o uso do wrapper22 de resposta da ESAPI em filtros Java SecurityWrapperResponse que força o uso da flag secure (NETO, 2010). Verificar se o certificado de servidor é legítimo e está corretamente configurado para o servidor. Obs.: isso inclui o fato do certificado ser emitido por uma autoridade certificadora confiável, não estar expirado nem revogado e que seja válido para todos os sub-domínios do site Redirecionamentos inseguros - (A10) As aplicações Web frequentemente redirecionam os usuários para outras páginas e sites através do uso de dados não confiáveis provenientes dos usuários para determinar as páginas de destino. Sem a devida validação dos dados, os atacantes podem redirecionar as vítimas para sites de phishing ou malware, ou então utilizar o mecanismo de encaminhamento para acessar páginas não autorizadas. Cenários de ataque: Cenário 1: A aplicação possui uma página que realiza o redirecionamento para uma "url" fornecida como parâmetro. O atacante utiliza técnica de phishing fornecendo aos usuários da aplicação a URL contendo um redirecionamento a uma página maliciosa, ex: Neste caso a classe SecurityWrapperResponse implementa a interface HttpServletResponse com reescrita de alguns métodos contendo implementações de segurança. 22

77 75 url manipulada Listagem 36: Exemplo de uso do mecanismo de redirecionamento para página maliciosa (NETO, 2010). Cenário 2: O aplicativo usa o método forward em uma página para fazer o roteamento das requisições entre as diferentes seções do site. A página utiliza o parâmetro fwd para indicar qual página o usuário deve ser encaminhado se a transação for bem-sucedida. Neste caso, o atacante insere uma URL no parâmetro com o propósito de burlar o mecanismo de controle de acesso da aplicação para encaminhar o atacante para uma função administrativa que normalmente não deveria ser capaz de acessar, ex: url original url manipulada Listagem 37: Exemplo de ataque que utiliza o mecanismo de redirecionamento para acessar página sensível da aplicação (NETO, 2010). Como evitar: Não utilizar parâmetros dos usuários para o cálculo da URL de destino, ou então utilizar referências indiretas (abordados na seção 2.4.4) para as URLs. Assegurar que o valor fornecido seja válido e autorizado para o usuário. Considerar o uso dos métodos sendredirect() e sendforward() da interface HTTPUtilities da ESAPI a fim de realizar os redirecionamentos e encaminhamentos de forma segura (NETO, 2010) Detecção e resposta a ataques com o uso do AppSensor O projeto AppSensor define um framework conceitual e metodologia que oferece orientações prescritivas para implementar um mecanismo de detecção e resposta automática contra tentativas de intrusão em uma aplicação existente (COATES, 2009). O AppSensor é composto basicamente por dois módulos:

78 76 Unidade de Detecção - responsável por identificar comportamento malicioso baseado em políticas definidas. Unidade de Resposta responsável por executar ações de resposta quando o comportamento malicioso é detectado. A Figura 20 mostra como os pontos de detecção podem ser integrados às camadas de apresentação, negócio e dados da aplicação, onde a unidade de detecção reporta as atividades para a unidade de resposta. Figura 20: Arquitetura do AppSensor (COATES, 2009). Segundo COATES (2009), as aplicações devem detectar os ataques, identificar o uso normal e o uso suspeito para identificar de forma automática quem são os atacantes e bloquear os ataques em tempo real, modificando a acessibilidade da aplicação por motivos de defesa. A seguir, a diferença entre evento suspeito e evento de ataque (COATES, 2009): Evento suspeito: Pode ocorrer durante a experiência normal do usuário com o site ou navegador. Pode ocorrer como resultado de um erro do usuário não-malicioso. Evento de ataque:

79 77 Fora do fluxo normal da aplicação. Requer ferramentas especiais para gerar as requisições. Requer conhecimento especializado. Portanto, o AppSensor deve atingir dois objetivos principais (COATES, 2009): 1. Garantir que usuários não maliciosos que cometeram erros acidentais não sejam injustamente punidos. 2. Detectar e responder as ações de ataques maliciosos Pontos de detecção Segundo WATSON (2011), atualmente existem mais de 50 pontos de detecção definidos no site do projeto AppSensor 23, que são definidas em conjunto com uma série de ações de resposta. Muitos ataques são óbvios e não podem ser entendidos como "erro do usuário", como receber uma requisição POST quando se espera receber uma requisição GET, quando os cabeçalhos ou campos escondidos são modificados, ou quando uma sequência de caracteres que tipifica um ataque XSS for submetido para a aplicação. Os pontos de detecção são identificados com siglas que categorizam o evento, ex: RE - Request (Requisição), AE - Authentication (Autenticação), SE Session Management (Gerenciamento de Sessão), ACE - Access Control (Controle de Acesso), IE - Input (Entrada de Dados), EE Encoding (Codificação), CIE Command Injection (Injeção de Comandos). Cada ponto de detecção é definido com o prefixo da categoria seguido de um número, ex: RE1, RE2, ACE1, ACE2. Segundo COATES (2009), os seguintes pontos de detecção devem ser considerados em uma implementação básica de detecção de ataques: RE - Request: RE1, RE2, RE3 e RE4 AE - Authentication: AE1, AE2 e AE3 SE - Session Management: SE5, SE6 ACE - Access Control: ACE1, ACE2 IE - Input: IE1, IE2 e IE3 23 https://www.owasp.org/index.php/owasp_appsensor_project

80 78 Além dos pontos de detecção recomendados, este trabalho irá abordar também sobre os seguintes pontos de detecção: EE - Encoding: EE1 e EE2 CIE - Command Injection: CIE1 O Apêndice A contém uma explicação detalhada dos pontos de detecção listados anteriormente. Os pontos de detecção do AppSensor podem ser implementados em uma aplicação utilizando dois métodos: Utilizando um método de conexão orientada a aspectos (baseados em filtros java); Implementação que modifica o código dentro da camada de negócio da aplicação. A Figura 21 mostra como os filtros podem ser aplicados para diferentes requisições em combinações diferentes. Figura 21: Combinação de diferentes filtros tratando requisições distintas (WEB..., 2008).

81 79 Deste modo, os filtros são uma ferramenta poderosa para tratar aspectos de segurança que envolvem toda a aplicação. De modo geral, o lançamento dos pontos de detecção ocorrem da seguinte forma: (...) if ( intrusiondetected() ) { //Condição que caracteriza um evento de segurança new AppSensorException ( "COD", //Codigo do ponto de detecção (ex: RE1, ACE1, IE1) "User Message", //Mensagem para o usuario (ex: "Operação ilegal") "Log Message"); //Mensagem de Log (ex: "Envio de metodo HTTP invalido") } (...) Listagem 38: Forma de lançar os pontos de detecção (NETO, 2011). O primeiro parâmetro da exceção AppSensorException contém o identificador do ponto de detecção, o segundo parâmetro a mensagem para ser exibida para o usuário (caso houver interesse) e o terceiro parâmetro contém a mensagem com detalhes da exceção para serem gravados nos registros de log da aplicação. Após lançada a exceção o mecanismo de detecção de intrusão irá incrementar a contagem da exceção e efetuar a resposta à exceção baseado no que foi definido nas políticas de segurança presentes nos arquivos de configuração. O AppSensor provê alguns filtros de segurança presentes no pacote org.owasp.appsensor.filters, que auxiliam na detecção de alguns pontos de detecção: IpAddressChangeDetectionFilter - é um filtro que detecta se o endereço IP associado a um identificador de sessão foi modificado durante a validade da sessão. Isso poderia apontar para um invasor tentando utilizar em outro computador um identificador de sessão capturado. Ao detectar a ocorrência do fato, o filtro lança o ponto de detecção SE6. UserAgentChangeDetectionFilter - é um filtro que detecta se o agente usuário associado a um identificador de sessão foi modificado durante a validade da sessão. Isso poderia apontar para um invasor tentando utilizar em outro computador um identificador de sessão capturado. Ao detectar a ocorrência do fato, o filtro lança o ponto de detecção SE5.

82 80 AppSensorRequestBlockingFilter - é um filtro que fornece tratamento padrão de bloquear requisições que são gerenciadas pelo AppSensor. A classe AttackDetectorUtils (org.owasp.appsensor.attackdetectorutils) é fornecida pelo componente AppSensor e possui um conjunto de métodos que auxiliam na detecção de ataques, listados a seguir com os respectivos pontos de detecção associados: verifyvalidrequestmethod RE1, RE2, RE3 RE4 verifyxssattack IE1 verifysqlinjectionattack CIE1 verifycookiespresent SE3, SE4 verifynullbytedoesnotexist CIE3 verifycarriagereturnorlinefeeddoesnotexist - CIE4 Embora o uso de verificação por Lista Negra seja uma prática pouco recomendada, o uso dos métodos verifyxssattack() e verifysqlinjectionattack() podem ser utilizados em filtros de detecção para monitorar os valores enviados nos parâmetros das requisições para lançar eventos de segurança que caracterizam os pontos de detecção IE1 (Tentativa de Cross Site Scripting) e CIE1 (Injeção de Comandos) para os caso onde for encontrado um padrão que corresponde aos padrões de ataque esperados. Os padrões de Lista Negra para serem utilizados na verificação de Cross Site Scripting e SQL Injection são definidos no arquivo appsensor.properties. O trecho de configuração da Listagem 39 mostra um exemplo de expressão regular que pode ser utilizada como referência na detecção de SQL Injection e XSS: ( ) xss.attack.patterns="><script>,script.*document\\.cookie,<script>,<img.*src.*\=.*script,<ifr ame>.*</iframe> (...) Listagem 39: Padrões de detecção de ataques do tipo XSS e SQL Injection (NETO, 2011).

83 81 O ideal é que a resposta a estes eventos sejam configurados de modo que não venham categoricamente ser interpretados na primeira ocorrência como um ataque, mas sim como um evento suspeito, a fim de evitar falsos positivos. Como a definição da tolerância aos eventos tem a ver com a configuração das ações de resposta aos pontos de detecção, então esses detalhes serão abordados na próxima seção que trata sobre ações de resposta. A tabela a seguir, extraída de WATSON (2011), apresenta a correlação dos pontos de detecção com as vulnerabilidades do OWASP Top 10. A escala de correlação do ponto de detecção com a vulnerabilidade é definida como: pouco relevante, parcial e forte, conforme descrito na legenda. A1 A2 A3 A4 A5 A6 A7 A8 A9 A10 Request RE1 RE2 RE3 RE4 AE1 AE2 AE3 Session SE5 Management SE6 ACE1 ACE2 ACE3 ACE4 Authentication Access Control Input Encoding IE1 IE2 IE3 EE1 EE2

84 82 Command CIE1 Injection Legenda: Forte Parcial Pouco relevante Tabela 1: Correlacionamento entre os pontos de detecção vulnerabilidades descritas no OWASP Top 10 (WATSON, 2011). e as Ao analisar a Tabela 1 é possível perceber que ao implementar os pontos de detecção abordados neste trabalho, é possível solucionar os problemas de vulnerabilidades associados com os riscos A2, A4, A6 e A8, enquanto resolvem parcialmente os riscos A1, A3 e A Ações de Resposta Segundo COATES (2009), a detecção de eventos é inútil se não estiver acompanhada de uma resposta automática para impedir e evitar a execução de um ataque. A política de resposta deve ser estabelecida ao definir limites específicos e ações de resposta com base nas ações de detecção de um usuário. Em cada caso, a ação do evento e resposta tomadas devem pelo menos serem registradas em log. O AppSensor além de conter o conjunto de ações de resposta previstos no DefaultIntrusionDetector (log, logout, disable), contém as seguintes ações de resposta complementares: disablecomponent bloqueia o acesso ao componente que foi invocado para realizar a intrusão usando o componente AppSensorServiceController. disablecomponentforuser bloqueia o acesso ao componente que foi invocado para realizar a tentativa de intrusão, apenas para o usuário logado (se existir), usando o componente AppSensorServiceController. admin envia um para o administrador notificando-o da ocorrência da ação maliciosa.

85 83 smsadmin envia um SMS para o administrador notificando-o da ação maliciosa. Esse conjunto complementar de respostas da aplicação permite executar ações preventivas como: desabilitar componente para todos os usuários, desabilitar componente somente para o usuário que está realizando um ataque e ações que visam informar o administrador do sistema da ocorrência de determinados eventos de segurança. A Figura 22 mostra o relacionamento entre os pontos de detecção, implementados nas diversas camadas da aplicação, com o controle central do AppSensor. Figura 22: Correlacionamento entre Pontos de Detecção, AppSensor e Base de Usuários (COATES, 2011).

86 84 Os pontos de detecção informam ao AppSensor a ocorrência dos eventos de segurança e este, por sua vez, tem acesso à base de dados do usuário (User Store) e com isso pode tomar ações de resposta contra o usuário que está realizando um ataque contra a aplicação. As respostas aos pontos de detecção podem ser configuradas tanto no arquivo ESAPI.properties, como no arquivo appsensor.properties. O trecho de configuração a seguir mostra uma exemplo de configuração dos eventos IE1 e CIE1, discutidos na seção 2.5.1, previstos para que o AppSensor tolere para cada usuário 3 eventos do tipo a cada 10 segundos: (...) IntrusionDetector.IE1.count=3 IntrusionDetector.IE1.interval=10 IntrusionDetector.IE1.actions=log, logout, disable IntrusionDetector.CIE1.count=3 IntrusionDetector.CIE1.interval=10 IntrusionDetector.CIE1.actions=log, logout, disable (...) Listagem 40: Exemplo de configuração dos pontos de detecção. Adaptado de NETO (2011). Ao configurar o AppSensor desta forma, deduz-se que um usuário legítimo em seu uso normal da aplicação não irá acidentalmente submeter valores suspeitos nos parâmetros em um intervalo de tempo inferior a 10 segundos. Com isso é possível detectar o uso de ferramentas que fazem busca por vulnerabilidades na aplicação, reduzindo as chances de um usuário malicioso encontrar vulnerabilidades na aplicação. Ao fazer uso de uma ferramenta que busca por vulnerabilidades na aplicação, provavelmente esta irá submeter diversos vetores de ataque contra a aplicação, entre eles padrões de ataques do tipo SQL Injection e XSS, em um curto período de tempo, através de um processo de busca por vulnerabilidades na aplicação. A Figura 23 mostra como um mecanismo que executa o papel de AppSensor pode reduzir as chances de um usuário malicioso encontrar uma vulnerabilidade explorável na aplicação.

87 85 Figura 23: AppSensor detectando usuários maliciosos. Adaptado de COATES (2011). Segundo COATES (2009), enquanto um firewall de aplicação apenas realiza detecção de ataques genéricos, que nem sempre são eficazes, o AppSensor possui a vantagem de ser integrado à aplicação, permitindo assim realizar interação com o objeto do usuário e implementação de controles complementares que só seriam possíveis através do conhecimento de detalhes da aplicação. Por sua vez, a técnica de análise de log é lenta, reativa e pouco efetiva. Portanto, é possível perceber claramente as vantagens de uso do AppSensor na aplicação, permitindo uma capacidade de responder aos ataques de maneira mais ágil e efetiva.

88 86 3 Teste de Vulnerabilidade no Demoiselle Framework Com o intuito de identificar vulnerabilidades na aplicação desenvolvida com o framework, foram realizados testes de segurança sobre a aplicação exemplo (ContactList), utilizando as ferramentas OWASP ZAP (Zed Attack Proxy) e Firebug. É importante destacar que o simples fato de encontrar uma vulnerabilidade de segurança na aplicação não significa necessariamente que a vulnerabilidade faça parte do framework Planejamento dos testes Os seguintes passos foram planejados para a execução dos testes: 1. Conhecer as regras de negócio implementadas pela aplicação para direcionar o processo de validação dos mecanismos de segurança, com o propósito de identificar ausência de controles, ou mesmo a ineficácia dos mesmos. O propósito maior é entender as regras de negócio e identificar possíveis brechas de segurança, como acesso às páginas ou operações que deveriam ser restritas a determinado grupo de usuários. O processo de entendimento da aplicação pode ser realizado configurando a ferramenta OWASP ZAP (ver Seção ) como proxy para realizar a busca passiva de vulnerabilidades. 2. Executar o processo de busca ativa de vulnerabilidades com a ferramenta OWASP ZAP, que compreende os testes automatizados, com o propósito de encontrar vulnerabilidades conhecidas apontadas pela ferramenta.

89 87 3. Gerar requisições manuais que visam executar operações restritas na aplicação com o auxílio da ferramenta OWASP ZAP. 4. Tentar acessar URLs restritas através da modificação da URL no navegador. 5. Tentar modificar, com o auxílio da ferramenta Firebugs, as propriedades dos objetos de interface para executar uma operação crítica de negócio autenticado com usuário não autorizado. 6. Analisar os resultados reportados tanto pelos testes automatizados, como pelos testes manuais, com o propósito de compreender a causa raiz do problema e mapear soluções que poderiam resolvê-los Ferramentas utilizadas nos testes OWASP ZAP A ferramenta OWASP ZAP é uma aplicação de código aberto, desenvolvido pela comunidade OWASP que permite realizar testes de segurança caixa preta em aplicações web. A aplicação possui diversos recursos que permitem realizar busca ativa (active scanning) e passiva (passive scanning) de vulnerabilidades. A busca ativa realiza o processo de spidering, visando realizar o mapeamento das páginas de um determinado domínio e gerar requisições automáticas que visam encontrar vulnerabilidades conhecidas. Já a busca passiva consiste em analisar o tráfego de resposta HTTP para gerar alertas nos casos onde for detectado algum problema. A aplicação OWASP ZAP foi escolhida por ser gratuita, fácil de usar e suportada por uma comunidade ativa. Segundo BENNETTS (2011), atualmente o projeto OWASP ZAP é considerado um projeto chave da OWASP. Além disso, a aplicação funciona como um proxy, permitindo, com isso, que as requisições geradas pelo navegador possam ser interceptadas e modificadas antes de serem encaminhadas para a aplicação web. Esse recurso permite que o usuário possa gerar requisições customizadas com o propósito de gerar testes manuais de segurança que complementam os testes automatizados. Apesar da ferramenta OWASP ZAP oferecer mecanismos para testes automatizados, ainda se faz necessário a execução de testes manuais, pois, os

90 88 mecanismos de busca automatizados não conseguem diferenciar quais recursos são restritos a determinados usuários. A Figura 24 mostra a interface da aplicação ZAP Proxy. Figura 24: Interface da aplicação OWASP ZAP Firebug O Firebug é um plugin que é instalado no navegador Firefox. Este plugin permite alterar as propriedades dos componentes de interface renderizados pelo navegador. Este plugin ajuda a complementar os testes de realizados pela ferramenta OWASP ZAP. O plugin foi utilizado nos casos onde a manipulação das propriedades dos objetos de interface podem revelar alguma vulnerabilidade na aplicação Resultados dos testes

91 89 Esta Seção trata sobre os resultados dos testes automatizados e manuais executados sobre a aplicação ContactList Resultados dos testes automatizados A Figura 25 mostra a tela que consolida os alertas gerados pela busca ativa e passiva da ferramenta OWASP ZAP. Figura 25: Lista de Alertas da ferramenta OWASP ZAP. Observe que foi encontrado apenas uma vulnerabilidade de alto risco, que neste caso é uma vulnerabilidade do tipo Cross site scripting (XSS). Cross site scripting (XSS) Esta vulnerabilidade está presente no campo calendário da pagina contact_edit.jsf. O campo é um componente de interface fornecido pela biblioteca PrimeFaces. A Listagem 41 mostra os parâmetros da requisição HTTP enviada pela aplicação OWASP ZAP que permitiu à ferramenta diagnosticar a vulnerabilidade. O valor destacado em negrito do parâmetro birthday_input contém o vetor de ataque XSS utilizando a codificação percent encoding.

92 90 POST HTTP/1.1 Host: localhost:8080 Proxy-Connection: keep-alive Referer: Content-length: 260 Cache-Control: max-age=0 Origin: User-Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/ (KHTML, like Gecko) Chrome/ Safari/ Content-Type: application/x-www-form-urlencoded Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Encoding: sdch Accept-Language: pt-br,pt;q=0.8,en-us;q=0.6,en;q=0.4 Accept-Charset: ISO ,utf-8;q=0.7,*;q=0.3 Cookie: JSESSIONID=0A71A1BD5EA0A91A DBAC4180 j_idt19=j_idt19&j_idt22=&name=jose&cpf= &birthday_input=%3cscript %3Ealert%28%22OWASP+ZAP%22%29%3B%3C%2FSCRIPT%3E& =jose%40jose.com&j_idt29_collapsed=false&j_idt41_collapsed=false&javax.faces.ViewState= %3A Listagem 41: Requisição HTTP gerada pelo ZAP Proxy. A Listagem 42 mostra o resumo do código HTML de resposta gerado pela aplicação quando recebe a requisição contida na Listagem 41. Deste modo, podemos observar a presença do script, em destaque, que comprova a existência da vulnerabilidade XSS presente na aplicação. <html> ( ) <tr> <td><label for="birthday" class="text-input"> Aniversário: </label></td> <td><span id="birthday"><input id="birthday_input" name="birthday_input" type="text" value="<script>alert("owasp ZAP");</SCRIPT>" class="ui-inputfield ui-widget ui-state-default ui-corner-all" title="data de aniversário" /></span><script type="text/javascript">jquery(function(){widget_birthday = new PrimeFaces.widget.Calendar('birthday', {popup:true,locale:'pt_br',defaultdate:'<script>alert("owasp ZAP");</SCRIPT>',dateFormat: 'dd/mm/yy',showbuttonpanel:true,changemonth:true,changeyear:true});});</script></td> <td><div id="j_idt37" class="ui-message-error ui-widget ui-corner-all"><span class="ui-message-error-icon"></span><span class="ui-message-error-detail">{0}: Ocorreu um erro de conversão.</span></div></td> </tr> (...) </html> Listagem 42: Resumo da resposta HTTP gerada pela aplicação.

93 91 Como resultado da análise da causa da falha, temos que o componente de interface utilizado na aplicação exemplo não realiza a codificação dos dados de saída de modo correto, permitindo a execução de um script XSS no navegador do usuário. Apesar da aplicação fazer uso do JSF, que possui proteção nativa contra XSS, conforme visto na seção , foi possível observar que ao usar um componente de interface de terceiros uma vulnerabilidade no componente pode afetar a segurança da aplicação como um todo. Em casos semelhantes, é aconselhável realizar testes de segurança nos componentes e implementar métodos de validação/codificação dos dados como medida preventiva, conforme apresentado na seção Password Autocomplete in browser Essa vulnerabilidade ocorre quando o atributo AUTOCOMPLETE está habilitado, permitindo que a senha digitada na tela de login possa ser armazenada no navegador. Essa vulnerabilidade representa um risco baixo e a ferramenta aponta como vulnerabilidade por entender que não é uma boa prática permitir que a senha seja armazenada no navegador do usuário. Vulnerabilidades ignoradas As demais vulnerabilidades ('Cookie set without HttpOnly flag', 'Session ID in URL rewrite', 'Referer expose session ID') serão desconsideradas pelo fato de estarem relacionados com a console administrativa do JBoss, que não fazem parte do escopo da aplicação Resultados dos testes manuais Acesso à página administrativa da aplicação Ao autenticar com o usuário convidado (guest) foi possível observar que a aplicação não restringe o acesso à página contact_edit.jsf. A vulnerabilidade se dá

94 92 pelo fato do desenvolvedor não implementar restrições de acesso às páginas administrativas. Neste caso, a página deveria ser acessada apenas pelo usuário administrador. Esse erro de implementação é bastante comum quando o desenvolvedor acredita que o simples fato de não exibir links para páginas restritas, estará restringindo o acesso às páginas sensíveis. Embora a implementação utilizando o componente apache Shiro possua recursos que permitam configurar a política de controle de acesso às URLs, a aplicação por padrão libera o acesso à todas URLs. Neste caso, seria mais adequado que o framework por padrão restringisse o acesso às URLs e exigisse que o desenvolvedor implemente a configuração da política de acesso às URLs. Neste caso, o controle de acesso da ESAPI pode ser utilizado para auxiliar na implementação desse tipo de restrição. Ação sensível executada por usuário não autorizado A página contact_list.jsp, possui o botão excluir. O botão invoca o método delete() da classe ContactBC.java (contactlist.business.contactbc), que tem o propósito de excluir os contatos selecionados. A causa da falha está relacionada com o fato da página listar todos os contatos cadastrados e por ser utilizada por todos usuários da aplicação, inclusive o administrador que é o único que possui permissão de excluir contatos, então, o botão excluir é exibido para todos os usuários e fica habilitado apenas para usuários com papel administrador. Deste modo, foi possível executar a ação de remoção de um registro de contato através do usuário convidado que não possui permissão de executar a operação. Assim, a ferramenta Firebug foi utilizada para habilitar o botão excluir e invocar a ação indevida de exclusão de um registro de contato. Essa vulnerabilidade ocorreu por que o desenvolvedor utilizou uma forma de renderizar o botão semelhante à que foi apresentada na seção , onde uma chamada de verificação de permissão é realizada apenas para verificar se o botão deve ou não estar habilitado para o usuário. Esse erro comum permite que, caso não haja um controle de acesso ao recurso ou função implementado na aplicação, um usuário malicioso poderá

95 93 simplesmente habilitar um botão que acessa uma funcionalidade crítica e executar a operação sensível invocada pelo botão. Vale destacar que ocultar o botão não resolverá o problema, pois, a requisição gerada pelo botão poderia ser forjada com o uso de ferramentas que geram requisições HTTP semelhante às geradas pelo botão. Deste modo, apesar do Demoiselle Framework possuir recursos que facilitam o controle de acesso através das conforme apresentado na seção , foi possível observar que esta falha ocorreu devido a inexistência do controle implementado pelo desenvolvedor da aplicação, protegendo operações críticas. Portanto, essa vulnerabilidade revela a importância do desenvolvedor fazer o uso correto dos controles de segurança fornecidos pelo framework. Autenticação por força bruta Essa falha ocorre no mecanismo de autenticação, pois, foi possível observar que o componente demoiselle-shiro, utilizado pela aplicação ContactList, não está configurado para limitar a quantidade de tentativas de login na aplicação. Idealmente a aplicação deve possuir algum mecanismo que evita que um atacante possa realizar um processo de tentativa-e-erro para descobrir a senha de um usuário. Deste modo, os mecanismos mais comuns são: uso de CAPTCHAs e bloqueio de conta após um determinado número de tentativas de acesso. Portanto, mesmo que o usuário utilize senhas fortes, um processo de tentativa-e-erro poderia em pouco tempo permitir que a senha de acesso de um determinado usuário seja descoberta pelo atacante Análise dos resultados dos testes Devido o fato do Demoiselle Framework fomentar o uso do JSF na criação dos componentes de interface e o uso do JPA para realizar a persistência dos dados, foi possível observar a inexistência de vulnerabilidades do tipo SQL Injection, enquanto que a única vulnerabilidade XSS encontrada está associada ao uso de um componente de interface de terceiros.

96 94 Além disso, devido o fato do JSF possuir um mecanismo que insere tokens secretos em todas as páginas que contenham formulários, com o propósito de evitar a ocorrência de vulnerabilidades do tipo CSRF, esse tipo de vulnerabilidade também não foi encontrado na aplicação. A tabela a seguir apresenta o correlacionamento das vulnerabilidades encontradas nos testes com o OWASP Top 10. Vulnerabilidade OWASP Top 10 Cross Site Scripting (XSS) A2 Acesso à página administrativa da aplicação A8 Ação sensível executada por usuário não autorizado A4 Autenticação por força bruta A3 Assim, a proposta de melhoria para o Demoiselle Framework seria criar o componente demoiselle-esapi na forma de um módulo que incorpora a biblioteca ESAPI e o AppSensor, com o propósito de prover os controles de segurança da ESAPI e do AppSensor integrados ao framework. A Figura 26 mostra como deve ser o relacionamento do componente com a arquitetura do framework. Figura 26: Visão arquitetural do componente esapi integrado à arquitetura do Demoiselle Framework.

97 95 Portanto, da mesma forma que o componente demoiselle-shiro se integra ao framework, o componente demoiselle-esapi deve ser integrado com o módulo de segurança do core, substituindo os mecanismos de autenticação, controle de acesso e log pelas implementações que integram a ESAPI e o AppSensor no framework.

98 96 4 Integração da ESAPI no Demoiselle Framework A integração da biblioteca ESAPI e do AppSensor no Demoiselle Framework foi construída através da criação de um componente chamado demoiselle-esapi, disponível no repositório google code no endereço: servindo como repositório provisório até que venha a ser aceito e incorporado como versão estável no repositório do projeto Demoiselle junto com os demais componentes. A integração com o AppSensor não requer obrigatoriamente a integração com a biblioteca ESAPI, porém a prévia integração com a ESAPI facilita a integração com o AppSensor. Para prover integração da ESAPI no Demoiselle Framework foi necessário implementar os componentes de autenticação, controle de acesso e registros de log que ao mesmo tempo implementam as interfaces da ESAPI e as interfaces do Demoiselle Framework. As classes essenciais construídas para prover esta integração foram: EsapiWrapperAuthenticator funciona como um wrapper integrador que implementa as interfaces br.gov.frameworkdemoiselle.security.authenticator e org.owasp.esapi.authenticator, permitindo a integração do mecanismo de autenticação da biblioteca ESAPI no Demoiselle Framework. EsapiWrapperAuthorizer funciona como um wrapper integrador que implementa as interfaces br.gov.frameworkdemoiselle.security.authorizer e org.owasp.esapi.accesscontroller, permitindo a integração do mecanismo de controle de acesso da biblioteca ESAPI no Demoiselle Framework.

99 97 EsapiWrapperLogger integra o mecanismo de log do Demoiselle Framework à ESAPI. Para isto, ele herda a classe org.owasp.esapi.reference.log4jlogger (implementação do mecanismo de log padrão da ESAPI) e implementa também a interface org.slf4j.logger, mecanismo padrão de Log utilizado pelo Demoiselle, permitindo a integração dos mecanismos de log padrão da biblioteca ESAPI e do Demoiselle Framework. As seções a seguir apresentam os detalhes das classes EsapiWrapperAuthenticator e EsapiWrapperAuthorizer. 4.1 EsapiWrapperAuthenticator A classe EsapiWrapperAuthenticator implementa as interfaces de autenticação do Demoiselle e da ESAPI, permitindo com isso, a integração dos dois ambientes através de um ponto em comum. A Figura 27 apresenta o diagrama de classes da classe EsapiWrapperAuthenticator: Figura 27: Hierarquia de classes associadas a autenticação.

100 98 A classe EsapiWrapperAuthenticator faz com que as chamadas aos métodos da interface Authenticate do Demoiselle sejam convertidos em chamadas aos métodos da ESAPI. Além da implementação desta classe, foi necessário criar uma classe que representa o usuário da aplicação e integra a interface de usuário da ESAPI e do Demoiselle. Neste caso, a classe criada chama-se BasicUser e implementa as seguintes interfaces: org.owasp.esapi.user br.gov.frameworkdemoiselle.security.user org.owasp.appsensor.asuser A Figura 28 mostra a classe BasicUser e as interfaces que implementa. Figura 28: Hierarquia de classes associadas a definição do usuário no sistema.

101 99 Dessa forma, foi possível integrar as chamadas da interface User do framework Demoiselle, a interface User da ESAPI e a interface ASUser do AppSensor. Os métodos logout() e disable() da interface ASUser do AppSensor (org.owasp.appsensor) são invocados pelo mecanismo de detecção de intrusão do AppSensor para executar ações de resposta de logout do usuário ou bloqueio da conta do usuário, conforme apresentado na Figura EsapiWrapperAuthorizer A classe EsapiWrapperAuthorizer implementa as interfaces de controle de acesso do Demoiselle e da ESAPI, permitindo a integração dos dois ambientes através de um ponto em comum, fazendo com que as chamadas aos métodos hasrole() e haspermission() da interface Authorizer do Demoiselle sejam convertidos em chamadas aos métodos da ESAPI. A Figura 29 mostra as interfaces que a classe EsapiWrapperAuthorizer implementa. Figura 29: Hierarquia de classes associadas ao mecanismo de controle de acessos.

102 100 A construção do mecanismo que integra o controle de acesso do Demoiselle com a ESAPI exigiu a construção de uma nova forma de realizar o controle de acesso, pois o controle de acesso do Demoiselle, conforme visto na seção 2.2.2, utiliza o padrão recurso (resource) e operação (operation), enquanto que a ESAPI possui apenas recursos para realizar o controle de acesso para tipos de dados (classes), URLs, arquivos, funções e serviços, conforme apresentado na seção Como a ESAPI permite estender a funcionalidade de controle de acessos, através da configuração do arquivo ESAPI-AccessControlPolicy.xml presente no mesmo diretório do arquivo de configuração ESAPI.properties, então para realizar o controle de acessos associando recursos e operações às ROLEs dos usuários, foi necessário criar o componente FileBasedACR ( br.gov.demoiselleframework.security.accesscontrol), baseado na classe de mesmo nome presente na biblioteca ESAPI. Essa classe implementa os mecanismos para configurar as permissões de acesso baseadas no arquivo ResourceAccessRules.txt. Desta forma, esse modo de realizar o controle de acessos exige a configuração do arquivo ResourceAccessRules.txt, que deve estar presente no mesmo diretório dos demais arquivos utilizados para configurar os mecanismos de controle de acesso da ESAPI. O exemplo a seguir mostra como o arquivo ResourceAccessRules.txt deve ser configurado para implementar as mesmas configurações de controle de acesso implementadas através do componente demoiselle-shiro na aplicação ContactList: # Resource Access Rules # resource opperation role, role allow/deny coments bookmark * admin allow bookmark visualizar * guest allow * admin allow Listagem 43: Exemplo de configuração do arquivo ResourceAccessRules.txt EsapiWrapperLogger

103 101 A classe EsapiWrapperLogger implementa as interfaces de Log do Demoiselle e da ESAPI, permitindo a integração dos dois ambientes através de um ponto em comum, fazendo com que as chamadas aos métodos da interface Logger (org.slf4j.logger) utilizado pelo Demoiselle sejam convertidos em chamadas aos métodos da interface Logger (org.owasp.esapi.logger) da ESAPI. A Figura 30 mostra o diagrama de classes da classe EsapiWrapperLogger: Figura 30: Hierarquia de classes associadas a logging Integração dos componentes na biblioteca ESAPI Para substituir os componentes padrão fornecidos pela ESAPI com as classes de integração, basta realizar a configuração do arquivo ESAPI.properties associando as referências que substituem o mecanismo padrão de Controle de Acesso, Autenticação e Log com as classes que integram as chamadas do Demoiselle à ESAPI. Neste caso, além dos mecanismos de controle de acessos, autenticação e log, temos a substituição do Detector de Intrusão padrão substituído pelo AppSensor a fim de permitir os benefícios de seu uso no Demoiselle Framework.

Boas Práticas de Desenvolvimento Seguro

Boas Práticas de Desenvolvimento Seguro Boas Práticas de Desenvolvimento Seguro Julho / 2.012 Histórico de Revisões Data Versão Descrição Autor 29/07/2012 1.0 Versão inicial Ricardo Kiyoshi Página 2 de 11 Conteúdo 1. SEGURANÇA DA INFORMAÇÃO

Leia mais

Top Ten OWASP. Fausto Levandoski 1. Curso Tecnólogo em Segurança da Informação Av. Unisinos, 950 93.022-000 São Leopoldo RS Brasil. farole@gmail.

Top Ten OWASP. Fausto Levandoski 1. Curso Tecnólogo em Segurança da Informação Av. Unisinos, 950 93.022-000 São Leopoldo RS Brasil. farole@gmail. Top Ten OWASP Fausto Levandoski 1 1 Universidade do Vale do Rios dos Sinos (UNISINOS) Curso Tecnólogo em Segurança da Informação Av. Unisinos, 950 93.022-000 São Leopoldo RS Brasil farole@gmail.com Abstract.

Leia mais

Biblioteca de segurança para tratar as principais vulnerabilidades web

Biblioteca de segurança para tratar as principais vulnerabilidades web Biblioteca de segurança para tratar as principais vulnerabilidades web Tarcizio Vieira Neto DIOPE/COGSI/SISEC/SIDES Líder em soluções de TI para governo Apresentação pessoal Tarcizio Vieira Neto 4 anos

Leia mais

Desenvolvimento e disponibilização de Conteúdos para a Internet

Desenvolvimento e disponibilização de Conteúdos para a Internet Desenvolvimento e disponibilização de Conteúdos para a Internet Por Matheus Orion OWASP A Open Web Application Security Project (OWASP) é uma entidade sem fins lucrativos e de reconhecimento internacional,

Leia mais

jshield Uma Proposta para Segurança de Aplicações Web

jshield Uma Proposta para Segurança de Aplicações Web jshield Uma Proposta para Segurança de Aplicações Web Márcio A. Macêdo¹, Ricardo G. Queiroz¹ ¹Centro de Ensino Unificado de Teresina (CEUT) Teresina, PI Brasil. marcioalmeida@ceut.com.br, ricardoqueiroz@ieee.org

Leia mais

Nomes: Questão 1 Vulnerabilidade: SQL Injection (Injeção de SQL):

Nomes: Questão 1 Vulnerabilidade: SQL Injection (Injeção de SQL): Nomes: Questão 1 Vulnerabilidade: SQL Injection (Injeção de SQL): Nos últimos anos uma das vulnerabilidades mais exploradas por usuários mal-intencionados é a injeção de SQL, onde o atacante realiza uma

Leia mais

JSF - Controle de Acesso FERNANDO FREITAS COSTA

JSF - Controle de Acesso FERNANDO FREITAS COSTA JSF - Controle de Acesso FERNANDO FREITAS COSTA ESPECIALISTA EM GESTÃO E DOCÊNCIA UNIVERSITÁRIA JSF Controle de Acesso Antes de iniciarmos este assunto, é importante conhecermos a definição de autenticação

Leia mais

Campus Party 2016 São Paulo, SP 27 de janeiro de 2016

Campus Party 2016 São Paulo, SP 27 de janeiro de 2016 Campus Party 2016 São Paulo, SP 27 de janeiro de 2016 WORKSHOP: Programação segura para WEB Dionathan Nakamura nakamura@cert.br Agenda 14:15 16:00 10-20 min: configuração inicial 30-45 min: parte teórica

Leia mais

Análise de Vulnerabilidades em Aplicações WEB

Análise de Vulnerabilidades em Aplicações WEB Análise de Vulnerabilidades em Aplicações WEB Apresentação Luiz Vieira Construtor 4Linux Analista e Consultor de Segurança 15 anos de experiência em TI Pen-Tester Articulista sobre Segurança de vários

Leia mais

SISTEMA DE WORKFLOW PARA MODELAGEM E EXECUÇÃO DE PROCESSOS DE SOFTWARE. Aluno: Roberto Reinert Orientador: Everaldo A. Grahl

SISTEMA DE WORKFLOW PARA MODELAGEM E EXECUÇÃO DE PROCESSOS DE SOFTWARE. Aluno: Roberto Reinert Orientador: Everaldo A. Grahl SISTEMA DE WORKFLOW PARA MODELAGEM E EXECUÇÃO DE PROCESSOS DE SOFTWARE Aluno: Roberto Reinert Orientador: Everaldo A. Grahl Roteiro de apresentação Introdução Objetivos Fundamentação Teórica Workflow Processo

Leia mais

SIQ GQF Plugin s WEB (Aplicações WEB) Gestão da Qualidade de Fornecedores

SIQ GQF Plugin s WEB (Aplicações WEB) Gestão da Qualidade de Fornecedores SIQ GQF Plugin s WEB (Aplicações WEB) Gestão da Qualidade de Fornecedores Requerimentos do Software Versão para Microsoft Windows/Unix Dezembro 2006 Bem-Vindo ao to SIQ GQF Plugin s WEB - Gestão da Qualidade

Leia mais

Projeto Demoiselle. Para perguntas e respostas, utilizem a lista de discussões de usuários da comunidade: demoiselle-users@lists.sourceforge.

Projeto Demoiselle. Para perguntas e respostas, utilizem a lista de discussões de usuários da comunidade: demoiselle-users@lists.sourceforge. Projeto Demoiselle Para perguntas e respostas, utilizem a lista de discussões de usuários da comunidade: demoiselle-users@lists.sourceforge.net Palestrantes: Antônio Carlos Tiboni Luciana Campos Mota 20/07/2009

Leia mais

Prof. Roberto Franciscatto 4º Semestre - TSI - CAFW. Free Powerpoint Templates Page 1

Prof. Roberto Franciscatto 4º Semestre - TSI - CAFW. Free Powerpoint Templates Page 1 Segurança na Web Capítulo 9: Segurança em Aplicações Web Prof. Roberto Franciscatto 4º Semestre - TSI - CAFW Page 1 Introdução Quando se fala em segurança na WEB é preciso pensar inicialmente em duas frentes:

Leia mais

UM ESTUDO SOBRE ARQUITETURA PARA DESENVOLVIMENTO DE SOFTWARE WEB UTILIZANDO NOVAS TECNOLOGIAS

UM ESTUDO SOBRE ARQUITETURA PARA DESENVOLVIMENTO DE SOFTWARE WEB UTILIZANDO NOVAS TECNOLOGIAS UM ESTUDO SOBRE ARQUITETURA PARA DESENVOLVIMENTO DE SOFTWARE WEB UTILIZANDO NOVAS TECNOLOGIAS Edi Carlos Siniciato ¹, William Magalhães¹ ¹ Universidade Paranaense (Unipar) Paranavaí PR Brasil edysiniciato@gmail.com,

Leia mais

PRODUTO 1 (CONSTRUÇÃO DE PORTAL WEB)

PRODUTO 1 (CONSTRUÇÃO DE PORTAL WEB) RELATÓRIO DE ENTREGA DO PRODUTO 1 (CONSTRUÇÃO DE PORTAL WEB) PARA A ELABORAÇÃO DOS PLANOS MUNICIPAIS DE GESTÃO INTEGRADA DE RESÍDUOS SÓLIDOS PMGIRS PARA OS MUNICÍPIOS DE NOVO HORIZONTE, JUPIÁ, GALVÃO,

Leia mais

Segurança em aplicações web: pequenas ideias, grandes resultados Prof. Alex Camargo alexcamargoweb@gmail.com

Segurança em aplicações web: pequenas ideias, grandes resultados Prof. Alex Camargo alexcamargoweb@gmail.com UNIVERSIDADE FEDERAL DO PAMPA CAMPUS BAGÉ ENGENHARIA DE COMPUTAÇÃO Segurança em aplicações web: pequenas ideias, grandes resultados alexcamargoweb@gmail.com Sobre o professor Formação acadêmica: Bacharel

Leia mais

Associação Carioca de Ensino Superior Centro Universitário Carioca

Associação Carioca de Ensino Superior Centro Universitário Carioca Desenvolvimento de Aplicações Web Lista de Exercícios Métodos HTTP 1. No tocante ao protocolo de transferência de hipertexto (HTTP), esse protocolo da categoria "solicitação e resposta" possui três métodos

Leia mais

Projeto: Simul-e Documento de Arquitetura de Software

Projeto: Simul-e Documento de Arquitetura de Software Projeto: Simul-e Documento de Arquitetura de Software Versão 1.0 Página 1 de 9 Histórico da Revisão Data Versão Descrição Autor 12.09.2015 1.0 Criação do Documento Hugo Pazolline 20.10.2015 1.0 Atualização

Leia mais

ABORDAGEM DE FRAMEWORKS PARA JSF QUE AUXILIAM O DESENVOLVIMENTO DE SOFTWARE

ABORDAGEM DE FRAMEWORKS PARA JSF QUE AUXILIAM O DESENVOLVIMENTO DE SOFTWARE ABORDAGEM DE FRAMEWORKS PARA JSF QUE AUXILIAM O DESENVOLVIMENTO DE SOFTWARE Amarildo Aparecido Ferreira Junior 1, Ricardo Ribeiro Rufino 1 ¹Universidade Paranaense (Unipar) Paranavaí PR Brasil aapfjr@gmail.com

Leia mais

Documento de Arquitetura

Documento de Arquitetura Documento de Arquitetura A2MEPonto - SISTEMA DE PONTO ELETRÔNICO A2MEPonto - SISTEMA DE PONTO ELETRÔNICO #1 Pág. 1 de 11 HISTÓRICO DE REVISÕES Data Versão Descrição Autor 28/10/2010 1 Elaboração do documento

Leia mais

Recomendações de Segurança para Desenvolvimento de Aplicações Web

Recomendações de Segurança para Desenvolvimento de Aplicações Web Recomendações de Segurança para Desenvolvimento de Aplicações Web Índice 1. INTRODUÇÃO...3 1.1 CONTROLE DE VERSÃO...3 1.2 OBJETIVO...3 1.3 PÚBLICO - ALVO...4 2 VULNERABILIDADES COMUNS...4 2.1 INJEÇÃO DE

Leia mais

Segurança no Desenvolvimento de Aplicações Web. Security in Web Applications Development

Segurança no Desenvolvimento de Aplicações Web. Security in Web Applications Development Segurança no Desenvolvimento de Aplicações Web Security in Web Applications Development Jonas Alves de Oliveira 1 Leonardo Luiz Teodoro Campos 2 Cristiano Antônio Rocha Silveira Diniz 3 Resumo: Este artigo

Leia mais

PROJETO DE COOPERAÇÃO TÉCNICA INTERNACIONAL. Diretrizes e Estratégias para Ciência, Tecnologia e Inovação no Brasil

PROJETO DE COOPERAÇÃO TÉCNICA INTERNACIONAL. Diretrizes e Estratégias para Ciência, Tecnologia e Inovação no Brasil PROJETO DE COOPERAÇÃO TÉCNICA INTERNACIONAL Diretrizes e Estratégias para Ciência, Tecnologia e Inovação no Brasil Projeto 914 BRA5065 - PRODOC-MTC/UNESCO DOCUMENTO TÉCNICO Nº 02 IMPLANTAÇÃO DE 1 (UM)

Leia mais

ESPECIFICAÇÃO E INTEGRAÇÃO

ESPECIFICAÇÃO E INTEGRAÇÃO \ Sistema Integrado de Gestão de Administrativa - White Paper - ESPECIFICAÇÃO E INTEGRAÇÃO Controle de Versão Versão Responsabilidade Início de elaboração Final de elaboração Atividade 0.01 Renato Crivano

Leia mais

Programação Orientada a Objetos com PHP & MySQL Cookies e Sessões. Prof. MSc. Hugo Souza

Programação Orientada a Objetos com PHP & MySQL Cookies e Sessões. Prof. MSc. Hugo Souza Programação Orientada a Objetos com PHP & MySQL Cookies e Sessões Prof. MSc. Hugo Souza Se você precisar manter informações sobre seus usuários enquanto eles navegam pelo seu site, ou até quando eles saem

Leia mais

O atacante pode roubar a sessão de um usuário legítimo do sistema, que esteja previamente autenticado e realizar operações que o mesmo poderia.

O atacante pode roubar a sessão de um usuário legítimo do sistema, que esteja previamente autenticado e realizar operações que o mesmo poderia. Explorando e tratando a falha de Cross-site-scripting (XSS) 1 D E D E Z E M B R O D E 2 0 1 5 Muito pouco falada e com alto nível crítico dentro das vulnerabilidades relatadas, o Cross-site-scripting (XSS)

Leia mais

Criando Aplicações PHP com. Zend e Dojo. Flávio Gomes da Silva Lisboa. Novatec

Criando Aplicações PHP com. Zend e Dojo. Flávio Gomes da Silva Lisboa. Novatec Criando Aplicações PHP com Zend e Dojo Flávio Gomes da Silva Lisboa Novatec Copyright 2013 da Novatec Editora Ltda. Todos os direitos reservados e protegidos pela Lei 9.610 de 19/02/1998. É proibida a

Leia mais

soluções transversais SOLUÇÕES segurança

soluções transversais SOLUÇÕES segurança soluções transversais SOLUÇÕES segurança RESUMO DA SOLUÇÃO single sign-on acessos prevenção autenticação Os serviços de segurança são implementados como um layer do tipo Black Box, utilizável pelos canais

Leia mais

Aplicativo web para definição do modelo lógico no projeto de banco de dados relacional

Aplicativo web para definição do modelo lógico no projeto de banco de dados relacional Aplicativo web para definição do modelo lógico no projeto de banco de dados relacional Juarez Bachmann Orientador: Alexander Roberto Valdameri Roteiro Introdução Objetivos Fundamentação teórica Desenvolvimento

Leia mais

Conviso Security Training Ementa dos Treinamentos

Conviso Security Training Ementa dos Treinamentos Escritório Central Rua Marechal Hermes 678 CJ 32 CEP 80530-230, Curitiba, PR T (41) 3095.3986 www.conviso.com.br Conviso Security Training Ementa dos Treinamentos Apresentação Sobre este Documento Este

Leia mais

Segurança da Informação

Segurança da Informação Segurança da Informação Segurança e Vulnerabilidades em Aplicações Web jobona@terra.com.br Definição: Segurança Segundo o dicionário da Wikipédia, o termo segurança significa: 1. Condição ou estado de

Leia mais

OWASP. Ferramentas & Tecnologias OWASP. The OWASP Foundation http://www.owasp.org. Joaquim Marques OWASP@PT. 2 Abril, 2009

OWASP. Ferramentas & Tecnologias OWASP. The OWASP Foundation http://www.owasp.org. Joaquim Marques OWASP@PT. 2 Abril, 2009 OWASP Ferramentas & Tecnologias Joaquim Marques OWASP@PT OWASP 2 Abril, 2009 Copyright 2007 - The OWASP Foundation This work is available under the Creative Commons SA 2.5 license The OWASP Foundation

Leia mais

3 Um Framework Orientado a Aspectos para Monitoramento e Análise de Processos de Negócio

3 Um Framework Orientado a Aspectos para Monitoramento e Análise de Processos de Negócio 32 3 Um Framework Orientado a Aspectos para Monitoramento e Análise de Processos de Negócio Este capítulo apresenta o framework orientado a aspectos para monitoramento e análise de processos de negócio

Leia mais

Aula 03 - Projeto Java Web

Aula 03 - Projeto Java Web Aula 03 - Projeto Java Web Para criação de um projeto java web, vá em File/New. Escolha o projeto: Em seguida, na caixa Categorias selecione Java Web. Feito isso, na caixa à direita selecione Aplicação

Leia mais

Geração e execução de scripts de teste em aplicações web a partir de casos de uso direcionados por comportamento 64

Geração e execução de scripts de teste em aplicações web a partir de casos de uso direcionados por comportamento 64 direcionados por comportamento 64 5 Estudo de caso Neste capítulo serão apresentadas as aplicações web utilizadas na aplicação da abordagem proposta, bem como a tecnologia em que foram desenvolvidas, o

Leia mais

ARQUITETURA DO SISTEMA ERP PEGASUS

ARQUITETURA DO SISTEMA ERP PEGASUS ARQUITETURA DO SISTEMA ERP PEGASUS Elaborado por: Bruno Duarte Nogueira Arquiteto de Software Data: 05/03/2012 1 Sumário 1. Introdução... 3 2. Tecnologias... 3 2.1. Web Tier... 3 2.1.1. Facelets 1.1.14...

Leia mais

PROJETO PEDAGÓGICO DE CURSOS

PROJETO PEDAGÓGICO DE CURSOS 1 de 6 PROJETO PEDAGÓGICO DE CURSOS BURITREINAMENTOS MANAUS-AM NOVEMBRO / 2014 2 de 6 PACOTES DE TREINAMENTOS BURITECH A Buritech desenvolveu um grupo de pacotes de treinamentos, aqui chamados de BuriPacks,

Leia mais

PROJETO PEDAGÓGICO DE CURSOS

PROJETO PEDAGÓGICO DE CURSOS 1 de 6 PROJETO PEDAGÓGICO DE CURSOS BURITREINAMENTOS MANAUS-AM MARÇO / 2015 2 de 6 PACOTES DE TREINAMENTOS BURITECH A Buritech desenvolveu um grupo de pacotes de treinamentos, aqui chamados de BuriPacks,

Leia mais

SISTEMA DE GESTÃO DE PRODUÇÃO DE EVENTOS

SISTEMA DE GESTÃO DE PRODUÇÃO DE EVENTOS SISTEMA DE GESTÃO DE PRODUÇÃO DE EVENTOS Rodrigo das Neves Wagner Luiz Gustavo Galves Mählmann Resumo: O presente artigo trata de um projeto de desenvolvimento de uma aplicação para uma produtora de eventos,

Leia mais

Essencial ao Desenvolvimento de Software

Essencial ao Desenvolvimento de Software Documento de Requisitos Essencial ao Desenvolvimento de Software De que se trata o artigo? Apresenta o documento de requisitos de software, destacando-o como um dos principais documentos pertinentes ao

Leia mais

Curso de Aprendizado Industrial Desenvolvedor WEB

Curso de Aprendizado Industrial Desenvolvedor WEB Curso de Aprendizado Industrial Desenvolvedor WEB Disciplina: Programação Orientada a Objetos II Professor: Cheli dos S. Mendes da Costa Modelo Cliente- Servidor Modelo de Aplicação Cliente-servidor Os

Leia mais

Segurança em Web Aula 1

Segurança em Web Aula 1 Open Web Application Security Project Segurança em Web Aula 1 Maycon Maia Vitali ( 0ut0fBound ) maycon@hacknroll.com Hack n Roll Centro Universitário Vila Velha Agenda Sobre o Instrutor Objetivos do Curso

Leia mais

Documento de Análise e Projeto VideoSystem

Documento de Análise e Projeto VideoSystem Documento de Análise e Projeto VideoSystem Versão Data Versão Descrição Autor 20/10/2009 1.0 21/10/2009 1.0 05/11/2009 1.1 Definição inicial do documento de análise e projeto Revisão do documento

Leia mais

Ferramenta: Spider-CL. Manual do Usuário. Versão da Ferramenta: 1.1. www.ufpa.br/spider

Ferramenta: Spider-CL. Manual do Usuário. Versão da Ferramenta: 1.1. www.ufpa.br/spider Ferramenta: Spider-CL Manual do Usuário Versão da Ferramenta: 1.1 www.ufpa.br/spider Histórico de Revisões Data Versão Descrição Autor 14/07/2009 1.0 15/07/2009 1.1 16/07/2009 1.2 20/05/2010 1.3 Preenchimento

Leia mais

INDICE 3.APLICAÇÕES QUE PODEM SER DESENVOLVIDAS COM O USO DO SAXES

INDICE 3.APLICAÇÕES QUE PODEM SER DESENVOLVIDAS COM O USO DO SAXES w w w. i d e a l o g i c. c o m. b r INDICE 1.APRESENTAÇÃO 2.ESPECIFICAÇÃO DOS RECURSOS DO SOFTWARE SAXES 2.1. Funcionalidades comuns a outras ferramentas similares 2.2. Funcionalidades próprias do software

Leia mais

VULNERABILIDADES WEB v.2.2

VULNERABILIDADES WEB v.2.2 VULNERABILIDADES WEB v.2.2 $ whoami Sgt NILSON Sangy Computer Hacking Forensic Investigator Analista de Segurança da Informação Guerreiro Cibernético $ ls -l /etc 1. Contextualização 2. OWASP 2.1. Injeção

Leia mais

Um Framework MVC para. Aplicações em Java utilizando Swing.

Um Framework MVC para. Aplicações em Java utilizando Swing. Um Framework MVC para Aplicações em Java utilizando Swing. Alessandro Lemser Curso de Ciência da Computação Universidade do Vale do Itajaí Campus São José São José, SC 88115-100, Brasil alemser@brturbo.com

Leia mais

Use a Cabeça! FREEMAN, Eric e Elisabeth. HTML com CSS e XHTML BASHMAN, Brian / SIERRA Kathy / BATES, Bert. Servlets & JSP

Use a Cabeça! FREEMAN, Eric e Elisabeth. HTML com CSS e XHTML BASHMAN, Brian / SIERRA Kathy / BATES, Bert. Servlets & JSP Use a Cabeça! FREEMAN, Eric e Elisabeth. HTML com CSS e XHTML BASHMAN, Brian / SIERRA Kathy / BATES, Bert. Servlets & JSP Software cliente: browser e outros Protocolo HTTP Infraestrutura de transporte

Leia mais

ANEXO 11. Framework é um conjunto de classes que colaboram para realizar uma responsabilidade para um domínio de um subsistema da aplicação.

ANEXO 11. Framework é um conjunto de classes que colaboram para realizar uma responsabilidade para um domínio de um subsistema da aplicação. ANEXO 11 O MATRIZ Para o desenvolvimento de sites, objeto deste edital, a empresa contratada obrigatoriamente utilizará o framework MATRIZ desenvolvido pela PROCERGS e disponibilizado no início do trabalho.

Leia mais

Segurança em Web Aula 2

Segurança em Web Aula 2 Open Web Application Security Project Segurança em Web Aula 2 Maycon Maia Vitali ( 0ut0fBound ) maycon@hacknroll.com Hack n Roll Centro Universitário Vila Velha Agenda Revisão da Última Aula SQL Injection

Leia mais

SISTEMA DE AGENDAMENTO E GERENCIAMENTO DE CONSULTAS CLÍNICAS

SISTEMA DE AGENDAMENTO E GERENCIAMENTO DE CONSULTAS CLÍNICAS SISTEMA DE AGENDAMENTO E GERENCIAMENTO DE CONSULTAS CLÍNICAS Pablo dos Santos Alves Alexander Roberto Valdameri - Orientador Roteiro da apresentação Introdução Objetivos Motivação Revisão bibliográfica

Leia mais

Pen-test de Aplicações Web: Técnicas e Ferramentas

Pen-test de Aplicações Web: Técnicas e Ferramentas Divisão de Informática - DINF MJ Departamento de Polícia Federal Pen-test de Aplicações Web: Técnicas e Ferramentas Ivo de Carvalho Peixinho Perito Criminal Federal Agenda 1. Introdução 2. Ferramentas

Leia mais

Demoiselle Tutorial Módulo 1 Arquitetura

Demoiselle Tutorial Módulo 1 Arquitetura Demoiselle Tutorial Módulo 1 Arquitetura Vanderson Botelho da Silva (SERPRO/SUPST/STCTA) Emerson Sachio Saito (SERPRO/CETEC/CTCTA) Flávio Gomes da Silva Lisboa (SERPRO/CETEC/CTCTA) Serge Normando Rehem

Leia mais

10 maiores riscos em aplicações Web

10 maiores riscos em aplicações Web 10 maiores riscos em aplicações Web Leandro Silva dos Santos Thiago Stuckert leandrosantos@inbrax.com thiago.melo.stuckert@gmail.com.br Novembro - 2010 1 Open Web Application Security Project (OWASP) Organização

Leia mais

4 O Workflow e a Máquina de Regras

4 O Workflow e a Máquina de Regras 4 O Workflow e a Máquina de Regras O objetivo do workflow e da máquina de regras é definir um conjunto de passos e regras configuráveis. Ao longo de sua execução, um usuário consegue simplificar o seu

Leia mais

DESENVOLVIMENTO COM JAVA EE E SUAS ESPECIFICAÇÕES

DESENVOLVIMENTO COM JAVA EE E SUAS ESPECIFICAÇÕES DESENVOLVIMENTO COM JAVA EE E SUAS ESPECIFICAÇÕES Hugo Henrique Rodrigues Correa¹, Jaime Willian Dias 1 Universidade Paranaense (Unipar) Paranavaí PR Brasil hugohrcorrea@gmail.com, jaime@unipar.br Resumo.

Leia mais

Padrões de Contagem de Pontos de Função

Padrões de Contagem de Pontos de Função Padrões de Contagem de Pontos de Função Contexto Versão: 1.0.0 Objetivo O propósito deste documento é apresentar os padrões estabelecidos para utilização da técnica de Análise de Pontos de Função no ambiente

Leia mais

Fonte: http://www.online-security-solution.com/ - Illustration by Gaich Muramatsu

Fonte: http://www.online-security-solution.com/ - Illustration by Gaich Muramatsu Fonte: http://www.online-security-solution.com/ - Illustration by Gaich Muramatsu Prof. Hederson Velasco Ramos Uma boa maneira de analisar ameaças no nível dos aplicativo é organiza las por categoria de

Leia mais

Segurança em Aplicações Web Metodologia OWASP

Segurança em Aplicações Web Metodologia OWASP Segurança em Aplicações Web Metodologia OWASP Weekly Seminar Lucas Vinícius da Rosa Laboratório de Segurança em Computação () Universidade Federal de Santa Catarina (UFSC) lvrosa@inf.ufsc.br 2012 Sumário

Leia mais

CURSO DESENVOLVEDOR JAVA WEB E FLEX Setembro de 2010 à Janeiro de 2011

CURSO DESENVOLVEDOR JAVA WEB E FLEX Setembro de 2010 à Janeiro de 2011 CURSO DESENVOLVEDOR JAVA WEB E FLEX Setembro de 2010 à Janeiro de 2011 O curso foi especialmente planejado para os profissionais que desejam trabalhar com desenvolvimento de sistemas seguindo o paradigma

Leia mais

CURSO DESENVOLVEDOR JAVA Edição 2009

CURSO DESENVOLVEDOR JAVA Edição 2009 CURSO DESENVOLVEDOR JAVA Edição 2009 O curso foi especialmente planejado para os profissionais que desejam trabalhar com desenvolvimento de sistemas seguindo o paradigma Orientado a Objetos e com o uso

Leia mais

Segurança no Desenvolvimento, Implantação e Operação de Sistemas de Informação Baseado na ISO 15408

Segurança no Desenvolvimento, Implantação e Operação de Sistemas de Informação Baseado na ISO 15408 Segurança no Desenvolvimento, Implantação e Operação de Sistemas de Informação Baseado na ISO 15408 Palestrante: Alexandre Sieira, CISSP Autores: Alexandre Correia Pinto, CISSP Alexandre Sieira, CISSP

Leia mais

SELinux. Security Enhanced Linux

SELinux. Security Enhanced Linux SELinux Security Enhanced Linux Segurança da Informação A segurança da informação é um conjunto de medidas que se constituem basicamente de controles e política de segurança Objetivando a proteção das

Leia mais

Curso - Padrões de Projeto Módulo 5: Model-View- Controller

Curso - Padrões de Projeto Módulo 5: Model-View- Controller Curso - Padrões de Projeto Módulo 5: Model-View- Controller Vítor E. Silva Souza vitorsouza@gmail.com http://www.javablogs.com.br/page/engenho http://esjug.dev.java.net Sobre o Instrutor Formação: Java:

Leia mais

DESENVOLVENDO APLICAÇÃO UTILIZANDO JAVA SERVER FACES

DESENVOLVENDO APLICAÇÃO UTILIZANDO JAVA SERVER FACES DESENVOLVENDO APLICAÇÃO UTILIZANDO JAVA SERVER FACES Alexandre Egleilton Araújo, Jaime Willian Dias Universidade Paranaense (Unipar) Paranavaí PR Brasil araujo.ale01@gmail.com, jaime@unipar.br Resumo.

Leia mais

Projeto Arquitetural do IEmbedded

Projeto Arquitetural do IEmbedded Universidade Federal de Campina Grande Centro de Engenharia Elétrica e Informática Departamento de Sistemas e Computação Disciplina: Projeto I Professora: Francilene Garcia Equipe: Carolina Nogueira de

Leia mais

CURSO DESENVOLVEDOR JAVA Edição Intensiva de Férias

CURSO DESENVOLVEDOR JAVA Edição Intensiva de Férias CURSO DESENVOLVEDOR JAVA Edição Intensiva de Férias O curso foi especialmente planejado para os profissionais que desejam trabalhar com desenvolvimento de sistemas seguindo o paradigma Orientado a Objetos

Leia mais

Conceitos de extensões Joomla!

Conceitos de extensões Joomla! capítulo 1 Conceitos de extensões Joomla! Entendendo o que é extensão Extensão pode ser entendida como uma pequena aplicação desenvolvida com regras de construção estabelecidas pelo ambiente Joomla!. É

Leia mais

DESENVOLVIMENTO WEB UTILIZANDO FRAMEWORK PRIMEFACES E OUTRAS TECNOLOGIAS ATUAIS

DESENVOLVIMENTO WEB UTILIZANDO FRAMEWORK PRIMEFACES E OUTRAS TECNOLOGIAS ATUAIS DESENVOLVIMENTO WEB UTILIZANDO FRAMEWORK PRIMEFACES E OUTRAS TECNOLOGIAS ATUAIS Emanuel M. Godoy 1, Ricardo Ribeiro Rufino 1 1 Universidade Paranaense (Unipar) Paranavaí PR Brasil godoymanel@gmail.com,

Leia mais

Suplemento de Informações: Esclarecimento de Firewalls de Aplicativos e Revisões do Código do Requisito 6.6

Suplemento de Informações: Esclarecimento de Firewalls de Aplicativos e Revisões do Código do Requisito 6.6 Padrão: Padrão de Segurança de Dados (DSS) Requisito: 6.6 Data: Fevereiro de 2008 Suplemento de Informações: Esclarecimento de Firewalls de Aplicativos e Revisões do Código do Requisito 6.6 Data de liberação:

Leia mais

J550 Segurança e Controle de erros

J550 Segurança e Controle de erros J550 Segurança e Controle de erros Helder da Rocha (helder@acm.org) www.argonavis.com.br 1 Assuntos abordados Este módulo trata de dois assuntos Como mapear erros HTTP e exceções Java a servlets ou páginas

Leia mais

1 SQL Injection A consulta normal SQL seria:

1 SQL Injection A consulta normal SQL seria: HTTP Testando aplicação Web. Pegaremos dois tipos de ataques dentre os top 10 do OWASP 1 SQL Injection A consulta normal SQL seria: SELECT * FROM Users WHERE Username='$username' AND Password='$password'

Leia mais

Programando em PHP. Conceitos Básicos

Programando em PHP. Conceitos Básicos Programando em PHP www.guilhermepontes.eti.br lgapontes@gmail.com Conceitos Básicos Todo o escopo deste estudo estará voltado para a criação de sites com o uso dos diversos recursos de programação web

Leia mais

Troubleshooting Versão 1.0

Troubleshooting Versão 1.0 Troubleshooting Versão 1.0 As informações contidas neste documento estão sujeitas a alteração sem notificação prévia. Os dados utilizados nos exemplos contidos neste manual são fictícios. Nenhuma parte

Leia mais

Desenvolvendo Aplicações Web com NetBeans

Desenvolvendo Aplicações Web com NetBeans Desenvolvendo Aplicações Web com NetBeans Aula 3 Cap. 4 Trabalhando com Banco de Dados Prof.: Marcelo Ferreira Ortega Introdução O trabalho com banco de dados utilizando o NetBeans se desenvolveu ao longo

Leia mais

Segurança da Internet. Ricardo Terra (rterrabh [at] gmail.com) Segurança da Internet Outubro, 2013 2012 1

Segurança da Internet. Ricardo Terra (rterrabh [at] gmail.com) Segurança da Internet Outubro, 2013 2012 1 Segurança da Internet Ricardo Terra rterrabh [at] gmail.com Outubro, 2013 2012 1 CV Nome: Ricardo Terra Email: rterrabh [at] gmail.com www: ricardoterra.com.br Twitter: rterrabh Lattes: lattes.cnpq.br/

Leia mais

segurança em aplicações web

segurança em aplicações web segurança em aplicações web myke hamada mykesh gmail 1 whoami ciência da computação segurança da informação ruby rails c# vbscript opensource microsoft ethical hacking 2 agenda introdução ontem e

Leia mais

WebApps em Java com uso de Frameworks

WebApps em Java com uso de Frameworks WebApps em Java com uso de Frameworks Fred Lopes Índice O que são frameworks? Arquitetura em camadas Arquitetura de sistemas WEB (WebApps) Listagem resumida de frameworks Java Hibernate O que são frameworks?

Leia mais

Ambiente Web PHP Problemas Frameworks CakePHP Symfony Zend Framework Prado CodeIgniter Demonstração O livro

Ambiente Web PHP Problemas Frameworks CakePHP Symfony Zend Framework Prado CodeIgniter Demonstração O livro Desenvolvimento em PHP usando Frameworks Elton Luís Minetto Agenda Ambiente Web PHP Problemas Frameworks CakePHP Symfony Zend Framework Prado CodeIgniter Demonstração O livro Ambiente Web É o ambiente

Leia mais

PODER JUDICIÁRIO. PORTARIA Nº CJF-POR-2015/00104 de 6 de março de 2015

PODER JUDICIÁRIO. PORTARIA Nº CJF-POR-2015/00104 de 6 de março de 2015 PODER JUDICIÁRIO JUSTIÇA FEDERAL CONSELHO DA JUSTIÇA FEDERAL PORTARIA Nº CJF-POR-2015/00104 de 6 de março de 2015 Dispõe sobre a aprovação do documento acessório comum "Política de Segurança para Desenvolvimento,

Leia mais

Engenharia de Software I

Engenharia de Software I Engenharia de Software I Rogério Eduardo Garcia (rogerio@fct.unesp.br) Bacharelado em Ciência da Computação Aula 05 Material preparado por Fernanda Madeiral Delfim Tópicos Aula 5 Contextualização UML Astah

Leia mais

ANEXO 9 DO PROJETO BÁSICO DA FERRAMENTA DE MONITORAMENTO, SEGURANÇA E AUDITORIA DE BANCO DE DADOS

ANEXO 9 DO PROJETO BÁSICO DA FERRAMENTA DE MONITORAMENTO, SEGURANÇA E AUDITORIA DE BANCO DE DADOS ANEXO 9 DO PROJETO BÁSICO DA FERRAMENTA DE MONITORAMENTO, SEGURANÇA E AUDITORIA DE BANCO DE DADOS Sumário 1. Finalidade... 2 2. Justificativa para contratação... 2 3. Premissas para fornecimento e operação

Leia mais

1 Introdução. O sistema permite:

1 Introdução. O sistema permite: A intenção deste documento é demonstrar as possibilidades de aplicação da solução INCA Insite Controle de Acesso - para controle de conexões dia-up ou banda larga à Internet e redes corporativas de forma

Leia mais

Versão 1.0 Janeiro de 2011. Xerox Phaser 3635MFP Plataforma de interface extensível

Versão 1.0 Janeiro de 2011. Xerox Phaser 3635MFP Plataforma de interface extensível Versão 1.0 Janeiro de 2011 Xerox Phaser 3635MFP 2011 Xerox Corporation. XEROX e XEROX e Design são marcas da Xerox Corporation nos Estados Unidos e/ou em outros países. São feitas alterações periodicamente

Leia mais

SIGECO07 Sistema Integrado de Gestão de Contas Universidade Federal de Lavras PLANO DE PROJETO 23/09/2007 SIGECO07/GERENCIA/PROJETOS/

SIGECO07 Sistema Integrado de Gestão de Contas Universidade Federal de Lavras PLANO DE PROJETO 23/09/2007 SIGECO07/GERENCIA/PROJETOS/ SIGECO07 Sistema Integrado de Gestão de Contas Universidade Federal de Lavras PLANO DE PROJETO 23/09/2007 SIGECO07/GERENCIA/PROJETOS/ ModeloPlanoProjeto_2007_04_24 SIGECO07_PlanoProjeto_2007_09_23 Página

Leia mais

Segurança na WEB Ambiente WEB estático

Segurança na WEB Ambiente WEB estático Segurança de Redes Segurança na WEB Prof. Rodrigo Rocha prof.rodrigorocha@yahoo.com Servidor IIS Apache Cliente Browser IE FireFox Ambiente WEB estático 1 Ambiente Web Dinâmico Servidor Web Cliente Navegadores

Leia mais

Instituto de Inovação com TIC. [Junho/ 2009]

Instituto de Inovação com TIC. [Junho/ 2009] Instituto de Inovação com TIC [Junho/ 2009] Segurança em aplicações WEB: A nova fronteira rodrigo.assad@cesar.org.br Redes de Computadores (Histórico) Segurança de Redes (Histórico) Robert Tappan

Leia mais

7 Utilização do Mobile Social Gateway

7 Utilização do Mobile Social Gateway 7 Utilização do Mobile Social Gateway Existem três atores envolvidos na arquitetura do Mobile Social Gateway: desenvolvedor do framework MoSoGw: é o responsável pelo desenvolvimento de novas features,

Leia mais

e-stf WebServices Processo Eletrônico Smart Client Manual de Instalação

e-stf WebServices Processo Eletrônico Smart Client Manual de Instalação SUPREMO TRIBUNAL FEDERAL Secretaria de Tecnologia da Informação e-stf WebServices Processo Eletrônico Smart Client 1 Histórico da Revisão Data Versão Descrição Autor 30/07/2008 1.0 Criação do documento

Leia mais

CA Nimsoft Monitor para servidores

CA Nimsoft Monitor para servidores DOCUMENTAÇÃO TÉCNICA Setembro de 2012 CA Nimsoft Monitor para servidores agility made possible CA Nimsoft para monitoramento de servidores sumário CA Nimsoft Monitor para servidores 3 visão geral da solução

Leia mais

Universidade Federal de Goiás Centro de Recursos Computacionais - CERCOMP Divisão de Sistemas. Criação de uma Serviço de Geração de Relatórios

Universidade Federal de Goiás Centro de Recursos Computacionais - CERCOMP Divisão de Sistemas. Criação de uma Serviço de Geração de Relatórios Universidade Federal de Goiás Centro de Recursos Computacionais - CERCOMP Divisão de Sistemas Criação de uma Serviço de Geração de Relatórios Goiânia 12/2011 Versionamento 12/12/2011 Hugo Marciano... 1.0

Leia mais

Proposta de pentest. O pentest realizado vai desde ataques aos servidores até testes na programação das aplicações com tentativas reais de invasão;

Proposta de pentest. O pentest realizado vai desde ataques aos servidores até testes na programação das aplicações com tentativas reais de invasão; initsec Proposta de pentest 1. O que é? Pentest (Penetration Test) é uma avaliação de maneira realista da segurança empregada em aplicações web e infraestruturas de TI no geral. O Pentest constitui da

Leia mais

CONTRA CONTROLE DE ACESSOS E MODULARIZADOR DE SISTEMAS

CONTRA CONTROLE DE ACESSOS E MODULARIZADOR DE SISTEMAS MINISTÉRIO DO DESENVOLVIMENTO AGRÁRIO SUBSECRETARIA DE PLANEJAMENTO, ORÇAMENTO E ADMINISTRAÇÃO COORDENAÇÃO-GERAL DE MODERNIZAÇÃO E INFORMÁTICA CONTRA CONTROLE DE ACESSOS E MODULARIZADOR DE SISTEMAS MANUAL

Leia mais

Produto: Webscan Relatório II Programas desenvolvidos, testados e documentados

Produto: Webscan Relatório II Programas desenvolvidos, testados e documentados Produto: Webscan Relatório II Programas desenvolvidos, testados e documentados Sérgio Oliveira Campos Contrato N : 2008/000514 Sumário 1 Introdução 1 2 Bibliotecas Utilizadas 2 2.1 Reconhecimento de Texto

Leia mais

Ambiente Web PHP Problemas Frameworks CakePHP Symfony Zend Framework Prado CodeIgniter Demonstração

Ambiente Web PHP Problemas Frameworks CakePHP Symfony Zend Framework Prado CodeIgniter Demonstração Desenvolvimento em PHP usando Frameworks Elton Luís Minetto Agenda Ambiente Web PHP Problemas Frameworks CakePHP Symfony Zend Framework Prado CodeIgniter Demonstração Ambiente Web É o ambiente formado

Leia mais

Cartilha de Desenvolvimento Seguro

Cartilha de Desenvolvimento Seguro Cartilha de Desenvolvimento Seguro Alexandre Vargas Amador e Fausto Levandoski¹ 1 Universidade do Vale do Rios dos Sinos (UNISINOS) Curso Tecnólogo em Segurança da Informação Av. Unisinos, 950 93.022-000

Leia mais

World Wide Web e Aplicações

World Wide Web e Aplicações World Wide Web e Aplicações Módulo H O que é a WWW Permite a criação, manipulação e recuperação de informações Padrão de fato para navegação, publicação de informações e execução de transações na Internet

Leia mais

MANUAL PARA USO DO SISTEMA GCO Gerenciador Clínico Odontológico

MANUAL PARA USO DO SISTEMA GCO Gerenciador Clínico Odontológico MANUAL PARA USO DO SISTEMA GCO Gerenciador Clínico Odontológico O GCO é um sistema de controle de clínicas odontológicas, onde dentistas terão acesso a agendas, fichas de pacientes, controle de estoque,

Leia mais

DOCUMENTAÇÃO DO FRAMEWORK - versão 2.0

DOCUMENTAÇÃO DO FRAMEWORK - versão 2.0 DOCUMENTAÇÃO DO FRAMEWORK - versão 2.0 Índice 1 - Objetivo 2 - Descrição do ambiente 2.1. Tecnologias utilizadas 2.2. Estrutura de pastas 2.3. Bibliotecas já incluídas 3 - Características gerais 4 - Criando

Leia mais

OWASP. The OWASP Foundation http://www.owasp.org. As 10 mais críticas vulnerabilidades de segurança em Aplicações Web

OWASP. The OWASP Foundation http://www.owasp.org. As 10 mais críticas vulnerabilidades de segurança em Aplicações Web As 10 mais críticas vulnerabilidades de segurança em Aplicações Web Carlos Serrão Portugal ISCTE/DCTI/Adetti/NetMuST Abril, 2009 carlos.serrao@iscte.pt carlos.j.serrao@gmail.com Copyright 2004 - The Foundation

Leia mais