WPF Skin Skinning Security Concerns

I'm really new to the WPF in the .Net Framework (get that out of the way). I'm writing an application where the interface is very customizable by simply loading .xaml (at the moment a Page element) files into a frame and then mapping the controls via names as needed. The idea is to have a community of people who are interested in making skins, skin my application however they want (much like Winamp).

Now the question arises, due to my lack of Xaml knowledge, is it possible to create malicious Xaml pages that when downloaded and used could have other embedded Iframes or other elements that could have embed html or call remote webpages with malicious content? I believe this could be the case.

If this is the case then I two options; either I have an automated process that开发者_如何学Go can remove these types of Xaml files by checking it’s elements prior to allowing download (which I would assume would be most difficult) or have a human review them prior to download. Are there alternatives I’m unaware of that could make this whole process a lot easier?

If you simply load the XAML without taking any precautions there are two potential concerns:

1. The XAML can call methods on your objects using "x:Static" and "ObjectDataSource"
2. The XAML can incorporate HTML and images from arbitrary Uris, so if there is a bug in the HTML-processing or image-processing code, malware could exploit it

The solution is twofold:

1. Limit the classes that can be instantiated.
2. Restrict the setting of Uri properties to relative sources only.

Limiting the classes that can be instantiated

Fortunately there are only a limited number of places types can appear: Element names, Attached-property names, Markup extensions, properties of type "Type". By disallowing any but the standard type extensions, it is quite simple to scan for all of usages and built a complete list of types referenced in the XAML. This can be checked against a whitelist of known-safe types. Any types referenced that aren't on the safe list cause the XAML to be rejected.

Note: The built-in XamlReader doesn't allow you to provide a custom IXamlTypeResolver. I use an enhanced XamlReader I wrote that that allows a custom IXamlTypeResolver, so I can actually detect every type that is referenced in the XAML at load time and run time without doing any parsing at all: Just fail to resolve any type type not on the whitelist.

Restricting the setting of Uri properties

Again the rigid structure of XAML comes to our aid. It can easily be scanned to determine every property setter that will be called and the value or binding to be set (don't forget styles and attached properties). The XAML can be rejected if any absolute Uri except a pack Uri is used. Attempts to set a Uri using a markup extension would be similarly rejected.