CA2107: Revisar el uso de Deny y PermitOnly
TypeName |
ReviewDenyAndPermitOnlyUsage |
Identificador de comprobación |
CA2107 |
Categoría |
Microsoft.Security |
Cambio problemático |
Problemático |
Motivo
Un método contiene una comprobación de seguridad que especifica una acción de seguridad PermitOnly o Deny.
Descripción de la regla
Las acciones de seguridad Utilizar el método PermitOnly y CodeAccessPermission.Deny solo deberían utilizarlas personas que tienen un conocimiento avanzado de la seguridad de .NET Framework.Debería realizarse una revisión de la seguridad del código que utiliza estas acciones de seguridad.
La acción Deny modifica el comportamiento predeterminado del recorrido de pila que se produce en respuesta a una demanda de seguridad.Permite especificar los permisos que no deben concederse durante la ejecución del método de denegación, sin tener en cuenta los permisos reales de los llamadores de la pila de llamadas.Si el recorrido de pila detecta un método protegido por Deny y el permiso solicitado está incluido en los permisos denegados, el recorrido de pila provoca un error.PermitOnly también modifica el comportamiento predeterminado del recorrido de pila.Permite al código especificar solo aquellos permisos que se pueden conceder sin tener en cuenta los permisos de los llamadores.Si el recorrido de pila detecta un método protegido por PermitOnly y el permiso solicitado no está incluido en los permisos especificados por PermitOnly, el recorrido de pila provoca un error.
El código basado en estas acciones se debería evaluar cuidadosamente para detectar vulnerabilidades de seguridad debido a su utilidad limitada y al comportamiento sutil.Considere el siguiente caso:
Peticiones de vínculos no se ven afectados por Deny o PermitOnly.
Si se producen Deny o PermitOnly en el mismo marco de pila como petición que provoca el recorrido de pila, las acciones de seguridad no tendrían ningún efecto.
Los valores que se utilizan para crear permisos basados en la ruta de acceso normalmente se pueden especificar de varias maneras.El acceso denegado a uno formulario de la ruta de acceso no deniega el acceso a todos los formularios.Por ejemplo, si un recurso compartido de archivos \\Server\Share se asigna a una unidad de red X:, para denegar el acceso a un archivo del recurso compartido, deberá denegar el acceso a \\Server\Share\File, X:\File o cualquier otra ruta que tenga acceso al archivo.
CodeAccessPermission.Assert puede finalizar un recorrido de pila antes de alcanzar Deny o PermitOnly.
Si Deny provoca un efecto, por ejemplo, cuando el llamador tiene un permiso bloqueado por Deny, el llamador puede obtener acceso directamente al recurso compartido omitiendo el permiso Deny.De forma similar, si el llamador no tiene el permiso denegado, se produciría un error en el recorrido de pila sin el permiso Deny.
Cómo corregir infracciones
Cualquier uso de estas acciones de seguridad provocará una infracción.Para corregir una infracción, no utilice estas acciones de seguridad.
Cuándo suprimir advertencias
Sólo suprima una advertencia de esta regla después de completar una revisión de seguridad.
Ejemplo
El ejemplo siguiente muestra algunas limitaciones de Deny.
La siguiente biblioteca contiene una clase con dos métodos que son idénticos salvo las peticiones de seguridad que los protegen.
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: ");
}
}
}
La aplicación siguiente muestra los efectos de Deny en los métodos protegidos de la 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);
}
}
}
}
Este ejemplo produce el siguiente resultado:
Vea también
Referencia
CodeAccessPermission.PermitOnly
Conceptos
Invalidar comprobaciones de seguridad