Consideraciones de seguridad sobre XAML

En este artículo se describen los procedimientos recomendados para la seguridad en las aplicaciones cuando se usa XAML y la API de servicios XAML de .NET.

XAML que no es de confianza en aplicaciones

En el sentido más general, XAML que no es de confianza es cualquier origen XAML que la aplicación no incluya ni emita específicamente.

XAML compilado como un recurso de tipo resx o almacenado como tal dentro de un ensamblado de confianza y firmado no es de confianza inherentemente. Se puede confiar en el XAML tanto como confíe en el ensamblado en su conjunto. En la mayoría de los casos solo debe preocuparse por los aspectos de confianza de XAML dinámico, que es un origen XAML que se carga desde una secuencia u otra E/S. XAML dinámico no es un componente o característica específicos de un modelo de aplicación con una infraestructura de implementación y empaquetado. Sin embargo, un ensamblado podría implementar un comportamiento que implique cargar XAML dinámico.

Para XAML que no es de confianza, se debe tratar igual que si fuera código que no es de confianza. Use espacios aislados u otros medios para evitar que XAML que no es de confianza acceda al código de confianza.

La naturaleza de las funcionalidades XAML proporciona al XAML el derecho a construir objetos y establecer sus propiedades. Estas funcionalidades también incluyen el acceso a convertidores de tipo y la asignación y el acceso a ensamblados en el dominio de aplicación mediante extensiones de marcado, bloques x:Code, etc.

Además de sus funcionalidades de nivel de lenguaje, XAML se usa para la definición de la interfaz de usuario en muchas tecnologías. Cargar XAML que no es de confianza podría significar cargar una interfaz de usuario de suplantación malintencionada.

Compartir contexto entre lectores y escritores

La arquitectura de servicios XAML de .NET para lectores XAML y escritores XAML a menudo requiere compartir un lector XAML con un escritor XAML o un contexto de esquema XAML compartido. Es posible que sea necesario compartir objetos o contextos si está escribiendo lógica de bucle de nodo XAML o proporcionando una ruta de acceso de guardado personalizada. No comparta instancias de lector XAML, contextos de esquema XAML no predeterminados ni configuraciones para clases de lector y escritor XAML entre código de confianza y no de confianza.

La mayoría de los escenarios y operaciones que implican la escritura de objetos XAML para una copia de seguridad de tipo basada en CLR solo pueden usar el contexto de esquema XAML predeterminado. El contexto de esquema XAML predeterminado no incluye explícitamente la configuración que podría poner en peligro la plena confianza. Por lo tanto, es seguro compartir contexto entre componentes de lector y escritor XAML de confianza y que no son de confianza. Sin embargo, si lo hace, sigue siendo un procedimiento recomendado mantener estos lectores y escritores en ámbitos independientes AppDomain, con uno de ellos específicamente pensado o aislado para la confianza parcial.

Espacios de nombres XAML y confianza de ensamblados

La sintaxis incompleta y la definición básicas de cómo interpreta XAML una asignación de espacio de nombres XAML personalizado a un ensamblado no distingue entre un ensamblado de confianza y uno que no es de confianza como cargado en el dominio de aplicación. Por lo tanto, técnicamente es posible que un ensamblado que no sea de confianza suplante la asignación de espacio de nombres XAML previsto de un ensamblado de confianza y capture la información de propiedad y el objeto declarado de un origen XAML. Si tiene requisitos de seguridad para evitar esta situación, la asignación de espacio de nombres XAML prevista debe realizarse mediante una de las técnicas siguientes:

  • Usar un nombre de ensamblado completo con nombre seguro en cualquier asignación de espacio de nombres XAML realizado por el XAML de la aplicación.

  • Restringir la asignación de ensamblados a un conjunto fijo de ensamblados de referencia mediante la construcción de un XamlSchemaContext específico para los lectores XAML y los escritores de objetos XAML. Vea XamlSchemaContext(IEnumerable<Assembly>).

Asignación de tipos XAML y acceso al sistema de tipos

XAML es compatible con su propio sistema de tipos, que es un elemento del mismo nivel que el modo en que CLR implementa el sistema básico de tipos CLR. Sin embargo, para determinados aspectos del reconocimiento de tipos en los que se toman decisiones de confianza sobre un tipo en función de su información de tipos, se debería aplazar la información de tipo en los tipos de respaldo CLR. Esto se debe a que algunas de las funcionalidades de informes específicas del sistema de tipos XAML quedan abiertas como métodos virtuales y, por lo tanto, no están totalmente bajo el control de las implementaciones originales de los servicios XAML de .NET. Estos puntos de ampliación existen porque el sistema de tipos XAML es extensible, para que coincida con la extensibilidad de XAML y sus posibles estrategias alternativas de asignación de tipos frente a la implementación predeterminada respaldada por CLR y el contexto de esquema XAML predeterminado. Para obtener más información, consulte las notas específicas sobre varias de las propiedades de XamlType y XamlMember.

Vea también