As emocionantes aventuras de um sysadmin linux na procura pelo uptime perfeito!

Os 25 erros de programação mais perigosos segundo a SANS

Posted: janeiro 22nd, 2009 | Author: coredump | Filed under: segurança | Tags: , ,

Saiu no site da SANS a lista criada com o consenso entre varios profissionais e empresas do ramo de segurança e desenvolvimento descrevendo os 25 erros de programação mais perigosos para o desenvolvimento seguro. Eu vou traduzir os nomes e informação básicos mas o melhor é ler o artigo na íntegra, em inglês.

Os erros estão separados em três categorias: Interação insegura entre componentes, Gerenciamento arriscado de recursos, Defensas porosas.

Categoria: Interação insegura entre componentes

  1. Validação Imprópria de Entradas: Entradas que recebem dados e os aceitam mesmo sem certificar que eles são do tipo/formato esperado.
  2. Codificação ou Escape Impróprios de Saída: Saídas que não são codificadas ou escapadas corretamente são a maior fonte de ataques de injeção de código.
  3. Falha ao Preservar a Estrutura da Busca SQL (conhecido como Injeção de SQL): Se os atacantes podem influenciar as procuras SQL do seu programa, então eles podem controlar o seu banco de dados.
  4. Falha ao Preservar a Estrutura do Código da Página (conhecido como “Cross-site Scripting”): Assim como o anterior, se os atacantes podem injetar código ou scripts em sua página, eles podem controlar a página.
  5. Falha ao Preservar a Estrutura de Comandos do Sistema Operacional: Se você permitir que entradas ilegais sejam passadas para aplicativos do sistema operacional, o atacante pode controlar o servidor.
  6. Transmissão de Dados Sensíveis em Texto Puro: Senhas, dados de cartão e qualquer informação considerada sensível deve ser criptografada.
  7. Falsificação de Requisição Entre Sites: Um atacante pode criar uma requisição que é enviada a outro site forjando a origem e fazendo o mesmo partir de um usuário inocente, aproveitando credenciais de autenticação e acessos.
  8. Condição de Corrida: Atacantes vão sempre procurar por condições de corrida no software para conferir se alguma informação importante não é obtida no processo.
  9. Vazamento de Informações em Mensagens de Erro: Atacantes vão procurar por mensagens de erro que descrevam mais que o necessário, como nomes de campos SQL, objetos e bibliotecas sendo utilizadas.

Categoria: Gerenciamento arriscado de recursos:

  1. Falha ao Limitar Operações aos Limites de um Buffer de Memória: O conhecido buffer overflow.
  2. Controle Externo de Dados Sensíveis: Informações críticas que são mantidas fora de um banco de dados por questões de performance não deviam ser facilmente acessíveis por atacantes.
  3. Controle Externo de de Caminho ou Nome de Arquivo: Quando você usa dados externos para montar um nome de arquivo ou caminho de gravação, você está se arriscando a ser atacado.
  4. Caminho de Procura Inseguro: Se o caminho de procura de recursos estiver em algum lugar sob controle de um atacante, bibliotecas ou código pode ser inserido a revelia.
  5. Falha ao Controlar a Geração de Código: Caso o atacante consiga influenciar a geração de código dinâmico (se geração de código dinâmico for utilizada no programa) ele poderá controlar todo seu código.
  6. Download de Código sem Verificação de Integridade: Se você executa código obtido por download, você confia na fonte. Atacantes podem aproveitar esta confiança.
  7. Desligamento ou Liberação Impróprias de Recursos: Arquivos, conexões e classes precisam ser corretamente encerradas.
  8. Inicialização Imprópria: Dados, bibliotecas e sistemas inicializados incorretamente podem abrir margens para problemas.
  9. Cálculos Incorretos: Quando o atacante tem algum controle sobre as entradas usadas em operações matemáticas, isso pode gerar vulnerabilidades.

Categoria: Defensas porosas:

  1. Controle de Acesso Impróprio: Se você não garante que seus usuários estão fazendo apenas o que deviam, os atacantes irão se aproveitar de sua autenticação.
  2. Uso de um Algoritmo Criptográfico Quebrado ou Vulnerável: Utilização de algoritmos fracos ou comprometidos levam a falhas de criptografia e vulnerabilidades.
  3. Senha no Código: deixar um usuário e uma senha no próprio código traz inúmeros problemas.
  4. Permissão de Acesso Insegura para Recurso Crítico: Configurações, arquivos de dados e bancos de dados devem ter suas permissões de acesso protegidas.
  5. Uso de Valores Insuficientemente Aleatórios: Se você usa tipos de segurança que dependem de aleatoriedade, usar um gerador aleatório insuficiente só vai causar problemas.
  6. Execução com Privilégios Desnecessários: Se seu programa precisa de privilégios elevados para executar suas funções, ele deve abrir mão destes direitos assim que ele termina de executar as ações que precisavam dos privilégios.
  7. Aplicação de Segurança do Lado do Servidor pelo Cliente: Atacantes podem usar engenharia reversa em um cliente de software e escrever seus próprios clientes removendo testes e aplicações de segurança.

