El código transparente de seguridad no debe ser asertivo
Actualización: noviembre 2007
Nombre de tipo |
SecurityTransparentCodeShouldNotAssert |
Identificador de comprobación |
CA2128 |
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 SecurityException. 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 como SecurityCritical 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 SecurityException.
using System;
using System.Security.Permissions;
namespace SecurityTestClassLibrary
{
public class SecurityTestClass
{
// SecurityTransparent
void SecurityTransparentMethod()
{
new FileIOPermission(PermissionState.Unrestricted).Assert();
// perform I/O operations under Assert
}
}
}
Una opción es revisar el código de [SecurityTransparentMethod] y, si [SecurityTransparentMethod] se considera seguro para su elevación, marcar [SecurityTransparentMethod] con [SecurityCritical]. Esto requiere que se realice una auditoría de seguridad detallada, completa y sin errores en [SecurityTransparentMethod] junto con todas las llamadas que se produzcan dentro de [SecurityTransparentMethod] 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 subsiguientes fluyan más allá de [SecurityTransparentMethod] hasta el llamador, lo que permite que se produzcan 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.