Your SlideShare is downloading. ×
Java security
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Java security

976
views

Published on

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

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

Published in: Technology

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
976
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
28
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Java SecurityTópicos sobre Segurança na Plataforma Java
  • 2. ApresentaçõesArmênio CardosoConsultor, Arquiteto de Sistemas e Professor http://www.linkedin.com/in/armeniocardoso http://www.slideshare.net/armeniocardoso
  • 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Implementações e Ferramentas
  • 23. Implementações e Ferramentas
  • 24. Implementações e Ferramentas Criptografia Assimétrica.
  • 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. 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. 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. 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. 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/