Este artigo foi traduzido por máquina. Para visualizar o arquivo em inglês, marque a caixa de seleção Inglês. Você também pode exibir o texto Em inglês em uma janela pop-up, movendo o ponteiro do mouse sobre o texto.
Tradução
Inglês

Diretrizes de codificação segura

 

Segurança baseada em evidência e segurança de acesso ao código fornecem mecanismos poderosos, explícitos para implementar a segurança. A maioria dos códigos de aplicativo pode simplesmente usar a infra-estrutura implementada pelo .NET Framework. Em alguns casos, segurança específicas do aplicativo adicional é necessária, criado estendendo o sistema de segurança ou usando novos métodos ad hoc.

Usando as permissões aplicadas pelo .NET Framework e outra imposição em seu código, você deve colocar as barreiras para impedir que código mal-intencionado de obtenção de informações que você não quer que ela tenha ou executar outras ações indesejáveis. Além disso, você deve obter um equilíbrio entre segurança e usabilidade em todos os cenários esperados usando código confiável.

Esta visão geral descreve as diferentes maneiras de código pode ser projetado para trabalhar com o sistema de segurança.

Ao projetar e escrever seu código, você precisa proteger e limitar o acesso código tem a recursos, especialmente ao usar ou invocar código de origem desconhecida. Portanto, tenha em mente as seguintes técnicas para garantir que o código está seguro:

  • Não use a segurança de acesso do código (CAS).

  • Não use o código de confiança parcial.

  • Não use o .NET Remoting.

  • Não use o modelo de objeto componente distribuído (DCOM).

  • Não use formatadores binários.

Segurança de acesso ao código e o código transparente de segurança não serão suportadas como um limite de segurança com código parcialmente confiável. Não aconselhamos carregar e executar códigos de origens desconhecidas sem a adoção de medidas de segurança alternativas no local. As medidas de segurança alternativas são:

  • Virtualização

  • AppContainers

  • Sistema operacional (SO) usuários e permissões

  • Contêineres de Hyper-V

Código de segurança neutra não faz nada explícita com o sistema de segurança. Seja executada com as permissões que ele recebe. Embora os aplicativos que não conseguem capturar exceções de segurança associadas a operações protegidas (como o uso de arquivos, rede e assim por diante) podem resultar em uma exceção não tratada, código de segurança neutra ainda aproveita as tecnologias de segurança do .NET Framework.

Uma biblioteca de segurança neutra tem características especiais que você deve compreender. Suponha que sua biblioteca fornece elementos de API que usam arquivos ou chamar código não gerenciado; Se seu código não tem a permissão correspondente, ele não será executado como descrito. No entanto, mesmo que o código tenha a permissão, qualquer código de aplicativo que chama deve ter a mesma permissão para trabalhar. Se o código de chamada não tem a permissão correta, um SecurityException aparece como resultado de movimentação de pilha de segurança de acesso código.

Se seu código fizer parte de um aplicativo que não será chamado por outro código, a segurança é simple e codificação especial pode não ser necessário. No entanto, lembre-se de que o código mal-intencionado pode chamar seu código. Enquanto a segurança de acesso ao código pode parar mal-intencionados acessem recursos, esse código ainda pode ler os valores de seus campos ou propriedades que podem conter informações confidenciais.

Além disso, se seu código aceita entrada do usuário da Internet ou outras fontes não confiáveis, você deve ser cuidadoso com entradas mal-intencionadas.

Normalmente nesse cenário, algumas funcionalidades úteis é implementada no código nativo que você deseja tornar disponíveis para código gerenciado. Invólucros gerenciados são fáceis de gravação usando o platform invoke ou a interoperabilidade COM. No entanto, se você fizer isso, os chamadores de seus wrappers devem ter direitos de código não gerenciado para ser bem-sucedido. Política padrão, isso significa que o código baixado em uma intranet ou Internet não funcionará com os wrappers.

Em vez de dar a todos os aplicativos que usam esses direitos de código não gerenciado wrappers, é melhor fornecer esses direitos somente para o código de wrapper. Se a funcionalidade subjacente não expõe nenhum recurso e a implementação da mesma forma é segura, o wrapper só precisa declarar seus direitos, que permite que qualquer código chame através dele. Quando os recursos estão envolvidos, codificação de segurança deve ser o mesmo no caso de código de biblioteca descrito na próxima seção. Como o wrapper está potencialmente expondo chamadores a esses recursos, cuidadosa verificação de segurança do código nativo é necessária e é responsabilidade do wrapper.

Isso é mais eficiente e, portanto, potencialmente perigoso (se feita incorretamente) abordagem para codificação de segurança: sua biblioteca serve como uma interface para acessar determinados recursos que não estejam disponíveis, assim como as classes do .NET Framework impõem permissões para recursos que usam outro código. Sempre que você exponha um recurso, seu código deve primeiro exigem a permissão apropriada para o recurso (ou seja, ele deve executar uma verificação de segurança) e, em seguida, declarar normalmente seus direitos para executar a operação real.

Título

Descrição

Protegendo dados de estado

Descreve como proteger os membros privados.

Segurança e entrada do usuário

Descreve problemas de segurança de aplicativos que aceitam entrada do usuário.

Segurança e condições de corrida

Descreve como evitar condições de corrida em seu código.

Segurança e geração de código durante a execução

Descreve problemas de segurança de aplicativos que geram código dinâmico.

Segurança baseada em função

Descreve a segurança baseada em função do .NET Framework em detalhes e fornece instruções sobre como usá-lo em seu código.

Mostrar: