java security
DESCRIPTION
Palestra apresentada para a turma de pós-graduação em Arquitetura de Sistemas - Instituto Infnet.TRANSCRIPT
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/