Freigeben über

Überlegungen zur XAML-Sicherheit

  • Artikel

In diesem Artikel werden bewährte Methoden für die Sicherheit in Anwendungen beschrieben, wenn Sie XAML- und .NET-XAML-Dienste-API verwenden.

Nicht vertrauenswürdiges XAML in Anwendungen

Im allgemeinen ist nicht vertrauenswürdiger XAML-Code eine XAML-Quelle, die Ihre Anwendung nicht ausdrücklich eingeschlossen oder ausgegeben hat.

XAML, das in einer vertrauenswürdigen und signierten Assembly als resx-Typressource kompiliert oder gespeichert wird, ist nicht vertrauenswürdig. Sie können dem XAML so viel vertrauen, wie Sie der Assembly als Ganzes vertrauen. In den meisten Fällen beschäftigen Sie sich nur mit den Vertrauensaspekten von losem XAML, einer XAML-Quelle, die Sie aus einem Stream oder anderen E/A laden. Lose XAML ist keine bestimmte Komponente oder ein Feature eines Anwendungsmodells mit einer Bereitstellungs- und Verpackungsinfrastruktur. Eine Assembly kann jedoch ein Verhalten implementieren, das das Laden von losem XAML umfasst.

Bei nicht vertrauenswürdigen XAML sollten Sie es im Allgemeinen genauso behandeln, als ob es nicht vertrauenswürdiger Code wäre. Verwenden Sie Sandkasten oder andere Metaphern, um zu verhindern, dass möglicherweise nicht vertrauenswürdiges XAML auf Ihren vertrauenswürdigen Code zugreift.

Die Art der XAML-Funktionen bietet dem XAML-Code das Recht, Objekte zu erstellen und ihre Eigenschaften festzulegen. Zu diesen Funktionen gehören auch der Zugriff auf Typkonverter, das Zuordnen und Zugreifen auf Assemblys in der Anwendungsdomäne, die Verwendung von Markuperweiterungen, x:Code Blöcke usw.

Zusätzlich zu den Funktionen auf Sprachebene wird XAML für die UI-Definition in vielen Technologien verwendet. Das Laden nicht vertrauenswürdiger XAML-Code bedeutet möglicherweise das Laden einer bösartigen Spoofing-UI.

Freigeben des Kontexts zwischen Lesern und Autoren

Die .NET XAML Services-Architektur für XAML-Leser und XAML-Autoren erfordert häufig die Freigabe eines XAML-Readers an einen XAML-Writer oder einen freigegebenen XAML-Schemakontext. Das Freigeben von Objekten oder Kontexten ist möglicherweise erforderlich, wenn Sie XAML-Knotenschleifenlogik schreiben oder einen benutzerdefinierten Speicherpfad bereitstellen. Geben Sie keine XAML-Readerinstanzen, nicht standardmäßigen XAML-Schemakontext oder Einstellungen für XAML-Reader-/Writer-Klassen zwischen vertrauenswürdigen und nicht vertrauenswürdigen Code gemeinsam.

Die meisten Szenarien und Vorgänge, die das Schreiben von XAML-Objekten für eine CLR-basierte Typsicherung umfassen, können nur den standardmäßigen XAML-Schemakontext verwenden. Der standardmäßige XAML-Schemakontext enthält nicht explizit Einstellungen, die eine vollständige Vertrauenswürdigstellung gefährden könnten. Daher ist es sicher, den Kontext zwischen vertrauenswürdigen und nicht vertrauenswürdigen XAML-Lese-/Schreibkomponenten zu teilen. Wenn Sie dies tun, ist es jedoch immer noch eine bewährte Methode, solche Leser und Autoren in separaten AppDomain Bereichen zu halten, wobei einer von ihnen speziell für die teilweise vertrauenswürdige/Sandkasten vorgesehen ist.

XAML-Namespaces und Assemblyvertrauensstellung

Die grundlegende nicht qualifizierte Syntax und Definition für die Interpretation einer benutzerdefinierten XAML-Namespacezuordnung zu einer Assembly unterscheidet nicht zwischen einer vertrauenswürdigen und nicht vertrauenswürdigen Assembly, die in die Anwendungsdomäne geladen wird. Daher ist es technisch möglich, dass eine nicht vertrauenswürdige Assembly die beabsichtigte XAML-Namespacezuordnung einer vertrauenswürdigen Assembly spooft und die deklarierten Objekt- und Eigenschaftsinformationen einer XAML-Quelle erfasst. Wenn Sie Sicherheitsanforderungen haben, um diese Situation zu vermeiden, sollten Sie die beabsichtigte XAML-Namespacezuordnung mit einer der folgenden Techniken erstellen:

  • Verwenden Sie einen vollqualifizierten Assemblynamen mit starkem Namen in jeder XAML-Namespacezuordnung, die vom XAML-Code Ihrer Anwendung erstellt wird.

  • Beschränken Sie die Assemblyzuordnung auf einen festen Satz von Referenzassemblys, indem Sie eine bestimmte XamlSchemaContext für Ihre XAML-Leser und XAML-Objektautoren erstellen. Siehe XamlSchemaContext(IEnumerable<Assembly>).

XAML-Typzuordnung und Systemzugriff

XAML unterstützt ein eigenes Typsystem, das auf viele Arten ein Peer ist, wie CLR das grundlegende CLR-Typsystem implementiert. Bei bestimmten Aspekten des Typbewusstseins, bei denen Sie vertrauenswürdige Entscheidungen zu einem Typ basierend auf seinen Typinformationen treffen, sollten Sie jedoch auf die Typinformationen in den CLR-Sicherungstypen zurückstellen. Dies liegt daran, dass einige der spezifischen Berichterstellungsfunktionen des XAML-Typsystems als virtuelle Methoden geöffnet bleiben und daher nicht vollständig unter der Kontrolle der ursprünglichen .NET XAML Services-Implementierungen liegen. Diese Erweiterbarkeitspunkte sind vorhanden, da das XAML-Typsystem erweiterbar ist, um der Erweiterbarkeit von XAML selbst und den möglichen alternativen Typzuordnungsstrategien gegenüber der standardmäßigen CLR-gesicherten Implementierung und dem Standardmäßigen XAML-Schemakontext zu entsprechen. Weitere Informationen finden Sie in den spezifischen Hinweisen zu mehreren Eigenschaften von XamlType und XamlMember.

Siehe auch