O documento discute tópicos sobre segurança na plataforma Java, abordando a metodologia SD3 de desenvolvimento seguro, categorias de ameaças como STRIDE e OWASP Top 10, e implementações e ferramentas de segurança como autenticação, criptografia, certificados digitais e mecanismos de autorização.

1. Java Security
Tópicos sobre Segurança na Plataforma Java

2. Apresentações
Armênio Cardoso
Consultor, 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ão
Funcionais
 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@27734f
Acrescentou- Texto Função O resultado
se 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/