Orientações de codificação seguras

A maioria do código de aplicação pode simplesmente usar a infraestrutura implementada por .NET. Em alguns casos, é necessária uma segurança adicional específica da aplicação, construída quer através do alargamento do sistema de segurança, quer através da utilização de novos métodos ad hoc.

Utilizando permissões forçadas .NET e outras aplicações no seu código, deve erguer barreiras para impedir que código malicioso aceda a informações que não pretende que tenham ou realizem 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 fidedigno.

Esta visão geral descreve as diferentes formas de o código poder ser concebido para funcionar com o sistema de segurança.

Garantir o acesso a recursos

Ao desenhar e escrever o seu código, é necessário proteger e limitar o acesso que esse código tem aos recursos, especialmente quando se utiliza ou invoca código de origem desconhecida. Por isso, lembre-se das seguintes técnicas para garantir que o seu código está seguro:

  • Não utilize a Segurança de Acesso código (CAS).

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

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

  • Não utilize .NET Remoting.

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

  • Não utilize formadores binários.

Código de Segurança e Security-Transparent Código não são suportados como uma fronteira de segurança com código parcialmente confiável. Aconselhamos contra o carregamento e execução do código de origens desconhecidas sem colocar em prática medidas de segurança alternativas. As medidas de segurança alternativas são:

  • Virtualização

  • AppContainers

  • Utilizadores e permissões do sistema operativo (OS)

  • Recipientes hiper-V

Código neutro em segurança

O código neutro de segurança não explicita o sistema de segurança. Funciona com as permissões que recebe. Embora as aplicações que não conseguem obter exceções de segurança associadas a operações protegidas (como a utilização de ficheiros, networking, e assim por diante) possam resultar numa exceção não manipulada, o código neutro em segurança ainda tira partido das tecnologias de segurança em .NET.

Uma biblioteca neutra em segurança tem características especiais que deve entender. Suponha que a sua biblioteca fornece elementos API que usam ficheiros ou chamam código não gerido. Se o seu código não tiver a permissão correspondente, não será executado como descrito. No entanto, mesmo que o código tenha a permissão, qualquer código de aplicação 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 aparece como resultado da caminhada da pilha de segurança de acesso de código.

Código de aplicação que não é um componente reutilizável

Se o seu código faz parte de uma aplicação que não será chamada por outro código, a segurança é simples e a codificação especial pode não ser necessária. No entanto, lembre-se que o código malicioso pode ligar para o seu código. Embora a segurança do acesso a códigos possa impedir o código malicioso de aceder a recursos, tal código ainda pode ler valores dos seus campos ou propriedades que possam conter informações sensíveis.

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

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

Normalmente neste cenário, algumas funcionalidades úteis são implementadas em código nativo que pretende disponibilizar para código gerido. Os invólucros geridos são fáceis de escrever usando a plataforma invocar ou interop COM. No entanto, se o fizer, os autores dos seus invólucros devem ter direitos de código não geridos para serem bem sucedidos. De acordo com a política padrão, isto significa que o código descarregado de uma intranet ou da Internet não funcionará com os invólucros.

Em vez de dar direitos de código não geridos a todas as aplicações que usam estes invólucros, é melhor dar estes direitos apenas ao código de invólucro. Se a funcionalidade subjacente não expor recursos e a implementação for igualmente segura, o invólucro apenas precisa de afirmar os seus direitos, o que permite que qualquer código o chame através dele. Quando os recursos estão envolvidos, a codificação de segurança deve ser a mesma que o caso do código da biblioteca descrito na secção seguinte. Como o invólucro está potencialmente expondo os chamadores a estes recursos, é necessária uma verificação cuidadosa da segurança do código nativo e é da responsabilidade do invólucro.

Código da biblioteca que expõe recursos protegidos

A seguinte abordagem é a mais poderosa e, portanto, potencialmente perigosa (se feita incorretamente) para codificação de segurança: a sua biblioteca serve como interface para outro código para aceder a determinados 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 exponha um recurso, o seu código deve primeiro exigir a permissão adequada ao recurso (ou seja, deve efetuar uma verificação de segurança) e, em seguida, normalmente afirmar os seus direitos de realização da operação real.

Ver também