Compartilhar via

Considerações sobre segurança XAML

  • Artigo

Este artigo descreve as melhores práticas de segurança em aplicativos quando você usa a API de Serviços XAML e .NET XAML.

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 emitia especificamente.

O XAML compilado ou armazenado como um recurso de tipo resxem um assembly 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ê só está preocupado com os aspectos de confiança do XAML flexível, que é uma fonte XAML que você carrega de um fluxo ou de outra E/S. O XAML flexível não é um componente específico ou um recurso 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 flexível.

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

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

Além dos 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.

Contexto de compartilhamento entre leitores e escritores

A arquitetura dos Serviços XAML do .NET para leitores XAML e gravadores XAML geralmente requer o compartilhamento de um leitor XAML para um gravador XAML ou um contexto de esquema XAML compartilhado. O compartilhamento de objetos ou contextos poderá ser necessário se você estiver escrevendo a 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 gravação de objeto XAML para um backup 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 podem 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 AppDomain separados, com um deles especificamente destinado/em área restrita para confiança parcial.

Namespaces XAML e confiança do assembly

A sintaxe básica não qualificada e a definição de como o XAML interpreta um mapeamento de namespace XAML personalizado para um assembly não distingue entre um assembly confiável e não confiável, conforme carregado no domínio do aplicativo. Portanto, tecnicamente, é possível que um assembly não confiável falsibilize o mapeamento de namespace XAML pretendido de um assembly confiável e capture as informações de objeto e propriedade declaradas 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 aplicativo.

  • Restrinja o mapeamento de assembly a um conjunto fixo de assemblies de referência, construindo uma XamlSchemaContext específica 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 dá suporte a seu próprio sistema de tipos, que, em muitos aspectos, é um par de como o CLR implementa o sistema de tipo CLR básico. No entanto, para determinados aspectos de 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órios específicos do sistema de tipos 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 tipos XAML é extensível, para corresponder à extensibilidade do próprio XAML e suas possíveis estratégias alternativas de mapeamento de tipo em comparação com a implementação padrão apoiada por CLR e o contexto de esquema XAML padrão. Para obter mais informações, consulte as anotações específicas sobre várias das propriedades de XamlType e XamlMember.

Consulte também