Diretrizes de codificação segura
A maioria dos códigos de aplicativo pode simplesmente usar a infraestrutura implementada pelo .NET. Em alguns casos, a segurança adicional específica do aplicativo é necessária, criada estendendo o sistema de segurança ou usando novos métodos ad hoc.
Usando permissões impostas pelo .NET e outras imposições no seu código, você deve criar barreiras para impedir que o código mal-intencionado acesse informações ou execute 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 em que o código pode ser criado para interagir com o sistema de segurança.
Protegendo o acesso a recursos
Ao criar 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 do código).
Não use código parcialmente confiável.
Não use o atributo AllowPartiallyTrustedCaller (APTCA).
Não use comunicação remota do .NET.
Não use DCOM (Distributed Component Object Model).
Não use formatadores binários.
A segurança de acesso do código e o código transparente de segurança não são compatíveis como 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
Usuários e permissões do sistema operacional
Contêineres do Hyper-V
Código de segurança neutra
O código de segurança neutra não faz nada explícito com o sistema de segurança. Ele é executado com todas as permissões que 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 etc.) possam resultar em uma exceção sem tratamento, o código de segurança neutra ainda aproveita as tecnologias de segurança do .NET.
Uma biblioteca de segurança neutra tem características especiais que você deve entender. Suponhamos que a biblioteca forneça elementos de API que usem arquivos ou chamem código não gerenciado. Se o código não tiver a permissão correspondente, ele não será executado conforme 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 certa, uma SecurityException será exibida como resultado da movimentação da pilha de segurança de acesso do código.
O código de aplicativo que não é um componente reutilizável
Se o código fizer parte de um aplicativo que não será chamado por outro código, a segurança será simples e talvez não seja necessária uma codificação especial. No entanto, lembre-se de que o código mal-intencionado pode chamar seu código. Embora a segurança de acesso do código possa impedir o acesso do código mal-intencionado aos recursos, esse código ainda pode ler valores de seus campos ou propriedades que possam conter informações confidenciais.
Além disso, se o código aceitar entrada de usuário da Internet ou de outras fontes não confiáveis, você deverá ter cuidado com a entrada mal-intencionada.
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 no código gerenciado. Os wrappers gerenciados são fáceis de gravar usando a invocação de plataforma ou a interoperabilidade COM. No entanto, se você fizer isso, os chamadores dos wrappers deverão ter direitos de código não gerenciados para ter êxito. Segundo a 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 dar direitos de código não gerenciados a todos os aplicativos que usam esses wrappers, é melhor dar esses direitos somente ao código wrapper. Se a funcionalidade subjacente não expuser recursos e a implementação também for segura, o wrapper só precisará declarar seus direitos, o que permitirá que qualquer código chame por meio dele. Quando recursos estiverem envolvidos, a codificação de segurança deverá ser igual à do caso de código de 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 de biblioteca que expõe recursos protegidos
A abordagem a seguir é a mais avançada e, portanto, potencialmente perigosa (se feita incorretamente) para codificação de segurança: a biblioteca serve de interface para outros códigos acessarem determinados recursos não disponíveis de outra forma, assim como as classes do .NET impõem permissões para os recursos que usam. Sempre que você expuser um recurso, seu código deverá primeiro exigir a permissão apropriada para o recurso (ou seja, deverá executar uma verificação de segurança) e, em seguida, declarar seus direitos para executar a operação real.
