Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Java security

1.339 Aufrufe

Veröffentlicht am

Palestra apresentada para a turma de pós-graduação em Arquitetura de Sistemas - Instituto Infnet.

Veröffentlicht in: Technologie
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Java security

  1. 1. Java SecurityTópicos sobre Segurança na Plataforma Java
  2. 2. ApresentaçõesArmênio CardosoConsultor, Arquiteto de Sistemas e Professor http://www.linkedin.com/in/armeniocardoso http://www.slideshare.net/armeniocardoso
  3. 3. Agenda Metodologia SD3. Processo de Desenvolvimento X Segurança. Requisitos Funcionais X Requisitos Não Funcionais. Categorias de Ameaças. Implementações e Ferramentas. Referências.
  4. 4. Metodologia SD3 Security “by Design”, “by Default” e “in Deployment”. SD3 é um conjunto de estratégias que ajudam a desenvolver sistemas seguros. Baseia-se em três diretrizes:  Design = a segurança deve ser uma das prioridades desde o início do desenvolvimento de um sistema e deve ser considerada no seu projeto.  Default = o framework de desenvolvimento deve conter recursos de segurança para que sua implementação seja natural.  Deployment = o sistema deve rodar em uma plataforma segura, mantida pelo pessoal de infraestrutura.
  5. 5. Princícios da metodologia SD3 Minimizar a área de ataque.  Utilizar a quantidade mínima de características que ofereçam riscos potenciais de ataque tais como: número de portas abertas, número de serviços com privilégios elevados, número de contas com privilégio de administrador. Defaults seguros.  A instalação e a configuração em plataforma de produção segura. Separação de código e dados.  Evitar a possibilidade do usuário efetuar entradas que mesclem código e dados, como por exemplo, caixas de texto que permitem html e javascript.. Menor privilégio.  O sistema deve ser executado no menor privilégio possível para realizar o seu trabalho. Deve-se evitar a necessidade de executar o software como administrador ou como um serviço. Sistemas externos são inseguros.  Ao desenvolver o software considerar que todo sistema externo é inseguro, ou seja, deve-se validar a entrada de forma robusta. Erros e falhas devem terminar de modo seguro.  Caso ocorra uma falha no sistema, deve-se terminar a rotina de modo seguro, ou seja, não se deve expor dados críticos ao informar sobre o erro.
  6. 6. Processo de Desenvolvimento X Segurança Um software seguro deve ser projetado colocando os aspectos de segurança como prioridade. Diretrizes de Segurança:  Treinamento continuado da equipe.  Segurança planejada: devem ser definidos os objetivos de segurança de um produto já na fase de projeto.  Segurança como recurso: a segurança não deve ser considerada como um bônus ou apenas uma característica secundária desejável. Ela deve ser implementada por todo o aplicativo.  Check-in verificado: deve-se incorporar o novo código ao sistema apenas após uma verificação rígida.  Revisão interna e externa. O código deve ser revisado tanto pela equipe quanto por entidades externas, de preferência uma consultoria de segurança ou auditoria.
  7. 7. Processo de Desenvolvimento X Segurança Levantamento de Requisitos.  Requisitos Funcionais X Requisitos Não Funcionais.  Atores X Casos de Uso. Análise e Projeto.  Metodologia de Segurança.  Framework de Segurança. Construção.  Codificação.  Banco de Dados. Testes.  Inspeção de Conformidade.  Análise automática de código – PMD / CheckStyle. Implantação.  Infraestrutura Segura.
  8. 8. Requisitos Funcionais X Requisitos NãoFuncionais O projeto de um sistema seguro deve incorporar a modelagem das possíveis ameças para que seja possível a implementação das proteções adequadas.  Requisitos Funcionais = as funcionalidades do sistema devem ser mapeadas (casos de uso) de forma a permitir a identificação de recursos de segurança.  Requisitos Não Funcionais = arquitetura de recursos default que dão suporte às aplicações e implementam os vários recursos de segurança.
  9. 9. Requisitos Funcionais X Segurança 1. O aplicativo deve ser decomposto formalmente com o objetivo de identificar seu escopo, entradas e saídas. 2. Deve-seidentificar quais componentes ou recursos podem ser alvos de ameaças. Uma forma de se fazer isso é analisar cada item de acordo com as categorias de ameaças. 3. Classificação por risco: as ameaças devem ser classificadas de acordo com seu risco potencial. 04_DREAD.pdf 4. Elaboração da resposta: cada ameaça identificada deve ter uma resposta correspondente do sistema.
  10. 10. Categorias de Ameaças Existem vários critérios disponíveis para categorizar as ameaças – o importante é criar um critério padrão e incorporá-lo à metodologia de desenvolvimento de software.  STRIDE – Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege.  OWASP TOP 10 – As 10 vulnerabilidades de segurança mais críticas em aplicações WEB do Open Web Application Security Project. 01_Check List de Seguranca.pdf 03_OWASP_TOP_10_2007_PT-BR.pdf
  11. 11. Categorias de Ameaças - STRIDE Spoofing  Fazer-se passar por alguém. Tampering  Modificar dados ou código. Repudiation  Dizer que não executou uma operação. Information Disclosure  Expor informações a pessoas não autorizadas. Denial of Service  Negar ou degradar serviços a usuários. Elevation of Privilege  Obter capacidades sem a autorização apropriada. 02_Stride.pdf
  12. 12. Categorias de Ameaças - OWASP Top 10 1 – Cross Site Scripting. 2 – Falhas de Injeção. 3 – Execução Maliciosa de Arquivo. 4 – Referência Insegura Direta a objeto. 5 – Cross Site Request Forgery (CSRF). 6 – Vazamento de Informações e Tratamento de erros inapropriado. 7 – Furo de Autenticação e Gerência de Sessão. 8 – Armazenamento criptográfico inseguro. 9 – Comunicações Inseguras. 10 – Falha ao Restringir Acesso a URLs.
  13. 13. Categorias de Ameaças - Conclusões Determinadas ameaças são respondidas por implementações da aplicação.  Requisitos Funcionais. Outras são respondidas por mecanismos default do framework de desenvolvimento de software.  Requisitos Não Funcionais.
  14. 14. Implementações e Ferramentas Entrada de Dados Segura. Identificação e Autenticação de Usuários. Hash de Senha. Sistemas de gerenciamento de contas de usuários. Mecanismos de autorização. Criptografia Assimétrica. Certificado Digital. Autenticação do servidor. Mecanismos de auditoria. CAPTCHA.
  15. 15. Implementações e Ferramentas Entrada de Dados Segura.  Começa com o simples uso do atributo “maxlength” das tags de entrada de dados do HTML. O “maxlength” deve ser definido conforme o tamanho do campo no banco de dados.  Campos especiais como CNPJ, CPF e Telefone devem utilizar máscaras de entrada de dados. http://www.meiocodigo.com/projects/meiomask/  Deve-se utilizar listas drop-down, botões de rádio e checkboxes ao máximo.
  16. 16. Implementações e Ferramentas Entrada de Dados Segura.  Todos os dados passados ao servidor devem ser codificados de forma a evitar caracteres que possam fazer parte de scripts SQL ou JavaScript (Output Encoding).  Todos os dados passados ao servidor devem ser rigorosamente validados:  Validação Sintática.  Validação Semântica.  Jamais devemos utilizar instruções SQL nas páginas (mesmo JSTL-Database).  Todas as instruções SQL devem ser confinadas em classes DAO e devem utilizar PreparedStatement ou CallableStatement quando usar JDBC.  Nenhuma chamada AJAX deve acessar diretamente um DAO. Sempre utilizar um Façade como intermediário.
  17. 17. Implementações e Ferramentas Identificação e Autenticação de Usuários.  Nível 1: O que o usuário sabe?  O uso de senhas de acesso é o modelo de segurança mais simples e barato de implementar. Podemos complementá-lo com perguntas aleatórias sobre dados cadastrais a fim de dificultar a passagem da senha para uma outra pessoa.  Nivel 2: O que o usuário tem?  Cartões magnéticos, smartcards, biometria e cryptocards são opções na implementação do nível 2.  Nível 3: Onde o usuário está?  Segurança física através de câmeras, vigilantes, portas de aço são recursos de segurança quando o usuário só pode acessar o sistema em um determinado lugar.
  18. 18. Implementações e Ferramentas  Hash de Senha.  Não adianta ter um sistema complexo de autenticação de usuários se a senha trafega pela rede aberta e o DBA consegue fazer um SELECT e listar todos os usuários e as senhas disponíveis.  A criptografia HASH converte a senha em uma sequencia de caracteres única, que não pode ser convertida de volta. Texto Função Original Hash B@27734fAcrescentou- Texto Função O resultadose o “.” Hash B@b66cc é outro! Original.
  19. 19. Implementações e Ferramentas Hash de Senha.  É importante que o algoritmo seja eficaz – alguns mecanismos disponíveis NÃO são seguros!  Não se deve criar algoritmos de criptografia. Somente devem ser usados algoritmos aprovados publicamente.  Não se deve usar algoritmos fracos, como MD5/SHA1. Somente devem ser usados mecanismos seguros como SHA-256 ou melhores.  Na página de login deve ser empregado um script que criptografe a senha de forma que somente o hash da senha seja transmitido e armazenado. http://code.google.com/p/crypto-js/
  20. 20. Implementações e Ferramentas Sistemas de gerenciamento de contas de usuários.  Registro de usuários.  Registro de funcionalidades.  Associação de usuários à funcionalidades.  Manutenção de políticas de segurança.  Uso de contas de administração X usuários com privilégios de administração.] 05_Modelo_de_Controle_de_Acesso.pdf
  21. 21. Implementações e Ferramentas Mecanismos de autorização.  Padrão RBAC = Role Based Access Control.  O padrão RBAC adequa-se perfeitamente aos modelos de casos de uso da UML:  Atores = Papeis (roles).  Casos de Uso = Privilégios.  Os usuários são classificados conforme os casos de uso que desempenham no sistema.  RBAC simplifica a administração por definir um nível granular mais alto para as funcionalidades do sistema.
  22. 22. Implementações e Ferramentas
  23. 23. Implementações e Ferramentas
  24. 24. Implementações e Ferramentas Criptografia Assimétrica.
  25. 25. Implementações e Ferramentas Certificado Digital.  Autoridades de Certificação (Certificate Authorities) são empresas cujas chaves-públicas são conhecidas (e até já vêm pré-instaladas no seu browser ou são mantidas internamente pela área de TI da sua empresa com alto nível de segurança) e emitem certificados que comprovam a autenticidade de sites e indivíduos.  Eles não são falsificáveis justamente porque são criados usando a chave privada da Autoridade de Certificação, que é mantida no mais absoluto sigilo.
  26. 26. Implementações e Ferramentas Autenticação do Servidor.  Alguns usuários verificam que um site pertence a uma empresa somente pelo seu endereço de domínio.  Várias empresas dão credibilidade ao seu endereço através de certificados digitais X.509.  O protocolo SSL – Secure Socket Layer é baseado nesse certificado.  O Web Container precisa implementar suporte ao certificado X.509 preferencialmente de forma declarativa.
  27. 27. Implementações e Ferramentas Autenticação do Servidor.  O SSL (Secure Socket Layer) é protocolo padrão que tanto os programas cliente como os servidores têm que utilizar em uma comunicação segura.  O SSL garante autenticação (através de certificados), integridade e confidencialidade.  O HTTPS é o mesmo protocolo HTTP, só que utiliza-se do SSL como uma camada extra de segurança.
  28. 28. Implementações e Ferramentas Mecanismos de auditoria – Requisitos:  Criação de trilhas de auditoria e alarmes.  Reconstrução de trilhas de auditoria.  Trilhas de auditoria registram o que, quem e quando.  Alarmes são triggers para determinadas funcionalidades.  A auditoria requer planejamento para que se estabeleça claramente que casos de uso requerem registro / alarmes.
  29. 29. Implementações e Ferramentas CAPTCHA é um acrônimo da expressão "Completely Automated Public Turing test to tell Computers and Humans Apart" (teste de Turing público completamente automatizado para diferenciação entre computadores e humanos). É um teste de desafio cognitivo, utilizado como ferramenta anti-spam, desenvolvido pioneiramente na universidade de Carnegie-Mellon.http://simplecaptcha.sourceforge.net/

×