Segurança em .NET

[marcialwushu]

https://docs.microsoft.com/en-us/dotnet/standard/security/

[marcialwushu]

Diretrizes de codificação seguras

• 09/15/2021

In this article

1. Securing resource access
2. Security-neutral code
3. Application code that isn't a reusable component
4. Managed wrapper to native code implementation
5. Library code that exposes protected resources
6. See also

A maioria dos códigos de aplicativos pode simplesmente usar a infraestrutura implementada pelo .NET. Em alguns casos, é necessária uma segurança específica de aplicativos adicional, construída através da extensão do sistema de segurança ou usando novos métodos ad hoc.

Usando permissões impostas pelo .NET e outras execuções em seu código, você deve erguer barreiras para impedir que o código malicioso acesse informações que você não deseja que ela tenha ou realize 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 pelas quais o código pode ser projetado para funcionar com o sistema de segurança.

Garantir o acesso a recursos

Ao projetar e escrever seu código, você precisa proteger e limitar o acesso que esse 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 esteja seguro:

• Não use CAS (Code Access Security, segurança de acesso ao código).

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

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

• Não utilize o remoting .NET.

• Não use DCOM (Distributed Component Object Model, modelo de objeto de componente distribuído).

• 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 contra o carregamento e a execução de códigos de origens desconhecidas sem colocar medidas alternativas de segurança em vigor. As medidas alternativas de segurança são:

• Virtualização

• AppContainers

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

• Recipientes Hyper-V

Código neutro de segurança

Código neutro de segurança não faz nada explícito com o sistema de segurança. Ele funciona com quaisquer permissões que recebe. Embora aplicativos que não peguem 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 manipulada, o código neutro de segurança ainda se aproveita das 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 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 certa, 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 faz parte de um aplicativo que não será chamado por outro código, a segurança é simples e uma codificação especial pode não ser necessária. No entanto, lembre-se que o código malicioso pode chamar seu código. Embora a segurança de acesso ao código possa impedir que o código malicioso acesse recursos, esse código ainda pode ler valores de seus campos ou propriedades que possam conter informações confidenciais.

Além disso, se o seu código aceitar a entrada do usuário da Internet ou outras fontes não confiáveis, você deve ter cuidado com a entrada maliciosa.

Invólucro gerenciado para implementação de código nativo

Normalmente, neste cenário, alguma funcionalidade útil é implementada em código nativo que você deseja disponibilizar ao código gerenciado. Os invólucros gerenciados são fáceis de escrever usando a invocação da plataforma ou o interop COM. No entanto, se você fizer isso, os chamadores de seus invólucros devem ter direitos de código não gerenciados para ter sucesso. Na política padrão, isso significa que o código baixado de uma intranet ou da Internet não funcionará com os invólucros.

Em vez de dar direitos de código não gerenciados a todos os aplicativos que usam esses invólucros, é melhor dar esses direitos apenas ao código de invólucro. Se a funcionalidade subjacente não expõe recursos e a implementação também é segura, o invólucro só precisa afirmar seus direitos, o que permite que qualquer código o chame. Quando os recursos estão envolvidos, a codificação de segurança deve ser a mesma do caso de código da biblioteca descrito na próxima seção. Como o invólucro está potencialmente expondo os chamadores a esses recursos, é necessária uma verificação cuidadosa da segurança do código nativo e é responsabilidade do invólucro.

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 outro código para 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 eles usam. Onde quer que você exponha um recurso, seu código deve primeiro exigir a permissão apropriada ao recurso (ou seja, ele deve realizar uma verificação de segurança) e, em seguida, normalmente afirmar seus direitos para executar a operação real.

Veja também

• Protegendo dados do Estado
• Entrada de segurança e usuário
• Condições de segurança e raça
• Geração de códigos de segurança e on-the-fly
• Segurança baseada em papel
• Segurança do Núcleo ASP.NET