Diretrizes de codificação segura
A maioria do código do aplicativo pode simplesmente usar a infraestrutura implementada pelo .NET. Em alguns casos, é necessária segurança adicional específica do aplicativo, construída estendendo o sistema de segurança ou usando novos métodos ad hoc.
Usando permissões impostas pelo .NET e outras imposições em seu código, você deve erguer barreiras para impedir que códigos mal-intencionados acessem informações que você não quer que ele tenha ou executem outras ações indesejáveis. Além disso, você deve encontrar 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 como o código pode ser projetado para trabalhar com o sistema de segurança.
Proteger o acesso aos recursos
Ao projetar e escrever seu código, você precisa proteger e limitar o acesso que o código tem aos recursos, especialmente ao usar ou invocar código de origem desconhecida. Portanto, tenha em mente as seguintes técnicas para garantir que seu código seja seguro:
Não use CAS (Segurança de Acesso ao Código).
Não use código confiável parcial.
Não use o atributo AllowPartiallyTrustedCaller (APTCA).
Não use a comunicação remota do .NET.
Não use DCOM (Distributed Component Object Model).
Não use formatters binários.
A Segurança de Acesso ao Código e o Código Transparente de Segurança não são suportados como um limite de segurança com código parcialmente confiável. Aconselhamos a não carregar e executar códigos de origem desconhecida sem pôr em prática medidas de segurança alternativas. As medidas de segurança alternativas são:
Virtualização
AppContainers
Usuários e permissões do sistema operacional (SO)
Containers Hyper-V
Código neutro em termos de segurança
O código neutro em termos de segurança não faz nada explícito com o sistema de segurança. Ele é executado com quaisquer permissões que receber. 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) possam resultar em uma exceção não tratada, o código neutro de segurança ainda aproveita as tecnologias de segurança no .NET.
Uma biblioteca neutra em termos de segurança tem características especiais que deve compreender. Suponha que sua biblioteca forneça elementos de API que usam arquivos ou chamam código não gerenciado. Se o seu código não tiver 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 o chame deve ter a mesma permissão para funcionar. Se o código de chamada não tiver a permissão correta, um SecurityException será exibido como resultado da caminhada da pilha de segurança de acesso ao código.
Código de aplicativo que não é um componente reutilizável
Se o seu código fizer parte de um aplicativo que não será chamado por outro código, a segurança é simples e a codificação especial pode não ser necessária. No entanto, lembre-se de que um código malicioso pode chamar o seu código. Embora a segurança de acesso ao código possa impedir que códigos mal-intencionados acessem recursos, esse código ainda pode ler valores de seus campos ou propriedades que podem conter informações confidenciais.
Além disso, se o seu código aceita entrada do usuário da Internet ou outras fontes não confiáveis, você deve ter cuidado com a entrada maliciosa.
Wrapper gerenciado para implementação de código nativo
Normalmente, nesse cenário, algumas funcionalidades úteis são implementadas no código nativo que você deseja disponibilizar para o código gerenciado. Os wrappers gerenciados são fáceis de escrever usando invocar plataforma ou interoperabilidade COM. No entanto, se você fizer isso, os chamadores de seus wrappers devem ter direitos de código não gerenciados para serem bem-sucedidos. Na política padrão, isso significa que o código baixado de uma intranet ou da Internet não funcionará com os wrappers.
Em vez de conceder direitos de código não gerenciados a todos os aplicativos que usam esses wrappers, é melhor conceder esses direitos apenas ao código do wrapper. Se a funcionalidade subjacente não expõe recursos e a implementação também é segura, o wrapper só precisa fazer valer seus direitos, o que permite que qualquer código chame através dele. Quando os recursos estão envolvidos, a codificação de segurança deve ser a mesma que o caso de código da biblioteca descrito na próxima seção. Como o wrapper está potencialmente expondo os chamadores a esses recursos, a verificação cuidadosa da segurança do código nativo é necessária e é responsabilidade do wrapper.
Código da biblioteca que expõe recursos protegidos
A abordagem a seguir é a mais poderosa e, portanto, potencialmente perigosa (se feita incorretamente) para codificação de segurança: sua biblioteca serve como uma interface para outro código acessar certos recursos que não estão disponíveis de outra forma, assim como as classes .NET impõem permissões para os recursos que usam. Onde quer que você exponha um recurso, seu código deve primeiro exigir a permissão apropriada para o recurso (ou seja, ele deve executar uma verificação de segurança) e, em seguida, normalmente reivindicar seus direitos para executar a operação real.
