WPF Skin Skinning Sicherheitsprobleme

Question

Ich bin wirklich neu in der WPF in der .Net Framework (erhalten, dass aus dem Weg). Ich schreibe eine Anwendung, wo die Schnittstelle ist sehr anpassbar durch einfaches Laden .xaml (im Moment ein Page-Element) Dateien in einen Rahmen und dann die Steuerelemente über Namen nach Bedarf zuordnen. Die Idee ist, eine Gemeinschaft von Menschen, die bei der Herstellung von Skins interessiert sind, Haut meine Anwendung, wie sie wollen (ähnlich wie Winamp) haben.

Nun stellt sich aufgrund meiner mangelnden Xaml-Kenntnisse die Frage, ob es möglich ist, bösartige Xaml-Seiten zu erstellen, die, wenn sie heruntergeladen und verwendet werden, andere eingebettete Iframes oder andere Elemente haben könnten, die HTML einbetten oder entfernte Webseiten mit bösartigem Inhalt aufrufen könnten? Ich glaube, dass dies der Fall sein könnte.

Wenn dies der Fall ist, dann habe ich zwei Möglichkeiten: Entweder ich habe einen automatisierten Prozess, der diese Arten von Xaml-Dateien entfernen kann, indem er die Elemente überprüft, bevor er den Download zulässt (was vermutlich am schwierigsten wäre), oder ich lasse sie von einem Menschen vor dem Download überprüfen. Gibt es Alternativen, die ich noch nicht kenne, die diesen ganzen Prozess viel einfacher machen könnten?

Answer 1

Wenn Sie die XAML einfach laden, ohne irgendwelche Vorsichtsmaßnahmen zu treffen, gibt es zwei mögliche Probleme:

1. Die XAML kann mit "x:Static" und "ObjectDataSource" Methoden für Ihre Objekte aufrufen.
2. Die XAML kann HTML und Bilder von beliebigen Uris einbinden. Wenn also ein Fehler im HTML- oder Bildverarbeitungscode auftritt, könnte Malware diesen ausnutzen.

Die Lösung besteht aus zwei Teilen:

1. Begrenzen Sie die Klassen, die instanziiert werden können.
2. Beschränken Sie die Einstellung von Uri-Eigenschaften nur auf relative Quellen.

Begrenzung der Klassen, die instanziiert werden können

Glücklicherweise gibt es nur eine begrenzte Anzahl von Orten, an denen Typen auftreten können: Elementnamen, Namen von angehängten Eigenschaften, Markup-Erweiterungen, Eigenschaften vom Typ "Typ". Indem nur die Standard-Typ-Erweiterungen verboten werden, ist es recht einfach, nach allen Verwendungen zu suchen und eine vollständige Liste der in der XAML referenzierten Typen zu erstellen. Diese kann mit einer Whitelist bekannter sicherer Typen abgeglichen werden. Alle Typen, die nicht in der Liste der sicheren Typen aufgeführt sind, führen dazu, dass die XAML zurückgewiesen wird.

Hinweis: Der eingebaute XamlReader erlaubt es Ihnen nicht, einen benutzerdefinierten IXamlTypeResolver bereitzustellen. Ich verwende einen erweiterten XamlReader, den ich geschrieben habe und der einen benutzerdefinierten IXamlTypeResolver erlaubt, so dass ich tatsächlich jeden Typ erkennen kann, der in der XAML zur Ladezeit und zur Laufzeit referenziert wird, ohne überhaupt ein Parsing durchzuführen: Jeder Typ, der nicht auf der Whitelist steht, wird einfach nicht aufgelöst.

Einschränkung der Einstellung von Uri-Eigenschaften

Auch hier kommt uns die starre Struktur von XAML zu Hilfe. Sie kann leicht gescannt werden, um jeden Property Setter, der aufgerufen wird, und den Wert oder die Bindung, die gesetzt werden soll, zu bestimmen (Stile und angehängte Eigenschaften nicht vergessen). Die XAML kann zurückgewiesen werden, wenn ein absoluter Uri außer einem pack Uri verwendet wird. Versuche, einen Uri mit einer Markup-Erweiterung zu setzen, würden ebenfalls abgelehnt werden.