Рекомендации по безопасности XAML

  • Статья

В этой статье описаны рекомендации по обеспечению безопасности в приложениях при использовании API СЛУЖБ XAML и .NET XAML.

Ненадежный XAML в приложениях

В самом общем смысле ненадежный КОД XAML — это любой источник XAML, который приложение не включало или не выдало.

XAML, скомпилированный в или хранящийся в качестве ресурса типа в доверенной resxи подписанной сборке, по сути не является доверенным. Вы можете доверять XAML столько, сколько вы доверяете сборке в целом. В большинстве случаев вы относитесь только к аспектам доверия свободного XAML, который является источником XAML, который вы загружаете из потока или других операций ввода-вывода. Свободный XAML не является определенным компонентом или компонентом модели приложения с инфраструктурой развертывания и упаковки. Однако сборка может реализовать поведение, включающее загрузку свободного XAML.

Для ненадежного XAML обычно следует рассматривать его так же, как если бы он был ненадежным кодом. Используйте песочницу или другие метафоры, чтобы предотвратить доступ к доверенному коду XAML, возможно, ненадежным XAML.

Характер возможностей XAML дает XAML право создавать объекты и задавать их свойства. Эти возможности также включают доступ к преобразователям типов, сопоставлению и доступу к сборкам в домене приложения, использованию расширений разметки, x:Code блоков и т. д.

Помимо возможностей на уровне языка XAML используется для определения пользовательского интерфейса во многих технологиях. Загрузка ненадежного XAML может означать загрузку вредоносного пользовательского интерфейса спуфингирования.

Общий доступ к контексту между средствами чтения и записи

Архитектура служб XAML для средств чтения XAML и записи XAML часто требует совместного использования средства чтения XAML в модуль записи XAML или контекста общей схемы XAML. При написании логики цикла узла XAML или предоставления пользовательского пути сохранения может потребоваться общий доступ к объектам или контекстам. Не делитесь экземплярами средства чтения XAML, контекстом схемы XAML или параметрами для классов чтения и записи XAML между доверенным и ненадежным кодом.

Большинство сценариев и операций, связанных с записью объектов XAML для резервного копирования типов clR, могут использовать только контекст схемы XAML по умолчанию. Контекст схемы XAML по умолчанию явно не включает параметры, которые могут компрометации полного доверия. Таким образом, безопасно предоставлять общий доступ к контексту между доверенными и ненадежными компонентами чтения и записи XAML. Однако, если вы делаете это, это по-прежнему рекомендуется держать таких читателей и писателей в отдельных AppDomain область, с одним из них специально предназначен или песочниц для частичного доверия.

Пространства имен XAML и доверие сборок

Базовый нечеткий синтаксис и определение того, как XAML интерпретирует сопоставление пользовательского пространства имен XAML с сборкой, не отличается от доверенной и ненадежной сборки, загруженной в домен приложения. Таким образом, техническая возможность ненадежной сборки позволяет спуфинировать предполагаемое сопоставление пространства имен XAML доверенной сборки и записывать объявленные объекты и сведения о свойстве источника XAML. Если у вас есть требования к безопасности, чтобы избежать этой ситуации, необходимо выполнить сопоставление пространства имен XAML с помощью одного из следующих методов:

  • Используйте полное имя сборки с строгим именем в любом сопоставлении пространства имен XAML приложения.

  • Ограничение сопоставления сборок фиксированному набору ссылочных сборок путем создания определенного XamlSchemaContext для средств чтения XAML и записи объектов XAML. См. раздел XamlSchemaContext(IEnumerable<Assembly>).

Сопоставление типов XAML и системный доступ к типам

XAML поддерживает собственную систему типов, которая во многих отношениях является одноранговым элементом для реализации базовой системы типов CLR. Однако для определенных аспектов осведомленности о типе, когда вы принимаете решения о доверии о типе на основе сведений о типе, следует отложить сведения о типе в типах поддержки CLR. Это связано с тем, что некоторые возможности создания отчетов системы типов XAML остаются открытыми как виртуальные методы и поэтому не полностью находятся под контролем исходных реализаций служб XAML .NET. Эти точки расширяемости существуют, так как система типов XAML расширяема, чтобы сопоставить расширяемость самого XAML и ее возможные альтернативные стратегии сопоставления типов и контекст схемы XAML по умолчанию. Дополнительные сведения см. в конкретных заметках по нескольким свойствам XamlType и XamlMember.

См. также