CA2147: Los métodos transparentes no pueden usar aserciones de seguridad
Nombre de tipo |
SecurityTransparentCodeShouldNotAssert |
Identificador de comprobación |
CA2147 |
Categoría |
Microsoft.Security |
Cambio problemático |
Sí |
Motivo
El código marcado como SecurityTransparentAttribute no tiene concedidos permisos suficientes para ser asertivo.
Descripción de la regla
Esta regla analiza todos los métodos y tipos de un ensamblado que es 100% transparente o tiene una mezcla de transparente y crítico, y marca cualquier uso declarativo o imperativo de Assert.
En tiempo de ejecución, cualquier llamada a Assert desde código transparente hará que se inicie una InvalidOperationException.Esto puede producirse tanto en los ensamblados 100% transparentes como en los ensamblados con mezcla de transparente y crítico donde un método o tipo se declara transparente pero incluye una aserción declarativa o imperativa.
En .NET Framework 2.0 se incluyó una característica denominada transparencia.Los métodos, campos, interfaces, clases y tipos individuales pueden ser transparentes o críticos.
El código transparente no puede elevar los privilegios de seguridad.Por consiguiente, cualquier permiso concedido o demandado pasa automáticamente a través del código al dominio de aplicación del llamador o del host.Entre los ejemplos de elevaciones se incluyen Asserts, LinkDemands, SuppressUnmanagedCode y código unsafe.
Cómo corregir infracciones
Para resolver el problema, marque el código que llama a la aserción con SecurityCriticalAttribute, o quite la aserción.
Cuándo suprimir advertencias
No suprima los mensajes de esta regla.
Ejemplo
Este código generará errores si SecurityTestClass es transparente cuando el método Assert inicia una InvalidOperationException.
using System;
using System.Security;
using System.Security.Permissions;
namespace TransparencyWarningsDemo
{
public class TransparentMethodsUseSecurityAssertsClass
{
// CA2147 violation - transparent code using a security assert declaratively. This can be fixed by
// any of:
// 1. Make DeclarativeAssert critical
// 2. Make DeclarativeAssert safe critical
// 3. Remove the assert attribute
[PermissionSet(SecurityAction.Assert, Unrestricted = true)]
public void DeclarativeAssert()
{
}
public void ImperativeAssert()
{
// CA2147 violation - transparent code using a security assert imperatively. This can be fixed by
// any of:
// 1. Make ImperativeAssert critical
// 2. Make ImperativeAssert safe critical
// 3. Remove the assert call
new PermissionSet(PermissionState.Unrestricted).Assert();
}
}
}
Una opción es revisar el código del método SecurityTransparentMethod en el ejemplo siguiente y, si el método se considera seguro para su elevación, marcar SecurityTransparentMethod con crítico para la seguridad. Esto requiere que se realice una auditoría de seguridad detallada y completa sin errores en el método junto con cualquier llamada que se produzca dentro del método bajo la Aserción:
using System;
using System.Security.Permissions;
namespace SecurityTestClassLibrary
{
public class SecurityTestClass
{
[System.Security.SecurityCritical]
void SecurityCriticalMethod()
{
new FileIOPermission(PermissionState.Unrestricted).Assert();
// perform I/O operations under Assert
}
}
}
Otra opción es quitar la aserción del código y permitir que todas las peticiones de permiso de E/S del archivo subsiguientes fluyan más allá de SecurityTransparentMethod hasta el llamador.Esto habilita las comprobaciones de seguridad.En este caso, generalmente no se necesita ninguna auditoría de seguridad porque las peticiones de permiso fluirán hasta el llamador y/o el dominio de aplicación.Las peticiones de permiso se controlan exhaustivamente mediante la concesión de permisos de directivas de seguridad, entornos de hospedaje y código fuente.