Segurança em Aplicações 5. Melhores Práticas de Programação

1. Segurança em Aplicações5. Melhores Práticas de Programação Márcio Aurélio Ribeiro Moreira marcio.moreira@pitagoras.com.br http://si.lopesgazzani.br/docentes/marcio/

2. Princípios das funções seguras • Princípios: • Documente as funções • Use parâmetros e o retorno fortemente tipados • Teste os parâmetros recebidos (evita SQL/code injection) • Use funções seguras (strncpy ao invés de strcpy) • Crie funções seguras (evita buffer overflow) • Teste o retorno das funções • Função: • // comentários • Função nome (parâmetros) retorno • Teste de parâmetros • Codificação segura • Retorno • Chamador: • Ret. = função(valores) • Teste do retorno entradas Função saídas

3. Princípios gerais • Tenha política de versões consistentes • O recurso afetado existe desde a versão? • Use componentes e bibliotecas confiáveis • Evite arquivos temporários • Se necessário use nomes fixos (arq_userid.tmp) com privilégios fixos • Não armazene senhas e chaves no código • if (senha = “@b0b4*”) then ... • privkey = “88419787349802” • Use ambientes (dev, tst, hml e prd) seguros

4. Princípios de programação segura • Controle as condições de corrida • Teste antes, bloqueie, use e libere • Use semáforos ou outros mecanismos do SO • Minimização de privilégios • Use somente os privilégios necessários • Use várias camadas de segurança • Autenticação para acesso (credencial do usuário) • Autenticação estendida em pontos críticos da aplicação (credenciais do supervisor ou usuário)

5. Princípios de programação segura • Validação das entradas (evita injection) • Assuma que todas as entradas são vulneráveis • Procure valores válidos e rejeite o restante • Teste as entradas no client • Teste as entradas novamente na apresentação • Teste: • Tipo dos dados • Tamanho dos dados • Faixa de valores válidos • Formato dos valores válidos

6. Application.dll Princípios de programação segura • Limite a área de exposição • Crie interfaces somente quando necessário • Ofereça somente os serviços necessários • Use verificadores de código • Ferramentas de análise estática de código • Buscam vulnerabilidades conhecidas no código • Trate as exceções • É altamente recomendável tratar exceções • As exceções de chamadas ao SO são imperativas

7. Recomendações para Java (e .net) • Defina atributos da classe como private • Defina métodos de acesso como protected • Declare métodos internos como private • Defina políticas de acesso a applets Typical Use Source code Compiler Developer Class files User Libraries Virtual Machine

8. Recomendações para Java (e .net) • Use herança com cuidado • Você pode herdar vulnerabilidades • Declare as classes como: • final (evita reuso), • uncloneable (evita instância sem o construtor) e • unserializable (evita acesso serial indireto) • Se precisar assinar o código use um arquivo • Evita o uso indevido de arquivos assinados

9. Evite ou não use em Java (e .net) • Evite blocos privilegiados (privileged blocks) • Padrão: • if (obj.getClass().getName().equals("Admin")) { • // executa aqui a operação privilegiada • } • Se for necessário, use: • if (obj.getClass() == this.getClassLoader().loadClass("Admin")) { • // executa aqui a operação privilegiada • } • Evite atributos estáticos (static)

10. Evite ou não use em Java (e .net) • Não use o mecanismo package para controle de acesso (eles normalmente são abertos) • Não use string para armazenar senhas • Use vetor de char e limpe o conteúdo após o uso • Isto reduz a eficácia do memory dump • Não use classes aninhadas (elas tornam-se acessíveis a todo o pacote) • Não compare o nome de classes (isto revela informações que um espião não deve saber)

11. Materiais adicionais • Writing Secure Code – Best Practices • Secure Programming – Java - SAP • Programación Segura • Strategies for Securing Java Technology Code • Java & Secure Programming (Bad Examples found in JDK) • Catálogo de Práticas de Programação Segura em Java • Mechanisms for Secure Modular Programming in Java • Security Code Guidelines - Sun