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

Desenvolvimento seguro e software livre – Dica 2: Revisão de Código

Posted: dezembro 27th, 2008 | Author: coredump | Filed under: Linux e Open Source, segurança | Tags: ,

CadeadoContinuando com o assunto, estamos na metade do caminho agora. Cheque esta tag para ver os demais posts.

Revisão de Código

Depois que um projeto passa da parte de imaginar o que será feito e pensar em como fazê-lo, começa-se a parte de escrever código, propriamente dita. Se as duas outras dicas foram seguidas, o projeto já vai começar a escrever código com segurança em mente, tendo inclusive alguns documentos para nortear as escolhas (como por exemplo árvores de ataque e uma visão de risco). Caso o desenvolvimento não tenha seguido as dicas de segurança durante sua concepção, vai ser um pouco mais turbulento mas mesmo assim, funcional.

Vulnerabilidades em software podem ser decorrentes de dois problemas distintos: erros de programação e erros de desenho. Os erros de desenho podem ser evitados por uma arquitetura bem feita e uma análise de risco delineando as áreas críticas do projeto. Erros de programação são mais simples de se encontrar, mas demandam mais tempo ou pelo menos um processo formalizado de revisão de código.

Escrever código é uma arte e uma ciência. Demanda partes iguais de genialidade e uma visão lógica e mesmo de estilo. Um código feio é um código difícil de se manter, e como vou falar na última dica, a manutenção do software é de extrema importância para a segurança. Além destas considerações naturais, os membros de projetos de software livre e programadores em geral tem de começar a pensar mais em segurança. Isso envolve diversos fatores, desde conhecer bem a linguagem que se programa até conhecer as falhas da mesma, para que erros básicos possam ser evitados.

Uma das coisas que ajuda bastante na parte de escrever código é a utilização de frameworks e bibliotecas conhecidas. Por mais que seja atrativa a idéia de se codificar um novo sistema do zero isto acarreta inúmeras considerações de segurança e performance que demandam um nível elevadíssimo de trabalho. A não ser que a intenção seja realmente desenvolver um novo framework ou uma biblioteca que tenha uma aproximação diferente para o mesmo (ou um novo) problema, é mais vantajoso utilizar ferramentas que já tenham um bom tempo e uma boa base de usuários. Isto vale tanto para aplicações desktop como aplicações web. Frameworks e bibliotecas responsáveis vão normalmente fornecer aproximações mais seguras do que se ‘reinventar a roda’.

A revisão de código, em si, consiste em um passo extra para a Lei de Linus (que diz que ‘com um número suficiente de olhos, todo problema é trivial’). No ponto de vista de segurança, é mais importante que se tenha olhos treinados em identificar problemas de segurança do que um número grande de olhos. Isto porque alguns erros de segurança são difíceis de se encontrar, e algumas vezes são considerados ‘soluções normais’ pela maioria dos desenvolvedores. Por exemplo, a utilização de variáveis globais em linguagens de programação para aplicações web é uma solução que vários desenvolvedores consideraram (e alguns ainda consideraram) válida, demandou algum tempo até que olhos treinados em segurança identificassem o problema e, lentamente, isso fosse se tornando uma prática esquecida. O ponto é, problemas de segurança em código demandam olhos que estejam especificamente procurando por problemas de segurança e saibam como os encontrar.

Neste ponto, existem várias ferramentas que podem ajudar no processo de revisão. Logicamente nada é melhor que alguém ativamente analisando o código em busca de problemas, mas ferramentas podem ajudar a apontar os erros mais gritantes e facilitar o trabalho de quem está fazendo a revisão (seja uma pessoa ou um time). Frisando novamente: nada substitui olhos ativamente revisando o código escrito, ferramentas ajudam, mas nunca devem substituir o fator humano. O processo pode ser inclusive automatizado no sistema de controle de versões ou no processo de se fazer um release. Existem ferramentas que verificam o código por funções inseguras, variáveis mal utilizadas, vulnerabilidades conhecidas de linguagens e ataques comuns a aplicações web. A implantação de uma rotina de revisão de código pode ser automatizada e se realizada desde o início do projeto é um trabalho não muito pesado.

Tendo em vista que projetos de software livre costumam receber contribuições dos mais diversos tipos de desenvolvedores, é interessante que o projeto conte com um pequeno guia de segurança que descreva e indique políticas básicas como qualidade de código a ser enviada, considerações sobre utilização de frameworks e bibliotecas e mesmo uma lista de práticas que não serão aceitas.

Um exemplo deste pequeno documento seria:

Se você quer contribuir código para o projeto X, tenha em mente que:

- O projeto utiliza o framework <nome> e não aceitaremos código que não seja aderente ao mesmo
- O projeto utiliza a biblioteca <nome> para acesso a banco de dados e a biblioteca <nome> para operações de criptografia
- Não será aceito código declarando variáveis globais
- Não será aceito código usando as funções insegura(), insegura2() e insegura(3), utilize as similares seguras fornecidas pelo framework
- Estas orientações estão disponíveis no wiki/página do projeto <url>, além de outros documentos relacionados ao desenvolvimento

Isto pode ser um simples email enviado a pessoas que obtenham acesso de escrita no controle de versões do projeto ou mesmo na lista de usuários/desenvolvedores do projeto. O importante é que todos saibam que existem as recomendações e que elas devem ser seguidas.

Próximo assunto vai ser sobre Testes de Segurança.

intel

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 1: Análise de Risco Mais um post nesta série, se você quer ver o...
  2. Desenvolvimento seguro e software livre – Dica 4: Operação Segura Cheque esta tag para ver os demais posts desta série....
  3. Desenvolvimento seguro e software livre – Dica 0: Arquitetura e requisitos seguros. Como eu disse semana passada, vou continuar sugerindo algumas dicas/melhores...
  4. Desenvolvimento seguro e software livre – Dica 3: Testes de Segurança Cheque esta tag para ver os demais posts desta série....
  5. Desenvolvimento seguro e software livre Acabei a poucos dias atrás de escrever o trabalho final...

No Comments »

Leave a Reply