Java Security

Tópicos sobre Segurança na Plataforma Java

Apresentações

Armênio CardosoConsultor, Arquiteto de Sistemas e

Professor

http://www.linkedin.com/in/armeniocardoso

http://www.slideshare.net/armeniocardoso

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.

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.

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.

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.

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.

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.

Requisitos Funcionais X Segurança1.O aplicativo deve ser decomposto formalmente com o

objetivo de identificar seu escopo, entradas e saídas.

2.Deve-se identificar 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.

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

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

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.

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.

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.

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.

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.

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.

Texto Original.

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.

FunçãoHash B@27734f

Texto Original

FunçãoHash B@b66cc

Acrescentou-se o “.”

O resultado é outro!

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/

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

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.

Implementações e Ferramentas

Implementações e Ferramentas

Implementações e Ferramentas Criptografia Assimétrica.

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.

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.

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.

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.

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/