Seguridad de acceso del código para aplicaciones ASP.NET 4
La seguridad de acceso del código (SCA) es el mecanismo de seguridad de .NET Framework (el "espacio aislado") que usa ASP.NET para exigir restricciones en la capacidad de ejecutar código. ASP.NET ha implementado la seguridad de acceso del código desde ASP.NET 1.1 aplicando el concepto de los niveles de confianza.
En este tema se describe cómo funciona la seguridad de acceso del código (CAS) en ASP.NET 4 y se presta especial atención a los cambios experimentados desde las primeras versiones. Si ASP.NET es nuevo para usted, los cambios probablemente no serán de mucho interés. Sin embargo, se incluye información sobre cómo funciona la CAS en la versión actual de ASP.NET, lo que puede afectar al diseño de nuevas aplicaciones.
En este tema se tratan las siguientes materias:
Por qué ya no se utilizan los niveles de la directiva CAS y cómo afecta a los escenarios típicos en los que las aplicaciones ASP.NET de confianza parcial se ejecutan desde recursos compartidos UNC.
Cómo personalizar el comportamiento de la CAS en ASP.NET 4.
Problemas de compatibilidad cuando se permite que el código de confianza trabaje con CAS en ASP.NET 4.
En este tema se supone que conoce la CAS de .NET Framework y los niveles de confianza de ASP.NET. Para obtener más información sobre estos temas, vea los documentos siguientes:
Este tema contiene la siguiente información:
Información general sobre el modelo de seguridad de acceso del código de ASP.NET 4
Dominios de aplicación homogéneos
APTCA condicional
La transparencia de seguridad y su funcionamiento en ASP.NET 4
Información general sobre el modelo de seguridad de acceso del código de ASP.NET 4
En ASP.NET 4, se han efectuado varios cambios fundamentales en la CAS de ASP.NET 3.5 y versiones anteriores, a saber:
De forma predeterminada, los dominios de aplicación de confianza parcial de ASP.NET 4 son homogéneos. Esto produce un conjunto restringido de posibles conjuntos de permisos para el código que se está ejecutando en un dominio de aplicación de confianza parcial. También significa que el límite de confianza del dominio de aplicación está asociado a un conjunto de permisos concedidos de confianza parcial. En los dominios de aplicación homogéneos, la directiva de seguridad no interseca con las directivas CAS de los niveles de equipo, usuario o compañía.
Nota
El nuevo modelo de dominio de aplicación homogéneo requiere un conjunto ligeramente diferente de archivos de directivas de confianza ASP.NET declarativos que los archivos de directivas utilizados en versiones anteriores de ASP.NET.Como resultado, después de instalar ASP.NET 4, el equipo contiene dos conjuntos de archivos de directivas de confianza parcial de ASP.NET.El nuevo modelo de CAS usa uno de los conjuntos y el otro se usa cuando las aplicaciones se configuran para utilizar el modelo de CAS previo a ASP.NET 4.
En las versiones anteriores de ASP.NET, el atributo AspNetHostingPermission se empleaba en casi todas las clases públicas relacionadas con ASP.NET para evitar el uso de los tipos de ASP.NET en entornos de confianza parcial ajenos a Web. Por ejemplo, la presencia del atributo AspNetHostingPermission impedía el uso de la mayoría de las clases de ASP.NET en una aplicación ClickOnce de confianza parcial. (Para obtener más información sobre la CAS en aplicaciones ClickOnce, vea Seguridad de acceso del código para aplicaciones ClickOnce). En lugar de confiar en el atributo AspNetHostingPermission, ASP.NET 4 utiliza una tecnología de CAS diferente que se denomina APTCA condicional (se basa en el tipo AllowPartiallyTrustedCallersAttribute) para lograr el mismo resultado. Como resultado, el atributo AspNetHostingPermission se ha quitado de la mayoría de los tipos y los miembros de ASP.NET.
En ASP.NET 4, se han actualizado muchos de los ensamblados del sistema para utilizar el modelo de transparencia de seguridad de CLR. El modelo de la transparencia de ASP.NET 4 es muy similar al que se utiliza en Silverlight. Para obtener más información acerca de la transparencia del código, vea Código transparente en seguridad.
Verá los efectos de estos cambios si confiaba en directivas CAS de CLR personalizadas que se crearon con herramientas como caspol.exe. Los cambios también afectarán a las aplicaciones web de confianza parcial que confían en los ensamblados que se implementan en la GAC (caché global de ensamblados) para llevar a cabo operaciones con privilegios cuando solo el código de ASP.NET o de .NET Framework estaba activo en una pila de llamadas. En las siguientes secciones se tratan los cambios de la CAS.
Dominios de aplicación homogéneos
En esta sección se describen los dominios de aplicación homogéneos. Se comentan los cambios de comportamiento desde ASP.NET 2.0 para los dominios de aplicación homogéneos. También se comentan opciones de compatibilidad que se pueden establecer y los cambios en el código que se pueden realizar para ejecutar código en dominios de aplicación homogéneos.
Número reducido de conjuntos de permisos posibles
Los dominios de aplicación homogéneos son dominios de aplicación de confianza parcial que definen un conjunto de permisos compartido para ejecutar código. En un dominio de aplicación homogéneo hospedado en ASP.NET 4, el código que se puede cargar está asociado a uno de los dos conjuntos de permisos. El código se ejecuta con plena confianza (el código de la GAC siempre se ejecuta con plena confianza) o bien se ejecuta con el conjunto de permisos de confianza parcial definido por el valor de trustLevel. (Para obtener más información, vea Elemento trustLevel para securityPolicy (Esquema de configuración de ASP.NET)).
Nota
Los dominios de aplicación de ASP.NET 4 tienen como valor predeterminado la plena confianza.El comportamiento homogéneo en ASP.NET 4 solo surte efecto después de que el atributo de name del elemento trustLevel se establece en un valor distinto de Full.
Este comportamiento es diferente del de las aplicaciones de confianza parcial de versiones anteriores de ASP.NET. En las versiones anteriores, se podían crear varios conjuntos de permisos con conjuntos de permisos y condiciones de pertenencia diferentes. Los dominios de aplicación homogéneos se presentaron en .NET Framework 4 por la dificultad de controlar escenarios de permisos mixtos de este estilo. Era difícil crear varios conjuntos de permisos, cada uno con niveles diferentes de permisos y demostrar seguidamente que se exigían niveles de permisos diferentes, después de tener en cuenta todas las condiciones bajo las que el código se podría ejecutar. Por ejemplo, el código se podía ejecutar bajo reflexión, el código de plena confianza podía ejecutar otro código de plena confianza en nombre de un llamador de confianza parcial, etcétera. El conjunto de permisos tenía que responder de todas estas condiciones. Los dominios de aplicación homogéneos simplifican las decisiones sobre CAS inmensamente porque reducen los resultados posibles. El código tiene plena confianza o bien tiene un conjunto único y bien definido de permisos de confianza parcial. Para ASP.NET, el conjunto de permisos de confianza parcial bien definido es lo que se aplica a un nivel de confianza de ASP.NET especificado.
Hay un tercer posible estado para el código que intenta cargarse en un dominio de aplicación homogéneo. (El CLR no lo considera un conjunto de permisos independiente). El tercer conjunto de permisos es el conjunto de permisos vacío, que se define como el conjunto de permisos Nothing de todos los archivos de configuración de confianza parcial de ASP.NET. Todo código que evalúe el conjunto de permisos Nothing se considera descargable. Como resultado, todo intento de cargar ensamblados que tienen el conjunto de permisos Nothing en un dominio de aplicación homogéneo produce una excepción SecurityException.
Solo se aplica la directiva ASP.NET de confianza parcial
El host responsable de crear el dominio de aplicación establece el conjunto de permisos de confianza parcial de un dominio de aplicación homogéneo. En ASP.NET 4, esto significa que el contenido de un archivo de configuración de confianza parcial situado en el subdirectorio Config de la instalación de .NET Framework solo lo define el conjunto de permisos de confianza parcial. De forma predeterminada, la información sobre directivas ASP.NET para dominios de aplicación de confianza parcial de ASP.NET 4 no se superpone con los valores de configuración de directivas de CAS de usuario, equipo o compañía.
La información de la directiva de CAS global (la directiva que los desarrolladores controlaban previamente con herramientas como caspol.exe o la herramienta de configuración Mscorcfg.msc) ya no tiene influencia en dominios de aplicación homogéneos de ASP.NET 4. (Puede configurar ASP.NET para que use el modelo de CAS anterior, en el que la configuración de ASP.NET interseca con la directiva de empresa, equipo y de usuario. Este comportamiento heredado se explica en una sección posterior.)
El cambio más obvio es para las aplicaciones de confianza parcial de ASP.NET 4 hospedadas en UNC. En versiones anteriores, había que utilizar caspol.exe para elevar los recursos compartidos UNC a plena confianza y permitir que las directivas de confianza parcial de ASP.NET entraran en efecto. Esto se debía a que en versiones anteriores de ASP.NET, la directiva de CAS de CLR del nivel de equipo predeterminada entraba en efecto primero. Como resultado, las aplicaciones hospedadas en UNC tenían un conjunto de permisos restringido que se asociaba a la zona de intranet. Dado que los dominios de aplicación de confianza parcial de ASP.NET 4 solo establecen la directiva a partir de los archivos de directivas de ASP.NET, la ubicación física de una aplicación web ya no influye en el conjunto de permisos asociado a una aplicación de confianza parcial.
El escenario muestra un efecto secundario de este cambio donde un administrador desea bloquear un servidor web para denegar permisos de ejecución a todo el código administrado de forma predeterminada y, a continuación, conceder derechos de ejecución a las aplicaciones ASP.NET seleccionadas. En versiones anteriores de ASP.NET, esto requería una solución poco conocida, como se documenta en el artículo de la KB FIX: Error message when you try to run an ASP.NET 2.0 Web application if you do not associate the My_Computer_Zone code group with the "full trust" permission set: "Server Application Unavailable. En ASP.NET 4, un administrador puede bloquear un servidor web para denegar o conceder permisos de ejecución siguiendo estos pasos:
Cree un nivel de confianza de ASP.NET personalizado cuyo archivo de directivas asigne todo el código al conjunto de permisos Nothing (un conjunto de permisos vacío) y después configure todas las aplicaciones ASP.NET para que empleen ese nivel de confianza de forma predeterminada. (Esto se hace en la raíz del archivo Web.config).
Asocie selectivamente las aplicaciones ASP.NET individuales con niveles de confianza integradas o personalizadas que conceden permisos de ejecución (y el resto de permisos necesarios) al código administrado. Para el cumplimiento en el ámbito de equipo, asigne los niveles de confianza utilizando los elementos location en el archivo raíz Web.config.
Ubicación y convenciones de nomenclatura para archivos de directivas de confianza
La ubicación y la convención de nomenclatura de los archivos de directiva de CAS es la misma que en versiones anteriores de ASP.NET. Los niveles de confianza predeterminados son Full, High, Medium, Low y Minimal. Los archivos de directivas que definen los conjuntos de permisos de confianza parcial para High a través de Minimal se encuentran situados en el subdirectorio Config del directorio de instalación de .NET Framework.
Los nombres de los archivos de directivas siguen el siguiente modelo:
web_[trustlevelname]trust.config
Por ejemplo, el conjunto de permisos de confianza parcial para la confianza Medium está en el archivo denominado web_mediumtrust.config.
Cambios en los archivos de directivas se seguridad para ASP.NET 4
En su mayor parte, la información de los archivos de directiva de CAS de ASP.NET 4 es igual que la encontrada en los archivos de directivas de versiones anteriores. Sin embargo, se han hecho pequeñas aportaciones para la funcionalidad de .NET Framework 3.5 y de .NET Framework 4. El nombre del conjunto de permisos de confianza parcial asociado a un dominio de aplicación homogéneo es ASP.Net. Además, de forma predeterminada, todo el código que se encuentra en una estructura de directorios de aplicación web o en la estructura de directorios de generación de código tiene concedidos los permisos para el conjunto de permisos ASP.Net con nombre.
Hay dos cambios con respecto a las versiones anteriores de los archivos de directiva de confianza parcial:
Al final de cada archivo de directiva de CAS de ASP.NET 4, ya no hay un elemento CodeGroup que asigna con plena confianza a una clave de firma de Microsoft y a la clave de firma de ECMA. Estas entradas se quitaron de ASP.NET 4 porque se heredaron de versiones anteriores cuando no siempre se suponía implícitamente que la GAC tuviera plena confianza.
La parte Assertion del atributo SecurityPermission se ha quitado de todos los archivos de directiva de CAS de ASP.NET 4. Uno de los cambios fundamentales realizados por CLR en .NET Framework 4 es que el código de confianza parcial no puede validar permisos. Esto significa que el código de confianza parcial dará error si intenta validar permisos que ya tiene.
Ámbito de la confianza parcial
Los dominios de aplicación homogéneos significan que los límites del dominio de aplicación de ASP.NET 4 tienen confianza parcial. Cuando una aplicación se ejecuta con confianza parcial, la seguridad exige el resultado en un recorrido de pila. Todo el código de la pila se evalúa en función de los permisos exigidos. En los dominios de aplicación de ASP.NET 3.5 y versiones anteriores, era habitual que las rutas de acceso del código dieran como resultado un recorrido de pila hasta el límite del dominio. Dado que los límites de dominio de aplicación de las versiones anteriores de ASP.NET 4 tenían implícitamente plena confianza, los recorridos de pila para algunas rutas de acceso del código se realizaban satisfactoriamente. En los dominios de aplicación homogéneos de ASP.NET 4, cualquier recorrido de pila que alcance el límite del dominio de aplicación evaluará con el conjunto de permisos de confianza parcial que está actualmente en vigor para el dominio de aplicación.
El hecho de que el límite de dominio de aplicación sea ahora de confianza parcial es el cambio más común de la CAS que, por lo general, exige cambiar el código de plena confianza para que funcione en ASP.NET 4. Por ejemplo, el equipo de desarrollo de ASP.NET tenía que agregar aserciones de seguridad de destino en numerosas rutas de acceso del código internas para suprimir las demandas de seguridad y evitar su propagación hasta el límite del dominio de aplicación. Si el equipo de desarrollo no lo hubiera hecho, se habría producido un error en tareas básicas como la compilación de páginas porque las demandas de seguridad para tales operaciones (por ejemplo, permisos de E/S de archivos para la compilación) habrían dado error al compararse con el conjunto de permisos de confianza parcial de niveles de confianza como Medium.
Hay puntos de extensibilidad dentro de ASP.NET que pueden llevar al código de plena confianza a cargarse y ejecutarse solo cuando en la pila hay código de ASP.NET. Solo en estos escenarios, el código de ASP.NET está inicialmente en la pila cuando ASP.NET llama a un tipo personalizado que implementa algún tipo de punto de extensibilidad. Si el tipo personalizado es de plena confianza (algo que solo debería ocurrir si el tipo se implementa en la GAC), el resultado es que la pila de llamadas completa se compone de código de plena confianza. En un dominio de aplicación homogéneo, si cualquier código de un tipo de extensibilidad de plena confianza activa una demanda de seguridad, esa demanda terminará alcanzando el límite de dominio de aplicación. Después se producirá un error cuando tenga lugar la comprobación de seguridad con el conjunto de permisos de confianza parcial.
A continuación se incluye una lista de algunos puntos de extensibilidad de ASP.NET en los que esta situación es posible:
Controlador HTTP personalizado. Un controlador personalizado se invoca durante la fase de ejecución del controlador de la canalización.
Módulo HTTP personalizado. Un módulo HTTP personalizado se invoca durante los eventos de canalización para los que el módulo se registró.
Proveedores de compilación personalizados y generadores de expresiones. ASP.NET invocará estos tipos cuando analice y compile contenido ejecutable, como los archivos .aspx.
Proveedor de administrador de roles. Un proveedor personalizado se puede invocar durante el evento AuthorizeRequest en la canalización.
Proveedor de perfiles. Un proveedor personalizado se puede invocar para guardar los datos del perfil durante el evento EndRequest automáticamente.
Proveedor de supervisión de estado. Un proveedor personalizado se puede invocar en momentos arbitrarios para almacenar los datos de supervisión de estado acumulados.
Un ejemplo sencillo de un controlador HTTP personalizado muestra el cambio en el comportamiento de la CAS. En el siguiente ejemplo, el código del controlador intenta leer un archivo de texto que se encuentra en la raíz de la unidad C:\.
Public Class CustomHandler
Implements IHttpHandler
Public Sub ProcessRequest(ByVal context As HttpContext)
Dim data As String = File.ReadAllText("c:\testfile.txt")
context.Response.Write(data)
End Sub
Public Sub New()
End Sub
Public ReadOnly Property IsReusable() As Boolean
Get
Return False
End Get
End Property
End Class
public class CustomHandler : IHttpHandler
{
public void ProcessRequest(HttpContext context)
{
string data = File.ReadAllText("c:\\testfile.txt");
context.Response.Write(data);
}
public CustomHandler() { }
public bool IsReusable { get { return false; } }
}
Si el controlador está firmado, se marca con el atributo AllowPartiallyTrustedCallersAttribute y se implementa en la GAC, el código tendrá éxito cuando el controlador se use en una aplicación de nivel de confianza medio en ASP.NET 3.5 o anterior. El nivel de confianza medio se elige para este ejemplo porque en él, el conjunto de permisos de confianza parcial solo permite E/S de archivo de lectura y escritura a la estructura de directorios de la aplicación. El código de plena confianza, como el controlador del ejemplo, tiene acceso a otras ubicaciones de archivos en ASP.NET 3.5 y anteriores. Esto es porque cuando el controlador se ejecuta, solo hay en la pila código de plena confianza y el límite de dominio de aplicación es de plena confianza. Como resultado, la demanda de E/S de archivos desde la llamada a ReadAllText la satisface implícitamente el límite del dominio de aplicación al ser de plena confianza.
Sin embargo, si el mismo código del controlador se utiliza en una aplicación ASP.NET 4 con nivel de confianza medio, se producirá un error, porque la llamada a ReadAllText da como resultado una demanda de E/S de archivos para el acceso de lectura al archivo de texto. La demanda de E/S de archivos dará como resultado un recorrido de pila que finalmente alcanza el límite del dominio de aplicación. En ASP.NET 4, el límite del dominio de aplicación está asociado al conjunto de permisos de nivel de confianza medio y ese conjunto de permisos no permite el acceso a la raíz de la unidad C: \. Por consiguiente, la demanda E/S de archivos dará error.
Para ASP.NET 4, debe suprimir el recorrido de pila. Para hacerlo, use el atributo SecurityAction.Assert del atributo FileIOPermission en el método ProcessRequest. En el ejemplo siguiente se muestra cómo usar un atributo FileIOPermission con este fin.
[Visual Basic]
Public Class CustomHandler
Implements IHttpHandler
<FileIOPermission(SecurityAction.Assert, Read = "c:\testfile.txt")> _
Public Sub ProcessRequest(ByVal context As HttpContext)
Dim data As String = File.ReadAllText("c:\testfile.txt")
context.Response.Write(data)
End Sub
Public Sub New()
End Sub
Public ReadOnly Property IsReusable() As Boolean
Get
Return False
End Get
End Property
End Class
[C#]
public class CustomHandler : IHttpHandler
{
[FileIOPermission(SecurityAction.Assert, Read = "c:\\testfile.txt")]
public void ProcessRequest(HttpContext context)
{
string data = File.ReadAllText("c:\\testfile.txt");
context.Response.Write(data);
}
public CustomHandler() { }
public bool IsReusable { get { return false; } }
}
Puede utilizar aserciones declarativas (como se muestra en el ejemplo) o de programación. Es un procedimiento recomendado para confirmar mediante declaración los permisos más restringidos que se exigen para lograr que un bloque de código funcione. Aunque agregar aserciones de seguridad sin restricciones por todas partes parezca una solución sencilla, es un planteamiento que no se debe utilizar. Los errores de seguridad que causa el nuevo comportamiento del dominio de aplicación homogéneo se diseñaron para exigir el análisis del código de plena confianza y para entender qué operaciones de privilegio requiere el código de plena confianza. A continuación puede confirmar el conjunto más restringido de permisos que se exigen para volver a habilitar el código de plena confianza.
Configurar aplicaciones de ASP.NET 4 para utilizar el modelo de CAS de ASP.NET 2.0
Es posible configurar aplicaciones de ASP.NET 4 para utilizar los comportamientos de la CAS de ASP.NET 1.0 y ASP.NET 2.0. En ASP.NET 4, el elemento trust proporciona un nuevo atributo legacyCasModel, que está establecido de forma predeterminada en false. Al establecer este atributo en true, se configura una aplicación de ASP.NET 4 que usa la mayor parte (aunque no todo) el comportamiento de la CAS de las versiones anteriores de ASP.NET.
Cuando el atributo LegacyCasModel está establecido en true, se producen los siguientes comportamientos:
Los límites de dominio de aplicación de confianza parcial utilizan la plena confianza. Esto significa que los escenarios donde el código de plena confianza se ejecuta solo con código de plena confianza en la pila, no tiene que utilizar aserciones para suprimir las demandas de seguridad.
La configuración de directivas de CAS del usuario, empresa y equipo que se definen para .NET Framework 4 interseca con la directiva de CAS de ASP.NET. Esto significa que surte efecto todo permiso personalizado que se cree utilizando caspol.exe de .NET Framework 4 o Mscorcfg.msc.
Nota
Dado que los archivos de directiva de seguridad base y la herramienta caspol.exe para .NET Framework 4 están en un directorio diferente que los de .NET Framework 2.0, cualquier directiva de seguridad personalizada que se creara para .NET Framework 2.0 se debe volver a crear para .NET Framework 4 con la versión .NET Framework 4 de caspol.exe.
Puede especificar varios conjuntos de permisos personalizados para aplicar a ensamblados diferentes.
Los siguientes comportamientos relacionados con CAS ni siquiera cambian en modo CAS heredado:
Los ensamblados de ASP. de .NET 4 todavía se marcan como APTCA condicional. (APTCA condicional se describe más adelante en este tema.) APTCA condicional no se puede revertir al modo heredado porque implicaría quitar el atributo AspNetHostingPermission de la mayoría de las API públicas de ASP.NET 4. No hay ninguna manera eficaz de aplicar ese permiso a las API públicas de ASP.NET cuando se están ejecutando en modo CAS heredado y no aplicarlas cuando los ensamblados se ejecutan en el nuevo modelo de CAS.
Ya no se permite que el código de confianza parcial compruebe ningún permiso. El código al que previamente se le concedió confianza parcial podría llamar al método Assert y comprobar cualquier permiso que ya se hubiera concedido al código de confianza parcial. En .NET Framework 4, con independencia del modelo de CAS que esté en efecto para una aplicación ASP.NET, no se permite al código de confianza parcial realizar comprobaciones de seguridad.
Para distinguir los conjuntos de permisos que se aplican en el modelo de CAS heredado del conjunto de permisos único que se aplica en el nuevo modelo de CAS, cuando el atributo LegacyCasModel del elemento trust está establecido en true, ASP.NET 4 lee la directiva de CAS de un conjunto diferente de archivos de configuración de confianza parcial. Por cada archivo de directiva de confianza que existe para los niveles de confianza integrados de ASP.NET, existen dos versiones del archivo. ASP.NET lee una versión para el nuevo modelo de CAS y lee la otra versión para el modelo heredado. Por ejemplo, con el nivel de confianza medio, cuando ASP.NET 4 se ejecuta en modo heredado, lee el archivo de directivas denominado legacy.web_mediumtrust.config. Observe que el principio del nombre de archivo es "legacy". ASP.NET 4 utiliza la misma convención de nomenclatura para todos los archivos de directiva de CAS en lo referente a los niveles de confianza integrados de ASP.NET. La diferencia básica entre los archivos de directiva de CAS heredados y no heredados es que los archivos heredados incluyen la definición CodeGroup que hace referencia a la clave de firma de Microsoft y a la clave de firma ECMA.
Dado que se puede configurar una aplicación para que use el modelo anterior de CAS, con las aplicaciones existentes, puede interesar establecer la opción LegacyCasModel en true y evitar así los cambios. Sin embargo, es importante entender que la opción heredada exista principalmente para aliviar la transición de las aplicaciones existentes al modelo de CAS de ASP.NET 4. En el futuro, ambos equipos de ASP.NET y CLR se centrarán en diseñar y codificar con el nuevo modelo de CAS.
Silverlight 2 fue el primera área de características del .NET Framework que pasó al nuevo modelo. El objetivo de .NET Framework es mover todos los escenarios de confianza parcial de servidor y de escritorio para que se ejecuten en el nuevo modelo de CAS. Como resultado, recomendamos invertir en volver a habilitar las aplicaciones para trabajar en el modelo de CAS. De igual forma, los administradores que previamente confiaron en caspol.exe y Mscorcfg.msc deben confiar en personalizar los archivos de directivas de confianza parcial y las asignaciones de permisos de ASP.NET.
Personalizar la asignación del conjunto de permisos en el modelo de CAS de ASP.NET 4
Aunque los dominios de aplicación homogéneos de ASP.NET 4 restringen el código a plena confianza o al conjunto de permisos de confianza parcial de ASP.NET con nombre, los desarrolladores y los administradores pueden influir en el proceso por el que un conjunto de permisos se asocia a un ensamblado. Los siguientes enfoques permiten personalizar el proceso de asociar un conjunto de permisos a una parte de código en ejecución:
Se puede personalizar el archivo de directivas de confianza parcial para un nivel de confianza individual. (Este enfoque era posible en versiones anteriores de ASP.NET).
Puede configurar ensamblados de plena confianza de ASP.NET 4 estáticamente.
Puede utilizar el tipo HostSecurityPolicyResolver de ASP.NET 4 para tener acceso a la funcionalidad de la clase HostSecurityManager de CLR de una manera restringida.
Los dos primeros enfoques permiten hacer personalizaciones mediante declaración y la tercera opción permite hacer personalizaciones en el código.
Personalizar los archivos de directivas para un nivel de confianza
El primer enfoque para modificar los archivos de directivas de confianza parcial de ASP.NET es el mismo que en versiones anteriores de ASP.NET: se puede modificar el conjunto de permisos en el conjunto de permisos denominado ASP.NET. También puede agregar más definiciones CodeGroup que tienen condiciones de pertenencia personalizadas. Tal y como se señaló anteriormente, las nuevas personalizaciones de la CAS se deben realizar en archivos de directivas de confianza parcial, como web_mediumtrust.config. Los archivos que comienzan con "legacy" en el nombre se analizan y se utilizan cuando el atributo LegacyCasModel del elemento trust está establecido en true.
Con ASP.NET 4, todas las definiciones CodeGroup personalizadas deben asignarse a uno de los tres posibles conjuntos de permisos: FullTrust, ASP.Net (es decir, el conjunto de permisos de confianza parcial) o Nothing. Dado que los dominios de aplicación de confianza parcial de ASP.NET 4 son homogéneos de forma predeterminada, las entradas de la directiva personalizada se deben evaluar como un conjunto restringido de conjuntos de permisos. Aunque parezca que puede definir conjuntos de permisos con nombres diferentes cuando usa el modelo de CAS de ASP.NET 4, cualquier código que se evalúe con un conjunto de permisos que no sea FullTrust, ASP.Neto Nothing producirá una excepción SecurityException en tiempo de ejecución. Esto indica que el CLR no reconoció el conjunto de permisos evaluado.
El conjunto de permisos FullTrust indica que el código se ejecuta en plena confianza. El conjunto de permisos ASP.Net es el conjunto de permisos de confianza parcial con nombre que se utiliza normalmente en dominios de aplicación de confianza parcial. Como se ha descrito anteriormente, Nothing no es un conjunto de permisos real reconocido por CLR, más bien, el conjunto de permisos vacío. Si el CLR determina que un ensamblado está asociado a un conjunto de permisos vacío, produce una excepción SecurityException y no carga el ensamblado.
Además, ASP.NET 4 permite cambiar el nombre del conjunto de permisos ASP.Net mediante el atributo PermissionSetName del elemento trust. Puede establecer un nombre diferente para el atributo PermissionSetName. En tiempo de ejecución, ASP.NET 4 buscará un elemento PermissionSet del mismo nombre en el archivo de directivas de confianza parcial. Ese conjunto de permisos con nombre se utilizará después como el conjunto de permisos de confianza parcial para un dominio de aplicación homogéneo. No es probable que haya necesidad de hacerlo. Sin embargo, se agregó la capacidad de cambiar el nombre del conjunto de permisos de confianza parcial por algo distinto de ASP.Net para hospedar entornos host como SharePoint, que definen su propio conjunto de permisos con nombre como una entidad distinta del conjunto de permisos predeterminado de ASP.NET. (Se debe recordar que en el nuevo modelo de la CAS ya no es posible tener varios conjuntos de permisos con nombre para definir permisos de confianza parcial.) Aunque puede cambiar el nombre del conjunto de permisos de confianza parcial por algo distinto de ASP.Net, solo puede haber en efecto un único conjunto de permisos de confianza parcial para una aplicación.
Especificar los ensamblados a los que se concederá plena confianza
La segunda personalización de la directiva declarativa es nueva en ASP.NET 4 y permite establecer explícitamente una lista de identidades de ensamblado que siempre tendrán plena confianza. La configuración securityPolicy contiene una nueva sección de configuración fullTrustAssemblies secundaria. La sección FullTrustAssembliesSection es una colección estándar que admite operaciones de agregar, quitar y eliminar, y donde se pueden especificar una o más identidades de ensamblado a las que se concederá plena confianza en tiempo de ejecución. En el ejemplo siguiente se muestra una sección de configuración fullTrustAssemblies.
<system.web>
<securityPolicy>
<fullTrustAssemblies>
<add assemblyName="MyCustomAssembly"
version="1.0.0.0"
publicKey="a 320 hex character representation
of the public key blob used with a
signed assembly"
/>
</fullTrustAssemblies>
</securityPolicy>
</system.web>
Cada entrada del elemento fullTrustAssemblies identifica un ensamblado por su nombre y versión de ensamblado, y por una cadena de 320 caracteres que es la representación de caracteres hexadecimales de la mitad pública de la clave de firma.
Nota
En el futuro, los nuevos ensamblados NET Framework tal vez usen claves de firma de 2048 bits.Si se lanzan al mercado nuevos ensamblados que usan claves de firma de 2048 bits, se producirán cadenas hexadecimales de 576 caracteres de longitud.
En la definición no se especifica ninguna ubicación de ensamblado. Es decisión del entorno de hospedaje individual (como ASP.NET 4) buscar y cargar ensamblados. Si un ensamblado cargado coincide con la información contenida en uno de los elementos add en fullTrustAssemblies, al ensamblado se le concede plena confianza.
Debe usar fullTrustAssemblies para los ensamblados que no se implementan en la GAC, pero esos están pensados para ejecutarse siempre con plena confianza. Dado que los ensamblados enumerados en fullTrustAssemblies se puede personalizar en cualquier punto de la jerarquía de configuración (del archivo raíz Web.config a los archivos Web.config de la capa individual de aplicaciones), es más fácil y más flexible utilizar este valor para conceder plena confianza que usar una condición de pertenencia y un grupo de código en un archivo de directivas de confianza parcial. Puede personalizar las listas fullTrustAssemblies para aplicaciones individuales especificando información diferente para aplicaciones diferentes. Esto se puede hacer en archivos Web.config de la capa de aplicaciones o en el archivo raíz Web.config usando los elementos location.
El conjunto de ensamblados de plena confianza se establece inmediatamente en el momento que se crea un dominio de aplicación de confianza parcial. Consecuentemente, si un archivo de directiva de confianza parcial incluye información que da como resultado un conjunto de permisos concedidos diferente para un ensamblado que aparece en el elemento fullTrustAssemblies, se pasa por alto la información y se concede al ensamblado plena confianza.
Personalizar permisos mediante programación
También puede cambiar mediante programación la asociación de un conjunto de permisos a un ensamblado creando una implementación personalizada del tipo HostSecurityPolicyResolver de ASP.NET 4. En tiempo de ejecución, ASP.NET 4 utiliza su propia implementación del tipo HostSecurityManager de CLR. CLR llama a un objeto HostSecurityManager cada vez que se carga un ensamblado. Una de las funciones de la propiedad HostSecurityManager es devolver un objeto PermissionSet que debe estar asociado con un ensamblado especificado y para un conjunto de pruebas. ASP.NET 4 permite personalizar este proceso llamando a un objeto HostSecurityPolicyResolver personalizado cada vez que CLR pide a ASP.NET 4 una decisión para un conjunto de permisos.
Puede configurar un objeto HostSecurityPolicyResolver personalizado mediante el atributo HostSecurityPolicyResolverType del elemento trust. Si ASP.NET 4 determina que un objeto HostSecurityPolicyResolver personalizado se configura para una aplicación, llama al método ResolvePolicy de la resolución personalizada cada vez que CLR pide una decisión del conjunto de permisos. Sin embargo, a diferencia de un objeto HostSecurityManager, un objeto HostSecurityPolicyResolver solo puede devolver un conjunto restringido de posibles decisiones a ASP.NET 4. El valor devuelto por el método ResolvePolicy debe ser uno de estos valores de la enumeración HostSecurityPolicyResults:
DefaultPolicy. Esto especifica que ASP.NET 4 debe utilizar su lógica para determinar el conjunto de permisos adecuado para el ensamblado. Debe devolver DefaultPolicy para los ensamblados en los que no desea que el objeto HostSecurityPolicyResolver tome una decisión sobre el conjunto de permisos. Devolver DefaultPolicy hace que ASP.NET determine el conjunto de permisos concedidos de un ensamblado basado en los grupos de código declarativo y en las condiciones de pertenencia que se definen en el archivo de directivas de confianza parcial para el nivel de confianza actual de ASP.NET.
FullTrust. Al ensamblado se debe conceder plena confianza.
AppDomainTrust. Al ensamblado se debe permitir conjunto de permisos de confianza parcial que está asociado con el dominio de aplicación. Normalmente esto significa que al ensamblado se le concederán los permisos que se definen en el conjunto de permisos ASP.Net con nombre.
None. El conjunto de permisos para el ensamblado se establecerá en el conjunto de permisos Nothing que es un
Como la clase base HostSecurityPolicyResolver tiene una petición de herencia de permiso de seguridad sin restricciones, y un objeto HostSecurityPolicyResolver personalizado tiene que ser cargable sin exigir a otro objeto HostSecurityPolicyResolver que establezca la plena confianza, las implementaciones concretas de una clase HostSecurityPolicyResolver se deben firmar e implementar siempre en la GAC.
En el siguiente ejemplo se muestra un objeto HostSecurityPolicyResolver personalizado que concede plena confianza a todos los ensamblados que se cargan de un directorio concreto. Este podría ser un escenario para que las organizaciones que agregan ensamblados compilados en una ubicación concreta del disco (no la GAC) y que desean que todos los archivos de esa ubicación se ejecuten automáticamente con plena confianza. Para que las aplicaciones ASP.NET carguen ensamblados de fuera de la estructura de directorios de una aplicación web, debe agregar redirecciones explícitas de enlace de ensamblados que asocien las identidades del ensamblado con ubicaciones del disco físico diferentes.
[Visual Basic]
Public Class MyCustomResolver
Inherits HostSecurityPolicyResolver
Public Overloads Overrides Function ResolvePolicy(ByVal evidence _
As Evidence) As HostSecurityPolicyResults
Dim urlEvidence As Url = evidence.GetHostEvidence(Of Url)()
If (urlEvidence IsNot Nothing) AndAlso _
(urlEvidence.Value.StartsWith("file:///C:/FullTrustExample_HSPR.dll")) Then
Return HostSecurityPolicyResults.FullTrust
End If
' Specify that ASP.NET should perform its own logic.
Return HostSecurityPolicyResults.DefaultPolicy
End Function
End Class
public class MyCustomResolver : HostSecurityPolicyResolver
{
public override HostSecurityPolicyResults
ResolvePolicy(Evidence evidence)
{
Url urlEvidence = evidence.GetHostEvidence<Url>();
if ( (urlEvidence != null) &&
(urlEvidence.Value.StartsWith("file:///C:/FullTrustExample_HSPR.dll"))
)
return HostSecurityPolicyResults.FullTrust;
// Specify that ASP.NET should perform its own logic.
return HostSecurityPolicyResults.DefaultPolicy;
}
}
APTCA condicional
En versiones de .NET Framework anteriores a la versión 4, muchos ensamblados de plena confianza (incluidos los ensamblados de ASP.NET) se marcaron con el atributo AllowPartiallyTrustedCallersAttribute (APTCA). Este atributo da acceso a los llamadores de confianza parcial a los tipos y miembros públicos que se definen en los ensamblados marcados de esta manera. En .NET Framework 4, el CLR incluye una variación de APTCA que se conoce como APTCA condicional. (La notación abreviada de APTCA condicional es C-APTCA). APTCA condicional habilita los ensamblados que se marcan con el atributo APTCA para retener las características APTCA en algunos entornos alojados en host únicamente. Como resultado, APTCA condicional facilita que ASP.NET 4 controle exactamente en qué llamadores de confianza parcial de entornos de host de confianza parcial podrá llamar correctamente a las API públicas de ASP.NET 4.
Cómo funciona APTCA condicional
Tanto los entornos de host de confianza parcial como los ensamblados de plena confianza desempeñan una parte para que APTCA condicional funcione. Los entornos de host de confianza parcial donde los conjuntos de permisos son importantes pueden proporcionar al CLR una lista de ensamblados que siempre deben admitir la configuración APTCA. Los ensamblados de plena confianza que deben tener las características APTCA habilitadas solo en algunos entornos del host indican esto mediante el uso de la siguiente variación del atributo APTCA del nivel de ensamblado:
[assembly: AllowPartiallyTrustedCallers(PartialTrustVisibilityLevel=NotVisibleByDefault)]
En tiempo de ejecución, cuando se solicita que el CLR cargue un ensamblado que se marca condicionalmente como APTCA, el CLR comprobará la lista de ensamblados válidos de APTCA condicional que proporciona el entorno del host. Si el ensamblado está en la lista, el CLR tratará todo el código públicamente expuesto en el ensamblado como si el ensamblado se hubiera marcado con el atributo APTCA en versiones anteriores de .NET Framework.
Si un ensamblado de APTCA condicional no está en la lista del entorno del host de ensamblados que se deben tratar como APTCA, se carga el ensamblado, pero sin las características APTCA. La disponibilidad real de las API públicas para el código de usuario de confianza parcial en este tipo de ensamblado variará en función de si el ensamblado es 100% transparente en seguridad o no lo es. Es decir, depende de si el ensamblado se marca con un atributo SecurityTransparentAttribute del nivel de ensamblado. (La transparencia en seguridad en ASP.NET 4 se describe más adelante en este tema).
En resumen, las API públicas de ASP.NET 4 se comportan de una de las siguientes maneras:
En la mayoría de los ensamblados de ASP.NET, todas las API públicas no están disponibles para los llamadores de confianza parcial. En efecto, esto evita que la mayoría de las API públicas de ASP.NET 4 se empleen en entornos de confianza parcial que no son aplicaciones web.
Los llamadores de la confianza parcial aún pueden llamar a unos cuantos ensamblados de ASP.NET que se marcan como 100% transparentes en seguridad. Sin embargo, si las rutas de acceso del código de esos ensamblados llegan finalmente al resto del código base de ASP.NET, las llamadas darán error. El resultado es el mismo comportamiento que en versiones anteriores de ASP.NET, con la pequeña diferencia de que las llamadas a las API en ensamblados de ASP.NET 4 progresará más antes de dar error.
Tenga en cuenta lo siguiente sobre los ensamblados que se marcan como transparentes en seguridad:
Hay solo dos ensamblados de ASP.NET que se marcan como transparentes en seguridad en el nivel de ensamblados: System.Web.DynamicData.dll y System.Web.RegularExpressions.dll.
System.Web.Routing.dll no está considerado 100% transparente en seguridad en ASP.NET 4 porque todos los tipos que se definieron en ese ensamblado en versiones anteriores de ASP.NET se pasaron a System.Web.dll. En efecto, en ASP.NET 4, System.Web.Routing.dll es un ensamblado de solo metadatos.
En ASP.NET 4, la variación del atributo APTCA condicional se encuentra en los siguientes ensamblados:
System.Web.dll
System.Web.Extensions.dll
System.Web.DynamicData.dll
System.Web.DataVisualization.dll
System.ComponentModel.DataAnnotations.dll
System.Web.ApplicationServices.dll. Este ensamblado es nuevo en ASP.NET 4.
System.Web.Abstractions.dll. Los tipos de este ensamblado se movieron a System.Web.dll en ASP.NET 4.
System.Web.Routing.dll. Los tipos de este ensamblado se movieron a System.Web.dll en ASP.NET 4.
APTCA condicional en comparación con los atributos de los permisos de hospedaje en ASP.NET
Gracias a APTCA condicional resulta práctico quitar el atributo AspNetHostingPermission del 99% de las API públicas en ASP.NET 4. El atributo AspNetHostingPermission se sigue utilizando en algunas partes de ASP.NET 4, pero solo en las que el intento del permiso tiene realmente sentido. En el resto, los dos siguientes usos del atributo AspNetHostingPermission han desaparecido:
<AspNetHostingPermission(SecurityAction.LinkDemand,
Level=AspNetHostingPermissionLevel.Minimal)>
<AspNetHostingPermission(SecurityAction.InheritanceDemand,
Level=AspNetHostingPermissionLevel.Minimal)>
[AspNetHostingPermission(SecurityAction.LinkDemand,
Level=AspNetHostingPermissionLevel.Minimal)]
[AspNetHostingPermission(SecurityAction.InheritanceDemand,
Level=AspNetHostingPermissionLevel.Minimal)]
Estas definiciones de los permisos se utilizaron en versiones anteriores de ASP.NET para evitar que los ensamblados de ASP.NET se cargaran en entornos de confianza parcial que no son de Web. El principal entorno de preocupación fueron las aplicaciones administradas y los controles administrados con confianza parcial que se cargaban en exploradores como Microsoft Internet Explorer y Mozilla Firefox. Con el uso de APTCA condicional, las mismas protecciones se aplican eficazmente, porque las aplicaciones ClickOnce y los controles administrados basados en explorador no definen ningún ensamblado de APTCA condicional para un tratamiento como APTCA completo.
Personalizar la lista de APTCA condicional de ASP.NET 4
Como se ha mencionado antes, los entornos de host individuales pueden proporcionar al CLR una lista de ensamblados de APTCA condicional cuyas características APTCA se deben admitir. ASP.NET 4 proporciona al CLR una lista incluida en el código con todos los ensamblados de ASP.NET 4. Si ASP.NET 4 no hiciera esto, se produciría un error inmediato en las aplicaciones web cuando la primera línea de código interno de ASP.NET intentara ejecutarse en un dominio de aplicación de confianza parcial.
En .NET Framework 4, APTCA condicional es un nuevo concepto de la CAS no implementado todavía en otras partes de .NET Framework. Por consiguiente, es probable que las versiones futuras de .NET Framework incluyan más ensamblados de APTCA condicional. Además, a medida que se es consciente de APTCA condicional y se utiliza con ensamblados propios de plena confianza, el conjunto de ensamblados de APTCA del condicional crecerá. Dado que es imposible que ASP.NET 4 conozca todos posibles ensamblados de APTCA condicional de antemano, ASP.NET 4 incluye una sección de configuración en la que se pueden agregar ensamblados de APTCA condicional.
La sección securityPolicy existente tiene una sección de configuración secundaria denominada partialTrustVisibleAssemblies. Esta es una colección estándar que admite las operaciones de agregar, quitar y eliminar, y donde puede especificar una o más identidades de ensamblado que se deben tratar como APTCA (si también se marcan para APTCA condicional). En el ejemplo siguiente se muestra una sección partialTrustVisibleAssemblies.
<system.web>
<securityPolicy>
<partialTrustVisibleAssemblies>
<add assemblyName="MyCustomAssembly"
publicKey="a 320 hex character representation
of the public key blob used with a
signed assembly"
/>
</partialTrustVisibleAssemblies>
</securityPolicy>
</system.web>
Cada entrada de la sección partialTrustVisibleAssemblies identifica un ensamblado por su nombre. Una cadena de 320 caracteres (por ejemplo, 0x03FA4D...) que es la representación del carácter hexadecimal de la mitad pública de la clave de firma que se utiliza en el ensamblado con el atributo APTCA condicional. No es necesario especificar un atributo de versión. CLR requiere únicamente el nombre del ensamblado y el token de clave pública.
Una consecuencia importante de cara al rendimiento cuando se habilita un ensamblado con el atributo APTCA condicional es que también se debe habilitar la clausura transitiva de ensamblados con APTCA condicional. Por ejemplo, si ensamblado con ATPCA condicional A depende de ensamblado con APTCA B y a su vez el ensamblado con APTCA B depende del ensamblado con ATPCA condicional C, cuando habilite ATPCA condicional para A también debe habilitarlo para C. De lo contrario, el rendimiento de la aplicación puede verse afectado. Por ejemplo, el uso compartido del código y las imágenes NGen estarán deshabilitadas si la clausura completa de ATPCA condicional no está habilitada.
Cómo afecta APTCA condicional a las aplicaciones de confianza parcial que no son de Web
En versiones de ASP.NET anteriores a ASP.NET 4, algunos tipos y espacios de nombres no se marcaban con el atributo AspNetHostingPermission. Esto permitía llamar a estos tipos desde entornos de confianza parcial que no eran ASP.NET, como las aplicaciones ClickOnce. Los tipos y espacios de nombres a los que se podía llamar de esta manera eran los siguientes:
Tipos del espacio de nombres System.Web.ClientServices.
Tipos del espacio de nombres System.Web.ClientServices.Providers.
El tipo HttpUtility.
Los tipos System.Web.ClientServices no son utilizables en entornos de confianza parcial de .NET Framework 4 como ClickOnce. Dado que el ensamblado continente (System.Web.Extensions.dll) es un ensamblado de ASP.NET 4 que se marca para APTCA condicional y como ClickOnce no permite APTCA en cualquier ensamblado con APTCA condicional, ninguno de los tipos de servicios de cliente es invocable de las aplicaciones ClickOnce de confianza parcial.
Hay varias razones que justifican este comportamiento: Primero, .NET Framework 4 se ha dividido en un cliente y un SKU extendido, y la hipótesis es que muchas aplicaciones ClickOnce tendrán como destino el SKU de cliente. Requeriría un esfuerzo sustancial refactorizar los tipos de servicios del cliente de ASP.NET en el SKU de cliente.
Segundo, es complejo determinar cómo refactorizar los tipos de cliente al tiempo que se mantiene los límites de APTCA condicional necesarios. Por consiguiente, en .NET Framework 4, los tipos de servicios de cliente solo están disponibles para entornos de plena confianza que no son ASP.NET, incluidas las aplicaciones ClickOnce que se configuran para ejecutarse con plena confianza mediante el SKU extendido de .NET Framework 4.
Para el tipo HttpUtility, el efecto de APTCA condicional depende de qué métodos se estaban utilizando, como se muestra en los siguientes escenarios:
El código de confianza parcial estaba llamando a los métodos HtmlDecode o HtmlEncode de la clase WebUtility. El tipo WebUtility contiene la codificación HTML de ASP.NET y las implementaciones de descodificación, pero estos se han refactorizado y movido al espacio de nombres System.Net y eso se encuentra dentro de System.dll. Dado que System.dll está disponible en todos los entornos de host de confianza parcial, no hay ningún problema con los métodos del tipo WebUtility que tienen acceso a las aplicaciones de confianza parcial que no son ASP.NET.
El código de la confianza parcial llamaba a cualquiera de los otros métodos de la clase WebUtility. En ese caso, está vigente el mismo problema que se ha descrito antes para los tipos de servicios de cliente. Es decir, WebUtility solo está disponible a los llamadores de plena confianza que no son ASP.NET en .NET Framework 4.
Transparencia de seguridad en ASP.NET 4
La transparencia de seguridad permite que indique al CLR si un bloque de código va a llevar a cabo alguna vez una operación que afecte a la seguridad. El código transparente nunca puede validar permisos, satisfacer una petición de vínculo, contener código que no se pueda comprobar, llamar en código nativo o llamar en código crítico para la seguridad. Esto es verdad sin tener en cuenta si el código transparente es de plena confianza (por ejemplo en la GAC) o de confianza parcial.
La transparencia de seguridad es una característica eficaz con las características de .NET Framework como ASP.NET. Permite que ASP.NET indique al CLR que las partes de código ASP.NET nunca validarán permisos y que ese código nunca implementará ni efectuará operaciones que afecten a la seguridad, como llamadas PInvoke a código nativo. Esto habilita el código de .NET Framework para reducir, en gran medida, la exposición de seguridad de un número grande de API públicas e internas aunque el código de .NET Framework está en la GAC de plena confianza.
La transparencia de seguridad se puede aplicar a un ensamblado completo o solo a un subconjunto del código del ensamblado. Aunque marcar un ensamblado completo para transparencia de seguridad es lo ideal, algún código del código de .NET Framework tiene un requisito legítimo para realizar tareas que afectan a la seguridad. Los ensamblados que contienen un 100% de código transparente en seguridad se marcan con un atributo SecurityTransparentAttribute de nivel de ensamblado.
Los ensamblados que contienen una mezcla de código transparente y no transparente no tienen un atributo de transparencia de nivel de ensamblado. En su lugar, las clases individuales del ensamblado se pueden marcar con el atributo SecuritySafeCriticalAttributel o el atributo SecurityCriticalAttribute.
El comportamiento de las clases sin atributo es complejo. Sin embargo, en términos sencillos, los tipos sin atributo de los ensamblados de ASP.NET 4 que han adoptado el nuevo modelo de transparencia están considerados transparentes en seguridad. Los tipos de los ensamblados de ASP.NET 4 que no tienen atributos y no han adoptado el nuevo modelo de transparencia se consideran críticos para la seguridad y disponibles desde código transparente.
Transparencia de seguridad en la práctica y RuleSets de seguridad
Como gran cantidad de la base de código de ASP.NET 4 está en System.Web.dll, no era práctico pasar todo el código de ASP.NET 4 al nuevo modelo de transparencia. En su lugar, se pueden crear particiones del código de ASP.NET 4 en las siguientes categorías:
Código que no adoptó el nuevo modelo de transparencia, que incluye código de los siguientes ensamblados:
System.Web.dll
System.Web.ApplicationServices.dll
System.Web.Mobile.dll. Los tipos de este ensamblado se marcaron como obsoletos en ASP.NET 4. Aunque el ensamblado todavía existe, la expectativa es que, con el tiempo, deje de utilizar los tipos de este ensamblado.
Código que usa el nuevo modelo de transparencia, que incluye código de los siguientes ensamblados:
System.Web.Extensions.dll
System.Web.DynamicData.dll (100% transparente en seguridad)
System.Web.RegularExpressions.dll (100% transparente en seguridad)
System.ComponentModel.DataAnnotations.dll
System.Web.DataVisualization.dll
Ensamblados que solo son metadatos y cuyos tipos se pasaron a un ensamblado de ASP.NET diferente, incluidos los siguientes ensamblados:
System.Web.Abstractions.dll. Los tipos que estaban en este ensamblado en versiones anteriores de ASP.NET se movieron a System.Web.dll. Como resultado, Sytem.Web.Abstractions.dll es un ensamblado de solo metadatos en ASP.NET 4.
System.Web.Routing.dll. Los tipos que estaban en este ensamblado en versiones anteriores de ASP.NET se movieron a System.Web.dll. Como resultado, en ASP.NET 4, System.Web.Routing.dll es un ensamblado de solo metadatos.
En .NET Framework 4, el CLR presentó un nuevo concepto que se denomina conjunto de reglas de seguridad. Hay dos niveles de configuraciones SecurityRuleSet, el uno y el dos. La configuración SecurityRuleSet de todos los tipos se especifica usando el atributo del nivel de ensamblado SecurityRulesAttribute. Los ensamblados de ASP.NET 4 que adoptaron el nuevo modelo de transparencia se marcan con el siguiente atributo del nivel de ensamblado:
System.Security.SecurityRules(RuleSet=System.Security.SecurityRuleSet.Level2)
Los ensamblados de ASP.NET 4 que utilizan el modelo de la transparencia de .NET Framework 2.0 se marcan (lo que para ASP.NET significa, efectivamente, sin transparencia, porque antes de ASP.NET 4 nunca se usaron los conceptos de transparencia) con el siguiente atributo del nivel de ensamblado:
System.Security.SecurityRules(RuleSet=System.Security.SecurityRuleSet.Level1)
Para ensamblados de ASP.NET que adoptaron el nuevo modelo de transparencia (y los tipos públicos que están en los ensamblados), la mayoría del código se considera transparente en seguridad. Una pequeño de cantidad del código de estos ensamblados realiza operaciones que afectan a la seguridad y ese código se marca como crítico para la seguridad y disponible desde código transparente.
Con los ensamblados de ASP.NET que no adoptaron el nuevo modelo de transparencia (dejando a un lado los ensamblados obsoletos o los redirigidos por tipo) se puede llamar a todas las API públicas desde código de usuario de confianza parcial y efectuar internamente operaciones que afecten a la seguridad. La combinación de acceso abierto a los llamadores de confianza parcial y el potencial para los recursos de las operaciones que afecta a la seguridad que ese más anterior código de ASP.NET 4 requiere un grado mayor de escrutinio. Sin embargo, como la mayoría de las nuevas características de ASP.NET se implementan en ensamblados más recientes como System.Web.Extensions.dll y System.Web.DynamicData.dll, o en versiones independientes como ASP.NET MVC, la mayor parte del más nuevo código de ASP.NET es transparente en seguridad y, por consiguiente, de forma predeterminada es más seguro que el código anterior.
De forma predeterminada, el CLR trata las API públicas de todos los ensamblados de ASP.NET 4 que están marcadas como SecurityRuleSet.Level1 como crítico para la seguridad (es decir, equivalente a estar marcado con el atributo SecuritySafeCriticalAttribute) con tal de que el entorno de hospedaje admita el atributo APTCA. Si no se admite APTCA, CLR desencadena una petición de vínculo para plena confianza, en la que se producirá un error cuando haya código de usuario de confianza parcial en la pila. En otras palabras, cuando no se admita APTCA en un ensamblado de ASP.NET marcado como SecurityRuleSet.Level1, verá el mismo comportamiento que en versiones anteriores de .NET Framework, cuando el código de confianza parcial intentó llamar a un ensamblado de plena confianza no marcado con el atributo APTCA.
De forma predeterminada, el CLR trata las API públicas de todos los ensamblados de ASP.NET 4 que están marcadas como SecurityRuleSet.Level2 como transparente en seguridad (es decir, equivalente a estar marcado con el atributo SecurityTransparentAttribute) con tal de que el entorno de hospedaje admita el atributo APTCA. De lo contrario, se define el siguiente comportamiento:
Si no se admite APTCA y un ensamblado marcado como Level2 no es 100% transparente en seguridad, el CLR trata el área expuesta pública como crítica para la seguridad. Como resultado, es probable que se produzca un error en los llamadores de confianza parcial que intenten utilizar el área expuesta pública con una excepción MethodAccessException, TypeAccessException o FieldAccessException.
Si no se admite APTCA y un ensamblado marcado como Level2 es 100% transparente en seguridad, los llamadores de confianza parcial podrán llamar correctamente a cualquiera de las API públicas de ese ensamblado. En la práctica, esto significa que una excepción SecurityException se produce después en la ruta de acceso de la llamada cuando el código en el ensamblado 100% transparente en seguridad llama finalmente a un ensamblado de ASP.NET nivel 1 o a un ensamblado de ASP.NET nivel 2 que no son 100% transparentes en seguridad.
Transparencia y compilación en ASP.NET
El resultado que crea el sistema de compilación de ASP.NET también se ve afectado por la adopción por parte de ASP.NET 4 del nuevo modelo de CAS y del nuevo modelo de transparencia en seguridad. Esto incluye elementos como los ensamblados de página, los ensamblados precompilados y los resultados de compilación del directorio App_Code. El sistema de compilación varía su comportamiento según el valor del atributo LegacyCasModel del elemento trust.
La siguiente tabla describe cómo los objetos compilados dinámicamente se marcan en el modelo de CAS heredado y en el nuevo modelo.
valor de atributo legacyCasModel |
Nivel de confianza del sitio web |
Atributos aplicados a ensamblados de compilación |
|---|---|---|
False (nuevo modelo CAS) |
Plena confianza |
SecurityRules(SecurityRuleSet.Level2) |
Confianza alta o baja |
SecurityRules(SecurityRuleSet.Level2) |
|
SecurityRules(SecurityRuleSet.Level2) |
||
True (modelo de CAS) |
Plena confianza |
SecurityRules(SecurityRuleSet.Level1) |
Confianza alta o baja |
SecurityRules(SecurityRuleSet.Level1) |
Dado que el sistema de compilación de ASP.NET 4 varía su comportamiento según los valores del atributo LegacyCasModel del elemento trust, puede haber restricciones en cómo se comparte el código compilado por diferente aplicaciones de confianza parcial ASP.NET 4. En general, no tendría que ver ningún cambio en el comportamiento de la aplicación. Sin embargo, en algunos escenarios, los artefactos compilados creados a partir de una aplicación de confianza parcial que tiene el atributo LegacyCasModel establecido en false (es decir, que utiliza el nuevo modelo de CAS) no funciona como se espera cuando se utilizan con otras aplicaciones. Como resultado, en algunos escenarios (por ejemplo, una biblioteca compartida de controles .ascx compilados que están firmados, con atributo ATPCA e implementado en la GAC), tendría que aplicar los atributos críticos y críticos para la seguridad a parte del código explícitamente cuando la biblioteca esté marcada con Level2.
Vea también
Otros recursos
Seguridad de aplicaciones ASP.NET en entornos alojados en host