Considerações de segurança XAML

  • Artigo

Este artigo descreve as práticas recomendadas para segurança em aplicativos quando você usa XAML e .NET XAML Services API.

XAML não confiável em aplicativos

No sentido mais geral, XAML não confiável é qualquer fonte XAML que seu aplicativo não incluiu ou emitiu especificamente.

O XAML compilado ou armazenado como um recurso do tipo -type em um resxassembly confiável e assinado não é inerentemente não confiável. Você pode confiar no XAML tanto quanto confiar no assembly como um todo. Na maioria dos casos, você está preocupado apenas com os aspectos de confiança do XAML solto, que é uma fonte XAML que você carrega de um fluxo ou outra E/S. O XAML solto não é um componente ou recurso específico de um modelo de aplicativo com uma infraestrutura de implantação e empacotamento. No entanto, um assembly pode implementar um comportamento que envolve o carregamento de XAML solto.

Para XAML não confiável, você deve tratá-lo geralmente da mesma forma como se fosse um código não confiável. Use sandboxing ou outras metáforas para impedir que XAML possivelmente não confiáveis acessem seu código confiável.

A natureza dos recursos XAML dá ao XAML o direito de construir objetos e definir suas propriedades. Esses recursos também incluem acessar conversores de tipos, mapear e acessar assemblies no domínio do aplicativo, usar extensões de marcação, x:Code blocos e assim por diante.

Além de seus recursos de nível de linguagem, o XAML é usado para definição de interface do usuário em muitas tecnologias. Carregar XAML não confiável pode significar carregar uma interface do usuário de falsificação mal-intencionada.

Compartilhando contexto entre leitores e escritores

A arquitetura dos Serviços XAML do .NET para leitores e gravadores XAML geralmente requer o compartilhamento de um leitor XAML com um gravador XAML ou um contexto de esquema XAML compartilhado. O compartilhamento de objetos ou contextos pode ser necessário se você estiver escrevendo lógica de loop de nó XAML ou fornecendo um caminho de salvamento personalizado. Não compartilhe instâncias de leitor XAML, contexto de esquema XAML não padrão ou configurações para classes de leitor/gravador XAML entre código confiável e não confiável.

A maioria dos cenários e operações que envolvem a gravação de objetos XAML para um suporte de tipo baseado em CLR pode usar apenas o contexto de esquema XAML padrão. O contexto de esquema XAML padrão não inclui explicitamente configurações que possam comprometer a confiança total. Portanto, é seguro compartilhar o contexto entre componentes de leitor/gravador XAML confiáveis e não confiáveis. No entanto, se você fizer isso, ainda é uma prática recomendada manter esses leitores e escritores em escopos separados AppDomain , com um deles especificamente destinado/sandbox para confiança parcial.

Namespaces XAML e confiança de assembly

A sintaxe e a definição básicas não qualificadas de como o XAML interpreta um mapeamento de namespace XAML personalizado para um assembly não distinguem entre um assembly confiável e não confiável conforme carregado no domínio do aplicativo. Assim, é tecnicamente possível para um assembly não confiável falsificar o mapeamento de namespace XAML pretendido de um assembly confiável e capturar as informações de propriedade e objeto declarado de uma fonte XAML. Se você tiver requisitos de segurança para evitar essa situação, o mapeamento de namespace XAML pretendido deverá ser feito usando uma das seguintes técnicas:

  • Use um nome de assembly totalmente qualificado com nome forte em qualquer mapeamento de namespace XAML feito pelo XAML do seu aplicativo.

  • Restrinja o mapeamento de assembly a um conjunto fixo de assemblies de referência, construindo um específico XamlSchemaContext para seus leitores XAML e gravadores de objetos XAML. Consulte XamlSchemaContext(IEnumerable<Assembly>).

Mapeamento de tipo XAML e acesso ao sistema de tipos

O XAML oferece suporte a seu próprio sistema de tipos, que de muitas maneiras é um ponto de como o CLR implementa o sistema básico de tipos CLR. No entanto, para certos aspectos do reconhecimento de tipo em que você está tomando decisões de confiança sobre um tipo com base em suas informações de tipo, você deve adiar para as informações de tipo nos tipos de suporte CLR. Isso ocorre porque alguns dos recursos de relatório específicos do sistema de tipo XAML são deixados abertos como métodos virtuais e, portanto, não estão totalmente sob o controle das implementações originais dos Serviços XAML do .NET. Esses pontos de extensibilidade existem porque o sistema de tipo XAML é extensível, para corresponder à extensibilidade do próprio XAML e suas possíveis estratégias alternativas de mapeamento de tipo versus a implementação padrão apoiada pelo CLR e o contexto de esquema XAML padrão. Para obter mais informações, consulte as notas específicas sobre várias das propriedades de XamlType e XamlMember.

Confira também