Considerações de segurança do XAML
Este tópico descreve as práticas recomendadas para segurança em aplicativos, quando você usa o XAML e.API de serviços XAML a NET Framework.
XAML não confiável em aplicativos
Em um sentido mais geral, o XAML não confiável é qualquer fonte XAML que seu aplicativo não especificamente não incluem ou emitir.
XAML que é compilado em ou armazenado como um resx-tipo de recurso dentro de um assembly confiável e assinado não é confiável inerentemente. Você pode confiar em XAML quanto a confiança do assembly como um todo. Na maioria dos casos, você só está preocupado com os aspectos de confiança de XAML livre, o que é uma fonte XAML que você carregar a partir de um fluxo ou outro i / o. Não, o XAML livre é um componente específico ou o recurso de um modelo de aplicativo com a infra-estrutura de empacotamento e implantação. Entretanto, um assembly pode implementar um comportamento que envolve a carregar o XAML livre.
Para XAML não confiável, você deve tratá-lo geralmente o mesmo como se fosse código não confiável. Use o modo seguro ou outras metáforas para impedir que o XAML possivelmente não confiável acessem o seu código confiável.
A natureza dos recursos XAML dá o direito de construir objetos e definir suas propriedades XAML. Esses recursos também incluem acessando os conversores de tipo, mapeamento e acessar os módulos (assemblies) no domínio do aplicativo, usando as extensões de marcação, x:Code blocos e assim por diante.
Além de seus recursos de nível de linguagem XAML é utilizado para definição de interface do usuário em várias tecnologias. Carregar o XAML não confiável pode significar a carregar uma interface do usuário mal-intencionado falsificação.
Compartilhamento de contexto entre leitores e gravadores
A.Arquitetura de serviços do NET Framework XAML para leitores XAML e gravadores XAML geralmente requer o compartilhamento de um leitor XAML para um gravador XAML ou em um contexto de esquema compartilhado do XAML. Compartilhamento de objetos ou contextos pode ser necessário se você estiver escrevendo uma lógica de loop de nó XAML ou fornecendo um personalizado salvar demarcador. Você não deve compartilhar instâncias do leitor XAML, contexto de esquema XAML não padrão ou configurações para as classes de leitor/gravador XAML entre confiável e de código.
A maioria dos cenários e operações envolvendo o objeto XAML, escrevendo para um tipo de baseados em CLR fazendo poderá usar o contexto de esquema XAML padrão. O contexto de esquema XAML padrão não inclui configurações que possam comprometer a confiança total explicitamente. Assim, é seguro compartilhar o contexto entre componentes de leitor/gravador confiáveis e XAML. No entanto, se você fizer isso, ele ainda é uma prática recomendada para manter esses leitores e gravadores em separado AppDomain escopos, com um no modo especificamente pretendido/seguro para confiança parcial.
Namespaces XAML e a relação de confiança do Assembly
A sintaxe básica de não qualificado e a definição como XAML interpreta um mapeamento de namespace XAML personalizado a um assembly não faz distinção entre um assembly confiável e como carregados para o domínio do aplicativo. Portanto, é tecnicamente possível para um assembly não confiável falsificar o mapeamento de namespace XAML pretendido de um assembly confiável e capturar informações de propriedade e o objeto declarado de uma fonte XAML. Se você tiver requisitos de segurança para evitar essa situação, o mapeamento de namespace XAML pretendido deve ser feito usando uma das seguintes técnicas:
Use um nome totalmente qualificado do assembly com nome forte em qualquer mapeamento de namespace XAML feito pelo XAML em seu aplicativo.
Restringir o mapeamento para um conjunto fixo de assemblies de referência, construindo um específico do assembly XamlSchemaContext para seus leitores XAML e gravadores de objeto do XAML. See XamlSchemaContext(IEnumerable<Assembly>).
Mapeamento de tipo XAML e o acesso de tipo de sistema
O XAML oferece suporte a seu próprio sistema de tipo, o que é do mesmo nível como o CLR implementa o sistema básico de tipo CLR de várias maneiras. No entanto, para determinados aspectos de onde você está tomando decisões de confiança sobre um tipo com base em suas informações de tipo de reconhecimento de tipo, você deve adiar o tipo de informação no CLR fazendo tipos. Isso ocorre porque alguns dos recursos de relatório específicos do sistema de tipos XAML foram deixadas abertas como métodos virtuais e, portanto, não são totalmente sob o controle do original.Implementações de serviços do NET Framework XAML. Esses pontos de extensibilidade existem porque o sistema de tipos XAML é extensível, para coincidir com a extensibilidade do XAML em si e suas possíveis estratégias alternativas de mapeamento de tipo versus a implementação de CLR reserva padrão e contexto de esquema XAML padrão. Para obter mais informações, consulte as notas de específicas em várias das propriedades de XamlType e XamlMember.