CA2107: Revisão Negar e permitir o uso apenas
TypeName |
ReviewDenyAndPermitOnlyUsage |
CheckId |
CA2107 |
Category (Categoria) |
Microsoft.Security |
A última alteração |
Interromper |
Faz com que
O método contém uma verificação de segurança que especifica a ação de segurança de PermitOnly ou Deny.
Descrição da regra
As ações de segurança de Usando o método PermitOnly e de CodeAccessPermission.Deny devem ser usadas somente por aqueles que têm um conhecimento de segurança avançada de .NET Framework .O código que usa essas ações de segurança deve passar por uma revisão de segurança.
Negar altera o comportamento padrão de exame de pilha que ocorre em resposta a um requisito de segurança.Permite que você especifique as permissões que não devem ser concedidas para a duração de método negar, independentemente das permissões reais dos chamadores na pilha de chamada.Se a exame de pilha detectar um método que é protegido Deny, e se a permissão necessária está incluída nas permissões negado, a exame de pilha falhar.PermitOnly também alterar o comportamento padrão de exame de pilha.Permite que o código especifica somente as permissões que podem ser concedidas, independentemente das permissões dos chamadores.Se a exame de pilha detectar um método que é protegido por PermitOnly, e se a permissão necessária não está incluída nas permissões que são especificadas por PermitOnly, a exame de pilha falhar.
O código que depende em essas ações com cuidado deve ser avaliado para as vulnerabilidades de segurança devido seus utilidade limitada e comportamento sutil.Considere o seguinte:
Demandas de link não é afetado Deny ou por PermitOnly.
Se ou negar o PermitOnly ocorrem no mesmo quadro de pilha que a aparência que causa a exame de pilha, as ações de segurança não têm efeito.
Os valores que são usados para construir caminho- permissões baseadas geralmente podem ser especificados em várias maneiras.Negar acesso a um formulário de caminho não nega acesso a todos os formulários.Por exemplo, se \ compartilhamento de arquivos do servidor \ \ compartilhamento é mapeado para uma unidade de rede X: , para negar o acesso a um arquivo no compartilhamento, você deve negar \ \ \ \ servidor compartilhamento Arquivo X:\File, e todos os outros caminho que acessa o arquivo.
CodeAccessPermission.Assert pode finalizar um exame de pilha ou negar antes que o PermitOnly sejam alcançados.
Se qualquer Deny tem efeito, isto é, quando um chamador tiver uma permissão que esteja bloqueada negar, o chamador pode acessar o recurso protegido diretamente, ignorando negar.De a mesma forma, se o chamador não tiver permissão negada, a exame de pilha falharia sem negar.
Como corrigir violações
Qualquer uso de essas ações fará com que uma violação de segurança.Para corrigir uma violação, não use estas ações de segurança.
Quando suprimir avisos
Elimina um aviso de esta regra somente depois que você concluir uma revisão de segurança.
Exemplo
O exemplo a seguir demonstra algumas restrições Deny.
A biblioteca seguir contém uma classe que tem dois métodos que são idênticos exceto as demandas de segurança que as protegem.
using System.Security;
using System.Security.Permissions;
using System;
namespace SecurityRulesLibrary
{
public class SomeSecuredMethods
{
// Demand immediate caller has suitable permission
// before revealing sensitive data.
[EnvironmentPermissionAttribute(SecurityAction.LinkDemand,
Read="COMPUTERNAME;USERNAME;USERDOMAIN")]
public static void MethodProtectedByLinkDemand()
{
Console.Write("LinkDemand: ");
}
[EnvironmentPermissionAttribute(SecurityAction.Demand,
Read="COMPUTERNAME;USERNAME;USERDOMAIN")]
public static void MethodProtectedByDemand()
{
Console.Write("Demand: ");
}
}
}
O aplicativo seguir mostra os efeitos Deny os métodos protegidos de biblioteca.
using System.Security;
using System.Security.Permissions;
using System;
using SecurityRulesLibrary;
namespace TestSecurityLibrary
{
// Violates rule: ReviewDenyAndPermitOnlyUsage.
public class TestPermitAndDeny
{
public static void TestAssertAndDeny()
{
EnvironmentPermission envPermission = new EnvironmentPermission(
EnvironmentPermissionAccess.Read,
"COMPUTERNAME;USERNAME;USERDOMAIN");
envPermission.Assert();
try
{
SomeSecuredMethods.MethodProtectedByDemand();
Console.WriteLine(
"Caller's Deny has no effect on Demand " +
"with the asserted permission.");
SomeSecuredMethods.MethodProtectedByLinkDemand();
Console.WriteLine(
"Caller's Deny has no effect on LinkDemand " +
"with the asserted permission.");
}
catch (SecurityException e)
{
Console.WriteLine(
"Caller's Deny protected the library.{0}", e);
}
}
public static void TestDenyAndLinkDemand()
{
try
{
SomeSecuredMethods.MethodProtectedByLinkDemand();
Console.WriteLine(
"Caller's Deny has no effect with " +
"LinkDemand-protected code.");
}
catch (SecurityException e)
{
Console.WriteLine(
"Caller's Deny protected the library.{0}",e);
}
}
public static void Main()
{
EnvironmentPermission envPermission = new EnvironmentPermission(
EnvironmentPermissionAccess.Read,
"COMPUTERNAME;USERNAME;USERDOMAIN");
envPermission.Deny();
//Test Deny and Assert interaction for LinkDemands and Demands.
TestAssertAndDeny();
//Test Deny's effects on code in different stack frame.
TestDenyAndLinkDemand();
//Test Deny's effect on code in same frame as deny.
try
{
SomeSecuredMethods.MethodProtectedByLinkDemand();
Console.WriteLine(
"This Deny has no effect with LinkDemand-protected code.");
}
catch (SecurityException e)
{
Console.WriteLine("This Deny protected the library.{0}",e);
}
}
}
}
O exemplo produz a seguinte saída.
Consulte também
Referência
CodeAccessPermission.PermitOnly
Conceitos
Substituindo as verificações de segurança