Security Overview Silverlight 4 applications. Part 2

In the continuation to the first part , in which we looked at how Silverlight protects the end user. In this part, we will look at how to create secure sites using Silverlight. All links at the end of the topic.

Creating Secure Websites Using Silverlight

Sites using Silverlight have the same security issues as regular sites that do not use it.

Cross Site Scripting (XSS)

As with regular HTML sites, Silverlight developers need to be attentive to the XSS problem. XSS allows an attacker to run program code on a client’s computer. This gives the attacker access to cookies and other confidential information. Having this information has a different impact on security. For online stores, an attacker can order products in the user name. Other bad things can be done in banks.

XSS problems are possible in Silverlight, but they are less likely than in traditional HTML. Problems arise when an attacker sends a dangerous string to an uncontrolled field. Here are some examples when XSS vulnerability is possible:

Call XamlReader.Load () on a string passed by the attacker. You cannot call this method without first checking the string for XSS.
Calling Assembly.Load () for a harmful DLL
Creating XML by concatenating strings, for example, in order to send a request for a REST service. (System.Xml provides more efficient ways to create XML, including System.Xml.XmlWriter System.Xml.Linq.XElement)
Using Silverlight to create HTML through System.Windows.Browser
Use System.Windows.Controls.WebBrowser.NavigateToString () in the browser from within the application.
.Xap files uploaded by users.

Silverlight Isolation with HTML / JavaScript

Silverlight runs as part of the HTML page, but what happens if the application does not trust HTML or vice versa? Silverlight allows you to block communication in both directions. Blocked by default when .XAP and HTML are loaded from different domains.

The EnableHtmlAccess property allows .XAP to invoke JavaScript methods and modify HTML pages. EnableHtmlAccess is specified in the <object> tag when inserting Silverlight. If .XAP and HTML are from the same domain, then by default the property is enabled otherwise - no.

The ExternalCallersFromCrossDomain property and the [ScriptableTypeAttribute] / [ScriptableMemberAttribute] attributes specify .XAP and allow you to control whether these methods can be called from JavaScript. In order for JavaScript to call these methods, it must pass the ExternalCallersFromCrossDomain check and the class must be decorated with [ScriptableTypeAttribute] and this method must be [ScriptableMemberAttribute]. JavaScript can only call methods of classes specified in the application. ExternalCallersFromCrossDomain has two settings, ScriptableOnly and NoAccess with NoAccess default.

Isolating Silverlight code from other Silverlight code

In order to isolate Silverlight code from other Silverlight code, you need to run them in separate applications hosted on separate domains.

Data transfer between Silverlight applications

Silverlight applications running in separate <object> tags can communicate either using JavaScript or using System.Windows.Messaging.LocalMessageReceiver / LocalMessageSender. Messaging allows applications to send messages to other applications and receive them. By default, senders are sent, and recipients only accept messages from applications that are located on the same domain. You can add trusted domains for senders and recipients. Clients can use Global reach. They should be used carefully, as the sender and recipient can be from any domain. There is no way to check for which domain the message is sent, however the recipient knows which domain sent it.

Prevent unauthorized file reuse. Xap

To check that your .XAP is placed on the page, you need to include the following XAP code in startup:

If (App.Current.Host.Settings.EnableHTMLAccess == false ) throw new Exception(); string htmlurl = System.Windows.Browser.HtmlPage.Document.DocumentUri.ToString(); if (htmlurl != “http: //foo.com/mypage.html”) throw new Exception(); * This source code was highlighted with Source Code Highlighter .

Validation on the server

Silverlight applications do not change the way server requests are authenticated.

Verification of incoming data - like non-Silverlight sites, on the server you need to make sure that the input data does not contain SQL, HTML / JavaScript commands, which will subsequently be displayed on the page. Keep in mind that an attacker may not use the Silverlight application, but send the HTTP request directly to the server bypassing the application.

Securing Services - Silverlight applications often use services as a link between an application and a server. These interfaces must be protected and verified.

Fake Cross Domain Requests (CSRF) - Web servers should verify that requests come from the correct page. For example, see the Microsoft security policy file http://microsoft.com/clientaccesspolicy.xml. The site indicates which URLs can make cross-domain queries.

Protection of information inside. Xap

Storing confidential information (such as passwords, keys, or proprietary algorithms) in the .XAP file is problematic. In general, it is not possible to protect such information from an attacker. Libraries can be encoded using .NET obfuscators. However, while obfuscation can slow the attacker, but can not interfere. The search also shows that there are XAML markup obfuscators .

API for security

Silverlight offers a variety of security services and APIs to ensure the integrity and confidentiality of data transmitted over the network.

HTTPS is supported for both .XAP and for any requests it sends. Silverlight 4 Beta adds support for the Referer header, which allows the server to know where the user came from. You need to be careful when using the Referer header and not use it for security checks. An attacker can set any value to this header.

System.Security.Cryptography contains interfaces for AES private key encryption , SHA1 and SHA256 hashing, and HMAC digital signatures . (Silverlight does not include public key encryption)

Silverlight supports PlayReady digital rights management (DRM) to control access to media files. Silverlight 4 Beta adds support for H.264 protection and protection for offline scripts.

Conclusion

Silverlight was built from the ground up with safety as a top priority. Silverlight isolates web applications to protect users from malicious websites. Silverlight also helps keep your website safe from attack, providing default settings and making XSS errors difficult to implement. Understanding the security model of Silverlight helps you create secure websites that use Silverlight.