El código transparente en seguridad no debe hacer referencia a miembros críticos de seguridad no públicos
Actualización: noviembre 2007
Nombre de tipo |
SecurityTransparentCodeShouldNotReferenceNonpublicSecurityCriticalCode |
Identificador de comprobación |
CA2129 |
Categoría |
Microsoft.Security |
Cambio problemático |
Sí |
Motivo
Los métodos que se marcan con SecurityTransparentAttribute llaman a miembros no públicos marcados como SecurityCritical. SecurityTransparent es la designación predeterminada para los métodos.
Descripción de la regla
En .NET Framework 2.0 se incluyo 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 AppDomain del llamador o del host. Entre los ejemplos de elevaciones se incluyen Asserts, LinkDemands, SuppressUnmanagedCode y código no seguro.
El propósito de separar el código transparente del crítico es simplificar el proceso de auditoría de la seguridad. Las auditorías se realizan normalmente en puntos de entrada públicos debido a la oportunidad de uso público malintencionado que no es de confianza. Al marcar secciones más pequeñas de un ensamblado como críticas, la auditoría de la seguridad se puede reducir a los puntos de entrada públicos y a las secciones críticas de seguridad del código que elevan los privilegios. Sin embargo, para asegurarse de que la auditoría es precisa y completa, se debe exigir el límite entre el código transparente y el crítico tan estrictamente como sea posible. La alternativa sería permitir al código transparente llamar al código crítico de seguridad interna, que requiere auditar el código transparente más profundamente.
En tiempo de ejecución, el compilador Just-In-Time (JIT) de Common Language Runtime comprueba si el código transparente hace referencia o llama al código crítico de seguridad no público. Si se realiza una llamada del código transparente al código crítico no público, se produce una excepción como MethodAccessException. Esto se administra de forma similar a una clase que intenta tener acceso a los miembros privados de otra clase.
Esta regla del análisis de código analiza todos los métodos y tipos en un ensamblado que tiene una mezcla de transparente y crítico. Esta regla también marca cualquier llamada del código transparente a código crítico no público que no está marcado como SecurityTreatAsSafe.
Cómo corregir infracciones
Para resolver el problema, marque el código que llama al código SecurityCritical no público como SecurityCritical o marque el método o tipo de destino como SecurityTreatAsSafe. Esto trata eficazmente el código como público seguro y auditado para protegerlo contra fines malintencionados.
Cuándo suprimir advertencias
No suprima los mensajes de esta regla.
Ejemplo
Se producirá un error en el código siguiente porque SecondSecurityMethod es privado y SecurityCritical. Como ejemplo de un problema de seguridad, la aserción (Assert) en SecondSecurityMethod evitará que las demandas completas de acciones privilegiadas y las llamadas fluyan a FirstSecurityMethod, limitado a las comprobaciones de seguridad que se realizan en el llamador.
using System;
using System.Security.Permissions;
namespace SecurityTestClassLibrary
{
public class SecurityTestClass
{
// SecurityTransparent
public void FirstSecurityMethod()
{
SecondSecurityMethod();
}
[System.Security.SecurityCritical]
private void SecondSecurityMethod()
{
// Assert permissions
// do privileged actions, such as method call-outs
}
}
}
Si no se exigiera el límite transparente o crítico, FirstSecurityMethod podría realizar todas las acciones de SecondSecurityMethod sin comprobaciones de seguridad.
Una opción es revisar el código del método y, si el método se considera seguro para su elevación y seguro frente a ataques malintencionados, marcarlo con SecurityTreatAsSafe:
using System;
using System.Security.Permissions;
namespace SecurityTestClassLibrary
{
public class SecurityTestClass
{
// SecurityTransparent
public void FirstSecurityMethod()
{
SecondSecurityMethod();
}
[System.Security.SecurityTreatAsSafe]
[System.Security.SecurityCritical]
private void SecondSecurityMethod()
{
// Assert permissions
// do privileged actions, such as method call-outs
}
}
}
Otra opción es hacer que Method1 sea también crítico. Esto expande el kernel crítico del ensamblado y aumenta el tamaño de la auditoría de seguridad. También garantiza que se realice el correspondiente modelado de amenazas y el análisis de flujo del código.
using System;
using System.Security.Permissions;
namespace SecurityTestClassLibrary
{
public class SecurityTestClass
{
[System.Security.SecurityCritical]
public void FirstSecurityMethod()
{
SecondSecurityMethod();
}
[System.Security.SecurityCritical]
private void SecondSecurityMethod()
{
// Assert permissions
// do privileged actions, such as method call-outs
}
}
}