Considerações de segurança XAML

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

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 que é compilado ou armazenado como um recurso do tipo resxdentro de um assembly confiável e assinado não é inerentemente não confiável. Você pode confiar no XAML tanto quanto confia no assembly como um todo. Na maioria dos casos, você está preocupado apenas com os aspetos de confiança do XAML solto, que é uma fonte XAML que você carrega de um fluxo ou de outra E/S. 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ável acesse 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 tipo, mapear e acessar assemblies no domínio do aplicativo, usar extensões de marcação, blocos de x:Code 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.

Formas compiladas e binárias de XAML

Algumas tecnologias compilam XAML numa forma binária ou tokenizada que é carregada em tempo de execução. Uma forma binária de XAML tem as mesmas capacidades de construção de objetos que o XAML equivalente de texto, pelo que transporta as mesmas considerações de confiança. Trate uma fonte XAML binária como confiável apenas quando esta se origina de um assembly ou recurso compilado e assinado que produziu. Não carregue uma fonte XAML binária que provenha de um fluxo, ficheiro ou documento não confiável, e esteja ciente de que um formato de contentor pode incorporar esse conteúdo como uma das suas partes.

Leitores restritivos são uma medida de reforço, não um sandbox

Um caminho de carregamento pode oferecer um leitor restritivo ou de lista de permissões que bloqueia um conjunto de tipos conhecidos como perigosos. Este tipo de leitor é um passo útil para reforçar a defesa em profundidade, mas não é um sandbox de segurança. Um leitor restritivo pode ainda permitir muitos tipos incorporados, incluindo tipos que têm efeitos secundários, como o acesso a recursos de rede. Não trate uma análise restritiva de marcação não confiável como segura. Continue a isolar a marcação não confiável numa fronteira de baixo privilégio.

Compartilhando contexto entre leitores e escritores

A arquitetura dos Serviços XAML .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 escrita 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 AppDomain separados, com um deles especificamente destinado / sandbox para confiança parcial.

Namespaces XAML e confiança de 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 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 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 seu aplicativo.

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

Mapeamento de tipo XAML e acesso ao sistema de tipo

O XAML suporta seu próprio sistema de tipos, que de muitas maneiras é um ponto a como o CLR implementa o sistema de tipo CLR básico. No entanto, para certos aspetos 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 tipos 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 por 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.

Ver também

• XamlAccessLevel