Diretrizes para escrever código seguro
As diretrizes a seguir fornecem várias técnicas para escrever código seguro.
Necessário
Usar ferramentas de análise de código.
Visual Studio Team System Development Edition é fornecido com as ferramentas de análise de código que podem aumentar consideravelmente a possibilidade de encontrar bugs de segurança em seu código. Essas ferramentas encontram erros de maneira mais eficiente e com menos esforço.Para obter mais informações, consulte Detectar e corrigir defeitos de código em C/C++ e Detectar e corrigir defeitos de código gerenciado.
Conduzir uma revisão de segurança.
O objetivo de toda revisão de segurança é aumentar a segurança dos produtos que já foram lançados - através de patches ou correções - ou assegurar que nenhum novo produto seja lançado até que esteja tão seguro quanto possível.
Não revise o código aleatoriamente.Prepare-se com antecedência para a revisão de segurança, e comece criando um modelo de ameaça cuidadosamente.Se não fizer isso, você pode desperdiçar uma grande quantidade de tempo do seu time.Priorize códigos que devem receber a maior revisão de segurança e quais bugs de segurança devem ser solucionados.
Seja específico sobre o que procurar em uma revisão de segurança.Quando você procura por problemas específicos, você geralmente os encontra.Procure ainda mais atentamente se sua equipe está localizando uma grande quantidade de erros de segurança em uma área; ele provavelmente indica um problema de arquitetura que deve ser consertado.Se você não está localizando erros de segurança, isso normalmente significa que a revisão de segurança não foi executada corretamente.
Mantenha a revisão de segurança como parte da estabilização para cada etapa, e uma maior linha de produção guiada pelo gerenciamento.
Use uma lista de verificação da revisão de código por segurança.
Independentemente da sua função na equipe de desenvolvimento de software, é útil ter uma lista de verificação para seguir para se assegurar que o design e o código tenham um nível mínimo.
Validar todas entradas do usuário.
Se você permitir a seu aplicativo aceitar entradas do usuário, seja direta ou indiretamente, você deve validar a entrada antes de usá-la.Usuários mal-intencionados tentarão fazer seu aplicativo falhar ajustando a entrada para representar dados inválidos.A primeira regra de entrada do usuário é: Toda entrada é ruim até que se prove o contrário.
Tenha cuidado quando você usa expressões regulares para validar entradas do usuário.Para expressões complexas como endereços de email, é fácil pensar que você está fazendo uma validação completa quando você na verdade não está.Tenha revisão de colegas em todas as expressões regulares.
Valide firmemente todos os parâmetros da interface de programação de aplicativos (APIs) exportada.
Certifique-se de que todos os parâmetros de APIs exportadas são válidos.Isso inclui entradas que parecem consistentes mas estão além do intervalo de valores aceito, como tamanhos de buffer enormes.Não use asserts para verificar os parâmetros das APIs exportadas porque os asserts serão removidos na versão compilada.
Usar APIs de criptografia do Windows.
Em vez de escrever o seu próprio software de criptografia, use a API de criptografia da Microsoft que já está disponível.Usando a API de criptografia da Microsoft, os desenvolvedores são livres para se concentrar nos aplicativos a serem criados.Lembre-se, criptografia resolve um pequeno conjunto de problemas muito bem e é frequentemente usada de maneiras para as quais ela nunca foi desenvolvida.Para obter mais informações, consulte Visão geral sobre criptografia na biblioteca MSDN.
Evitar
Saturações do buffer.
Uma saturação estática do buffer ocorre quando um buffer declarado na pilha é substituído, copiando dados maior que o buffer.Variáveis declaradas na pilha estão localizadas ao lado do endereço de retorno para o chamador de função.Saturações de buffer também podem ocorrer na heap, e essas da mesma forma são perigosas.O culpado usual é passada para uma função, sistema autônomo de entrada do usuário não verificadostrcpy, e o resultado é que o endereço de retorno da função é substituído por um endereço escolhido pelo invasor. Prevenir saturações de buffer é principalmente uma questão de escrever um aplicativo robusto.
Asserts para verificar entrada externa.
Asserts não são compilados em compilações comerciais.Não use asserts para verificar entradas externas.Todos os parâmetros para funções e métodos exportados, todas entradas do usuário, e todos arquivos e dados de soquete devem ser cuidadosamente verificados para validação ou rejeição se estiver defeituoso.
Identificação de usuário e pares de senha embutidos em código.
Não use senhas embutidas em código.Modifique o instalador de modo que, quando as contas de usuário internas são criadas, o administrador será solicitado por senhas de alta segurança para cada conta.Dessa forma, a segurança dos sistemas de nível de produção do cliente pode ser mantida.
Uso de criptografia para resolver todas as questões de segurança.
Criptografia resolve um pequeno conjunto de problemas muito bem e é frequentemente usado de maneiras para as quais ela nunca foi desenvolvida.
URLs e caminhos de arquivo canônico.
Evitar situações onde localidade de um arquivo ou um URL é importante.Usar sistema de arquivos ACLs em vez das regras com base em nomes arquivo canônico.
Recomendável
Revisar todos os antigos defeitos de segurança em seu aplicativo.
Se torne conhecedor dos erros de segurança que você fez no passado.Frequentemente, código é escrito em padrão repetidos.Portanto um erro em uma localidade feito por uma pessoa pode indicar o mesmo erro em outros locais por outras pessoas.
Revisar todos os caminhos de erro.
Frequentemente, código em caminhos de erro não é bem testado e não limpa todos os objetos, tais como proteções ou memória alocada.Cuidadosamente rever esses caminhos e, conforme necessário, criar testes que induzem a falha para exercitar o código.
Não Recomendado
Privilégios de administrador para que aplicativo seja executado.
Aplicativos devem ser executados com o mínimo de privilégio necessário para realizar o trabalho.Se um usuário mal-intencionado encontrar vulnerabilidade de segurança e adiciona código no seu processo, o código mal-intencionado será executado com os mesmos privilégios que o processo host.Se o processo estiver sendo executado como um administrador, o código mal-intencionado será executado como um administrador.Para obter mais informações, consulte Desenvolvendo aplicativos seguros na biblioteca MSDN.