Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
En este artículo se describen los procedimientos recomendados al ejecutar Windows Communication Foundation (WCF) en un entorno de confianza parcial.
Serialización
Aplique estas prácticas al usar el DataContractSerializer en una aplicación de confianza parcial.
Todos los tipos serializables deben marcarse explícitamente con el [DataContract] atributo . Las técnicas siguientes no se admiten en un entorno de confianza parcial:
- Marcado de clases que se van a serializar con el SerializableAttribute.
- Implementar la ISerializable interfaz para permitir que una clase controle su proceso de serialización.
Uso de DataContractSerializer
Todos los tipos marcados con el
[DataContract]atributo deben ser públicos. Los tipos no públicos no se pueden serializar en un entorno de confianza parcial.Todos los miembros de
[DataContract]de un tipo de[DataContract]serializable deben ser públicos. Un tipo con un[DataMember]no público no se puede serializar en un entorno de confianza parcial.Los métodos que controlan los eventos de serialización (como
OnSerializing,OnSerialized,OnDeserializingyOnDeserialized) deben declararse como públicos. Sin embargo, se admiten implementaciones explícitas e implícitas de OnDeserialization(Object) .[DataContract]Los tipos implementados en ensamblados marcados con AllowPartiallyTrustedCallersAttribute no deben realizar acciones relacionadas con la seguridad en el constructor del tipo, puesto que DataContractSerializer no llama al constructor del objeto recién creado durante la deserialización. En concreto, se deben evitar las siguientes técnicas de seguridad comunes para los tipos[DataContract]:Intentar restringir el acceso de confianza parcial haciendo interno o privado el constructor del tipo.
Para restringir el acceso al tipo, añada un
[LinkDemand]al constructor del tipo.Suponiendo que, dado que el objeto se ha creado correctamente, las comprobaciones de validación aplicadas por el constructor se han superado correctamente.
Uso de IXmlSerializable
Los siguientes procedimientos recomendados se aplican a los tipos que implementan IXmlSerializable y se serializan mediante DataContractSerializer:
Las GetSchema implementaciones de método estático deben ser
public.Los métodos de instancia que implementan la IXmlSerializable interfaz deben ser
public.
Utilizar WCF a partir de código de la plataforma de plena confianza que permite llamadas desde llamadores de confianza parcial
El modelo de seguridad de confianza parcial de WCF supone que cualquier llamador de un método o propiedad públicos de WCF está funcionando en el contexto de seguridad de acceso al código (CAS) de la aplicación de hospedaje. WCF también supone que solo existe un contexto de seguridad de la aplicación para cada AppDomain, y que este contexto se establece en el momento de la creación de AppDomain por un host de confianza (por ejemplo, por una llamada a CreateDomain o por el administrador de aplicaciones de ASP.NET).
Nota:
La seguridad de acceso al código (CAS) está en desuso en todas las versiones de .NET Framework y .NET. Las versiones recientes de .NET no respetan las anotaciones CAS y producen errores si se utilizan las APIs relacionadas con CAS. Los desarrolladores deben buscar medios alternativos para realizar tareas de seguridad.
Este modelo de seguridad se aplica a las aplicaciones escritas por el usuario que no pueden declarar permisos CAS adicionales, como el código de usuario que se ejecuta en una aplicación de confianza media ASP.NET. Sin embargo, el código de plataforma completamente confiable (por ejemplo, un ensamblado de terceros instalado en la caché global de ensamblados, que acepta llamadas de código de confianza parcial) debe tener sumo cuidado al interactuar con WCF en nombre de una aplicación de confianza parcial para evitar la introducción de vulnerabilidades de seguridad a nivel de aplicación.
El código de plena confianza debe evitar modificar el conjunto de permisos CAS del hilo actual (llamando a Assert, PermitOnly, o Deny) antes de llamar a las API de WCF en nombre del código de confianza parcial. La afirmación, negación o creación de un contexto de permiso específico para el subproceso que sea independiente del contexto de seguridad a nivel de aplicación puede dar lugar a un comportamiento inesperado. Dependiendo de la aplicación, este comportamiento puede dar lugar a vulnerabilidades de seguridad de nivel de aplicación.
El código que llama a WCF mediante un contexto de permiso específico del subproceso debe estar preparado para controlar las siguientes situaciones que pueden surgir:
Es posible que el contexto de seguridad específico del subproceso no se mantenga durante la operación, lo que da lugar a posibles excepciones de seguridad.
El código de WCF interno junto con cualquier devolución de llamada proporcionada por el usuario pueden ejecutarse en un contexto de seguridad diferente que aquel bajo el que se inició la llamada originariamente. Estos contextos incluyen:
Contexto de permiso de aplicación.
Cualquier contexto de permiso para subprocesos creado previamente por otros subprocesos de usuarios utilizados para llamar en WCF mientras dure el AppDomain que se está ejecutando actualmente.
WCF garantiza que el código de confianza parcial no puede obtener permisos de plena confianza a menos que dichos permisos sean declarados por un componente de plena confianza antes de llamar a las API públicas de WCF. Sin embargo, no garantiza que los efectos de la aserción de plena confianza estén aislados en un subproceso, una operación o una acción de usuario determinada.
Como procedimiento recomendado, evite crear un contexto de permisos específico para el hilo llamando a Assert, PermitOnly o Deny. En su lugar, conceda o deniegue el privilegio a la propia aplicación, de modo que no se requiera Assert, Deny o PermitOnly.