XAML-Sicherheitsüberlegungen

  • Artikel

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

Nicht vertrauenswürdiges XAML in Anwendungen

Im Allgemeinen ist nicht vertrauenswürdiger XAML-Code jede XAML-Quelle, die Ihre Anwendung nicht ausdrücklich ein- oder ausgeschlossen hat.

XAML, das in einer vertrauenswürdigen und signierten Assembly als Ressource vom Typ resx kompiliert oder gespeichert wird, ist nicht unbedingt nicht vertrauenswürdig. Sie können dem XAML ebenso vertrauen wie der Assembly als Ganzes. In den meisten Fällen sind Vertrauensaspekte eher bei Loose XAML relevant, also einer XAML-Quelle, die Sie aus einem Datenstrom oder anderen Ein-/Ausgängen laden. Loose XAML ist keine bestimmte Komponente oder ein Feature eines Anwendungsmodells mit einer Bereitstellungs- und Paketinfrastruktur. Eine Assembly kann jedoch ein Verhalten implementieren, das das Laden von Loose XAML umfasst.

Nicht vertrauenswürdigen XAML-Code sollten Sie im Allgemeinen genauso behandeln wie anderen nicht vertrauenswürdigen Code. Verwenden Sie eine Sandbox oder eine andere Möglichkeit, um zu verhindern, dass möglicherweise nicht vertrauenswürdiger XAML-Code auf Ihren vertrauenswürdigen Code zugreift.

XAML-Funktionen bietet XAML-Code nativ die Möglichkeit, Objekte zu erstellen und ihre Eigenschaften festzulegen. Diese Funktionen umfassen auch den Zugriff auf Typkonverter, Zuordnungen und Assemblys in der Anwendungsdomäne über Markuperweiterungen, x:Code-Blöcke usw.

Zusätzlich zu seinen Funktionen auf Sprachebene wird XAML in vielen Technologien für die Definition von Benutzeroberflächenelementen verwendet. Das Laden von nicht vertrauenswürdigem XAML-Code bedeutet möglicherweise das Laden einer Benutzeroberfläche für böswilliges Spoofing.

Freigeben des Kontexts zwischen Readern und Writern

Die .NET XAML-Dienstarchitektur für XAML-Reader und -Writer erfordert häufig die Freigabe eines XAML-Readers an einen XAML-Writer oder einen freigegebenen XAML-Schemakontext. Das Freigeben von Objekten oder Kontexten kann erforderlich sein, wenn Sie XAML-Knotenschleifenlogik schreiben oder einen benutzerdefinierten Speicherpfad bereitstellen. Geben Sie keine XAML-Readerinstanzen, nicht standardmäßige XAML-Schemakontexte oder Einstellungen für XAML-Reader/-Writer-Klassen zwischen vertrauenswürdigem und nicht vertrauenswürdigem Code frei.

In den meisten Szenarien und Vorgänge, die das Schreiben von XAML-Objekten für einen CLR-basierten Typ unterstützen, kann nur der Standard-XAML-Schemakontext verwendet werden. Der Standard-XAML-Schemakontext enthält explizit keine Einstellungen, die eine volle Vertrauenswürdigkeit beeinträchtigen könnten. Daher ist es sicher, den Kontext zwischen vertrauenswürdigen und nicht vertrauenswürdigen Komponenten von XAML-Readern/-Writern zu teilen. Auch in diesem Fall ist es immer noch eine bewährte Methode, solche Reader und Writer in separaten AppDomain-Bereichen zu platzieren und einen davon speziell für die teilweise Vertrauenswürdigkeit vorzusehen oder in einer Sandbox auszuführen.

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 einer nicht vertrauenswürdigen Assembly, wenn sie in die Anwendungsdomäne geladen wurde. Daher ist es technisch möglich, dass eine nicht vertrauenswürdige Assembly die beabsichtigte XAML-Namespacezuordnung einer vertrauenswürdigen Assembly spooft und die Informationen der deklarierten Objekte und Eigenschaften einer XAML-Quelle abfängt. Wenn Ihre Sicherheitsanforderungen vorschreiben, eine solche Situation zu vermeiden, sollte Ihre beabsichtigte XAML-Namespacezuordnung mithilfe einer der folgenden Techniken erstellt werden:

  • Verwenden Sie in jeder XAML-Namespacezuordnung, die im XAML-Code Ihrer Anwendung erstellt wird, einen vollqualifizierten, starken Assemblynamen.

  • Beschränken Sie Assemblyzuordnungen auf einen festen Satz von Referenzassemblys, indem Sie einen bestimmten XamlSchemaContext für Ihre XAML-Reader und XAML-Objektwriter erstellen. Siehe XamlSchemaContext(IEnumerable<Assembly>).

Typzuordnung und Typsystemzugriff in XAML

XAML unterstützt ein eigenes Typsystem, das weitgehend der CLR-Implementierung des grundlegenden CLR-Typsystem entspricht. Bei bestimmten Aspekten von Typinformationen, bei denen Sie Entscheidungen zur Vertrauensstellung für einen Typ basierend auf seinen Typinformationen treffen, sollten Sie jedoch die Typinformationen auf die zugrunde liegenden CLR-Typen zurückführen. Dies liegt daran, dass einige der spezifischen Berichtsfunktionen des XAML-Typsystems als virtuelle Methoden geöffnet bleiben und daher nicht vollständig von den ursprünglichen .NET XAML-Dienstimplementierungen gesteuert werden. Diese Möglichkeiten zur Erweiterung bestehen, da das XAML-Typsystem erweiterbar ist, um der Erweiterbarkeit von XAML selbst und seinen möglichen alternativen Typzuordnungsstrategien im Gegensatz zur standardmäßigen CLR-Implementierung und zum Standard-XAML-Schemakontext zu entsprechen. Weitere Informationen finden Sie in den spezifischen Hinweisen zu den Eigenschaften von XamlType und XamlMember.

Weitere Informationen