Algumas coisas foram realmente chatas de traduzir, sinta-se livre para sugerir correções.

intel

PS: Lembre-se sempre “os 25 mais” não quer dizer “os 25 únicos”. Grain of Salt faz bem.

Compartilhe:
  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • LinkedIn
  • Slashdot
  • StumbleUpon
  • Technorati
  • TwitThis
  • Identi.ca
  • Twitter

Posts relacionados:

  1. Desenvolvimento seguro e software livre – Dica 4: Operação Segura Cheque esta tag para ver os demais posts desta série....
  2. Desenvolvimento seguro e software livre – Dica 0: Arquitetura e requisitos seguros. Como eu disse semana passada, vou continuar sugerindo algumas dicas/melhores...
  3. Não existe mundo virtual, infelizmente. Na verdade essa barafunda toda com relação o PL 84/99...
  4. Desenvolvimento seguro e software livre – Dica 2: Revisão de Código Continuando com o assunto, estamos na metade do caminho agora....
  5. Desenvolvimento seguro e software livre – Dica 1: Análise de Risco Mais um post nesta série, se você quer ver o...

8 Comments »

8 Comments on “Os 25 erros de programação mais perigosos segundo a SANS”

  1. 1 Cesar Cardoso said at 17:00 on janeiro 22nd, 2009:

    Três comentários sobre a primeira categoria…

    SQL Injection (item 3) se tornou um clássico da programação tosca para a Web, desde os tempos do PHPNuke.

    XSS (item 4) é A falha de programação da Web 2.0.

    Quem comete a falha do item 6 a esta altura do campeonato deveria ser proibido de projetar sistemas.

  2. 2 Patola said at 21:04 on janeiro 23rd, 2009:

    Errrr, condição de CORRIDA? Fala sério… aehuahuehuahuehua.

    Nos meus livros-texto de computação – os raros que eram em português – a expressão RACE CONDITION sempre foi traduzida como CONDIÇÃO DE CONFLITO. Se for algo como isso, é melhor até deixar sem traduzir.

  3. 3 coredump said at 21:27 on janeiro 23rd, 2009:

    É, achei feio também, mas conferi com outras pessoas e a tradução mais ou menos aceita :)

  4. 4 Paulo H Gonçalvez said at 13:13 on janeiro 24th, 2009:

    Achei fantástica sua iniciativa pela tradução do texto… parabéns….

  5. 5 henrique said at 21:38 on janeiro 24th, 2009:

    Não há problema algum na tradução para “condições de corrida”. Esse é o termo que todo livro em português usa. Tradução completamente aceita.

  6. 6 Wagner Saback Dantas said at 14:56 on janeiro 25th, 2009:

    Eu também conheço «race condition» como «condição de corrida», aliás esta tradução é usada por alguns livros de Sistemas Operacionais vertidos para português.

    No mais, coredump, obrigado pela contribuição!

  7. 7 Bruno said at 9:33 on janeiro 26th, 2009:

    O termo condição de corrida é totalmente aceito, pois alguns autores de muito prestígio usam esse termo, como por exemplo Andrew S.Tanembaum

  8. 8 Wagner Elias said at 12:36 on janeiro 26th, 2009:

    O termo condição de corrida é comum em português e lógico. O que acontece com uma falha de race condition?

    Quanto aos comentários sobre SQL Injection, acho que um dos fatores que permitem que o SQLi ainda atinja muitos sites é achar que é simples. Para ter uma idéia, 90% dos tutoriais que eu vejo sobre tratamento de SQLi são vulneráveis. Então SQLi não é um fator relacionado a programação tosca;

    Quanto a XSS, nada tem a ver com WEB 2.0, afinal a execução de script é possível devido a falha de validação, portanto acontece em qualquer sistema de hoje ou ontem;

    Quanto ao item 6, se for referente a HTTP/S o problema muitas vezes é a dependência de uma equipe de infra para implementar os certificados, não é uma características que o programador desenvolve.

    Parabéns pelo post.


Leave a Reply