Compartilhar via

Diretrizes de codificação segura

A maioria do código do 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 medidas de imposição em seu código, você deve criar barreiras para impedir que o código mal-intencionado acesse informações que não deseja que ele obtenha ou realize outras ações indesejadas. 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.

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

Protegendo o acesso a 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 (Code Access Security).

  • Não use código parcialmente confiável.

  • Não use o atributo AllowPartiallyTrustedCaller (APTCA).

  • Não use o .NET Remoting.

  • Não use o DCOM (Modelo de Objeto de Componente Distribuído).

  • Não use formatadores binários.

Não há suporte para Code Access Security e Security-Transparent Code como uma barreira de segurança com código parcialmente confiado. Aconselhamos a não carregar e executar código de origens desconhecidas sem colocar medidas de segurança alternativas em vigor. As medidas de segurança alternativas são:

  • Virtualização

  • Contêineres de Aplicativos

  • Usuários e permissões do sistema operacional (SO)

  • Contêineres do Hyper-V

Código neutro de segurança

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 e assim por diante) possam resultar em uma exceção sem tratamento, o código neutro de segurança ainda aproveita as tecnologias de segurança no .NET.

Uma biblioteca neutra em segurança tem características especiais que você deve entender. Suponha que sua biblioteca forneça elementos de API que usam 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.

Código do 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 a codificação especial poderá não ser necessária. No entanto, lembre-se de que o código mal-intencionado pode chamar seu código. Embora a segurança de acesso ao código possa impedir o acesso a recursos mal-intencionados, 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 a entrada do 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 para o 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. 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 wrapper. Se a funcionalidade subjacente não expõe recursos e a implementação também é segura, o wrapper só precisa declarar seus direitos, o que permite que qualquer código chame por meio dele. Quando os recursos estiverem envolvidos, a codificação de segurança deverá ser a mesma que o 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 poderosa e, portanto, potencialmente perigosa (se feita incorretamente) para codificação de segurança: sua biblioteca serve como uma interface para que outro código acesse determinados recursos que não estão disponíveis de outra forma, assim como as classes .NET impõem permissões para os recursos usados. 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 afirmar seus direitos para executar a operação real.

Consulte também