Silverlight: Avoiding Cross-Site Scripting Attacks
Written by Andrew Ivanov Monday, 27 August 2012
In Silverlight, XSS issues typically occur when attacker-controlled strings are inserted into markup without first validating or escaping the attacker-controlled string.
The following is a list of scenarios when you need to be careful of exposing an XSS vulnerability. Many of the mitigations listed are called out in other sections of this document. However, it is important that you also understand these vulnerabilities in the context of XSS issues.
- Loading untrusted XAML with the XamlReader.Load method. You should never load a string or partial string from an unknown user. For more information, see Using XamlReader.Load.
- Setting the Xaml property on the RichTextBox control to an attacker-provided string.
- Loading an untrusted assembly with the Assembly.Load method.
- Creating XML by combining strings. For example, you might do this to create XML to send to a REST service. Use the XmlWriter and XElement classes to create more secure XML. For more information, see Security Considerations (XML Data in Silverlight).
- Using Silverlight to create HTML with the classes provided by the System.Windows.Browser namespace, or allowing untrusted access from the Silverlight plug-in to the hosting page. For more information, see the Settings.EnableHTMLAccess property.
- Using Silverlight to display attacker-provided HTML with the WebBrowser.NavigateToString method. You can do this only, in an out-of-browser application. Silverlight 4 and later.
- Hosting an attacker’s XAP file from your Web server, perhaps by allowing user uploads.