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 Premiuminclui ferramentas de análise de código que podem aumentar significativamente a possibilidade de encontrar bugs de segurança no seu código. Essas ferramentas encontram erros de maneira mais eficiente e com menos esforço. Para obter mais informações, consulte um dos tópicos a seguintes.
Conduzir uma revisão de segurança.
O objetivo de cada revisão de segurança é para aumentar a segurança dos produtos que já foram lançados, fornecendo atualizações, ou para garantir que nenhum novos produtos são lançados até que elas são tão seguras 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. Observe ainda mais difícil, se sua equipe é localizar muitos bugs de segurança em uma área. Provavelmente, ele indica um problema de arquitetura que deve ser corrigido. 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 que o seu aplicativo aceitar a entrada do usuário, direta ou indiretamente, você deve validar a entrada antes de usá-lo. 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é provar 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.
Altamente valide todos os parâmetros de interfaces (APIs) de programação de aplicativo exportado e público.
Certifique-se de que todos os parâmetros de APIs públicas e exportados são válidos. Isso inclui a entrada que procura consistente, mas está além do intervalo de valores, como, por exemplo, os tamanhos de buffer grande aceito. 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 Referência de criptografia em que o 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, como de entrada do usuário não verificado strcpy, 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.
Usando a criptografia para resolver todas as questões de segurança.
A criptografia resolve um pequeno conjunto de problemas muito bem e é freqüentemente usada de forma que ele nunca foi projetado para.
URLs e caminhos de arquivo canônico.
Evite situações em que o local de um arquivo ou uma 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 bug em um único local por uma pessoa pode indicar o mesmo erro em outros locais por outras pessoas.
Revisar todos os caminhos de erro.
Freqüentemente, o código em caminhos de erro não está bem testado e limpar todos os objetos, como, por exemplo, bloqueios ou memória alocada. Cuidadosamente rever esses caminhos e, conforme necessário, criar testes que induzem a falha para exercitar o código. Para obter mais informações, consulte "Validação da entrada" seção de diretrizes de Design para proteger aplicativos da Web e "Validação da entrada" seção de revisão da arquitetura e Design de segurança na biblioteca MSDN.
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 o desenvolvimento de Software em Visual Studio.NET com Non-Administrative Privileges em que o Biblioteca MSDN.