Consideraciones de seguridad de 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 o emita específicamente.
XAML compilado en o almacenado como un recurso de tipo resx
dentro de un ensamblado de confianza y firmado no es inherentemente de confianza. Puedes confiar en el XAML tanto como confíes en el ensamblado en su conjunto. En la mayoría de los casos, solo te preocupas por los aspectos de confianza de XAML flexible, que es un origen XAML que cargas desde una secuencia u otra E/S. XAML flexible no es un componente específico ni una característica de un modelo de aplicación con una infraestructura de implementación y empaquetado. Sin embargo, un ensamblado podría implementar un comportamiento que implica cargar XAML flexible.
Para XAML que no es de confianza, debes tratarlo generalmente igual que si fuera código que no es de confianza. Usa espacio aislado u otras metáforas para evitar que posiblemente XAML no sea de confianza acceder al código de confianza.
La naturaleza de las funcionalidades xaml ofrece al XAML el derecho a construir objetos y establecer sus propiedades. Estas funcionalidades también incluyen el acceso a convertidores de tipos, la asignación y el acceso a ensamblados en el dominio de aplicación, mediante extensiones de marcado, bloques de 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 puede 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 suele requerir 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, contexto de esquema XAML no predeterminado ni configuración 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 tipos 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 de AppDomain independientes, con uno de ellos específicamente diseñado o aislado para la confianza parcial.
Espacios de nombres XAML y confianza de ensamblados
La sintaxis y la definición básicas no calificadas para la forma en que XAML interpreta una asignación de espacio de nombres XAML personalizado a un ensamblado no distingue entre un ensamblado de confianza y 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 suplantar la asignación de espacio de nombres XAML previsto de un ensamblado de confianza y capturar la información de propiedad y el objeto declarados 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:
Usa un nombre de ensamblado completo con nombre seguro en cualquier asignación de espacio de nombres XAML realizada por el XAML de la aplicación.
Restrinja 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. Consulte XamlSchemaContext(IEnumerable<Assembly>).
Asignación de tipos XAML y acceso al sistema de tipos
XAML admite su propio sistema de tipos, que de muchas maneras es un elemento del mismo nivel de cómo 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 tipo, debe aplazar a 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 se dejan 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 extensibilidad 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, vea las notas específicas sobre varias de las propiedades de XamlType y XamlMember.
Consulte también
.NET Desktop feedback