We can see serious movements that took place in the development of applications during the last years. 5-10 years ago the majority of applications were desktop. Today web-applications also become popular.

Web-applications become popular, so the market of technologies is changing. We can see that a Silverlight application becomes more popular. It is a class of applications which are named Rich Internet Applications.

Undoubtedly, a way of interaction with a server is one of the main factors of web-applications developing. Interaction with a server should be simple and convenient, it is important.

Today interactions with a server in Silverlight applications are usually built through web-services. Web-services assume data exchange in XML format between a client and a server via protocol SOAP or REST. Besides, client’s applications can request other resources from a server. Undoubtedly, all these ways present the developer with convenient tools for an applications building. However, such forms of interaction contain certain threats.

Let us have a look at ways of Silverlight applications interaction with a server, and then we will find out what threats exist and how they can be eliminated.

In Silverlight application since version 2 appeared to establish communication with a server became very convenient. For receiving some data through HTTP protocol in Silverlight, it is possible to use two mechanisms - WebClient and HttpWebRequest.

The WebClient allows easier access to a server, but it is less flexible. The example of WebClient usage is shown in listing 1.

Listing 1 - Sample of usage WebClient

private void Communicate()
{
      var client = new WebClient();
 
      client.DownloadStringCompleted += client_DownloadStringCompleted;
      client.DownloadProgressChanged += client_DownloadProgressChanged;
 
      client.DownloadStringAsync(new Uri(@"http://localhost/mydata.xml"));
}
 
void client_DownloadProgressChanged(object sender, DownloadProgressChangedEventArgs e)
{
      // inform client about progress
}
 
void client_DownloadStringCompleted(object sender, DownloadStringCompletedEventArgs e)
{
      if (e.Error == null)
      {
            var data = e.Result;
            // use the variable "data"
      }
      else
      {
            // error
      }
}

Other ways consist of using the HttpWebRequest/HttpWebResponse object. An example of WebRequest usage is shown in listing 2.

Listing 2 - Sample of usage WebRequest

private void Communicate()
{
      var webRequest = WebRequest.Create("http://localhost/mydata.xml") as
            HttpWebRequest;
      webRequest.Method = "GET";
      webRequest.BeginGetResponse(ResponseCallback, webRequest);
}
 
void ResponseCallback(IAsyncResult ar)
{
      var webRequest = ar.AsyncState as HttpWebRequest;
      var webResponse = webRequest.EndGetResponse(ar);
 
      var responseStream = webResponse.GetResponseStream();
      // reading the stream
}

These two ways can be used when it is necessary to obtain any data via HTTP protocol. However, if we work with web-services, it is more convenient to use a proxy-class and to do calls through it. This approach hides details of receiving data through WebRequest object, parsing and XML generation in SOAP/REST format.

It is necessary to use "Add Service Referece" item in popup menu of "References" item to create proxy-class.

Figure 1: Adding service reference

After proxy-class generation one can use it easily. The example of the access to service is shown in listing 3.

Listing 3 - An accessing to the service

private void Button_Click(object sender, RoutedEventArgs e)
{
      WebService1SoapClient client = new WebService1SoapClient();
      client.HelloWorldCompleted += client_HelloWorldCompleted;
      client.HelloWorldAsync();
}
 
void client_HelloWorldCompleted(object sender, HelloWorldCompletedEventArgs e)
{
      var result = e.Result;
      // do something
}

We have already looked at how to construct a simple access with a server. However, the use of such approaches cannot always be safe. Let us consider some scenarios.

Let us assume you have a bank account and you can work with this account through the Internet in a browser. To work with the bank web-application you authenticate on a bank web-site and a server places record about it in your cookie. Actually, this record in cookie distinguishes you from other a non-authenticated user. Now let us assume that there is a violator who wishes to get access to your bank account. The violator can create Silverlight application which works in your browser. Feature of such applications is that at the accessing to a server they can also use earlier set cookie for this web-site. All the violator needs is to force you to start this application. This application can be hidden in a naive joke displaying a funny card. But actually this application will access to the bank web-application, using your data, to transfer money for another account. It is possible to present this situation in a following scheme.

Figure 2: Multiple access to a server

Let us consider another dangerous scenario.

Let us assume that web-service is located on a server, which carries out labour-consuming operations. For example, for each operation the essential quantity of processor time or any other expensive resources is required. In this case a violator can place the application on the server to generate some accesses to this operation simultaneously. Then he can make a great number of people enter the site and thus arrange massed DoS attack on the application. Such attacks are especially dangerous, because such accesses occur from different computers. Therefore it is impossible just to block a range of IP-addresses for attack prevention.

Earlier we have considered various kinds of attacks which can be carried out using Silverlight applications. For prevention of such attacks special safety measures which are called "Crossdomain Client Access Policy" exist. Let us consider how it works.

The main idea is that applications any accesses to data which are out of the domain from Silverlight are forbidden by default.

It is possible to present it schematically as follows.

Figure 3: The cross-domain access

Such restriction guarantees that no other applications from other domains can access to a server.

It is important that this restriction is implemented at Silverlight level, e.g. Silverlight Runtime, to ensure the functionality of this mechanism. For Silverlight developers such an approach means that at the access to a server from the application from other domain a SecurityException will be thrown. This restriction extends not only to web-services but also to any other data which we try to receive from Silverlight applications (for example, a simple XML-file).

We have seen that all accesses from Silverlight application out of the domain are forbidden by default. However it is necessary to allow accesses from other domains in some situations.

Actually at the access to a resource from other domain, Silverlight Runtime checks if "clientaccesspolicy.xml" file which should be in a root of the given domain exists. If this file is found, parameters of the access to this domain are set in it.

If the file is not found, attempt of search of "crossdomain.xml" file, which is necessary for Adobe Flash applications work, will be made. If both files are not found, the access to the domain is blocked outside.

To understand how it works, let us make some experiments. For this purpose we need to create some websites that work in different domains. For our experiment, such sites can be defined in a "hosts" file which is located in a "%windir %\System32\drivers\etc" folder. For example, it is possible to define this file as follows.

Listing 4 - The "host" file sample

127.0.0.1   site1.com
127.0.0.1   api.site1.com
127.0.0.1   subdomain.api.site1.com
127.0.0.1   site2.com
127.0.0.1   site3.com

From this listing we can see that we define some domains which refer to local IP-address. It is now necessary to create in some sites in IIS for each of the domains.

Let us place a file "data.xml" on a web-site "api.site1.com" and we will create small Silverlight application which will access this file. There will be some lines of a code which load a XML-file in an asynchronous mode to this application.

Listing 5 - Sample of Silverlight application

private void GetDataButton_Click(object sender, RoutedEventArgs e)
{
      var client = new WebClient();
      client.DownloadStringCompleted += client_DownloadStringCompleted;
      client.DownloadStringAsync(new Uri(ServerURI.Text));
 
      Data.Text = "Loading..";
}
 
void client_DownloadStringCompleted(object sender, DownloadStringCompletedEventArgs e)
{
      if (e.Error == null)
      {
            Data.Text = e.Result;
      }
      else
      {
            Data.Text = "Error: " + e.Error.ToString();
      }
}

Let us place this application in each domain and try to access to service. Now applications in all domains, except api.site1.com, will throw a SecurityException.

To resolve cross-domain access to "api.site1.com" the domain we will place "clientaccesspolicy.xml" within a web-site "api.site1.com". Thus this file should have the address "http://api.site1.com/clientaccesspolicy.xml". This file has the following format.

Listing 6 - Sample of "clientaccesspolicy.xml" file

<?xml version="1.0" encoding="utf-8" ?>
<access-policy>
      <cross-domain-access>
            <policy>
                  <allow-from>
                        <domain uri="*" />
                  </allow-from>
                  <grant-to>
                        <resource path="/" include-subpaths="true" />
                  </grant-to>
            </policy>
      </cross-domain-access>
</access-policy>

When we place this file within the specified domain all cross-domain access becomes possible and all applications from various domains can access it. We can be sure that our Silverlight application has been correctly set up if we can access our test application from the different domains that we have previously deployed.

Besides, it is possible to adjust the policy so that access is possible from  only some domains. For example, the "clientaccesspolicy.xml" file can look as follows.

Listing 7 - Sample of "clientaccesspolicy.xml" file

<?xml version="1.0" encoding="utf-8" ?>
<access-policy>
<cross-domain-access>
<policy>
<allow-from>
<domain uri="http://site1.com/" />
<domain uri="http://site2.com/" />
</allow-from>
<grant-to>
<resource path="/" include-subpaths="true" />
</grant-to>
</policy>
</cross-domain-access>
</access-policy>

In this case we allow access only from domains site1.com and site2.com.

In other case we can define not only certain domains, but also subdomains.

Listing 8 - Sample of "clientaccesspolicy.xml" file

<?xml version="1.0" encoding="utf-8" ?>
<access-policy>
      <cross-domain-access>
            <policy>
                  <allow-from>
                        <domain uri="http://*.site1.com/" />
                  </allow-from>
                  <grant-to>
                        <resource path="/" include-subpaths="true" />
                  </grant-to>
            </policy>
      </cross-domain-access>
</access-policy>

In this case access is possible from all subdomains *.site1.com.

Also it is possible to limit which port and protocol will be used. For example, we will allow access only via HTTPS for all sites.

Listing 9 - Sample of "clientaccesspolicy.xml" file

<?xml version="1.0" encoding="utf-8" ?>
<access-policy>
      <cross-domain-access>
            <policy>
                  <allow-from>
                        <domain uri="https://*" />
                  </allow-from>
                  <grant-to>
                        <resource path="/" include-subpaths="true" />
                  </grant-to>
            </policy>
      </cross-domain-access>
</access-policy>

Besides, it is possible to limit a set of resources which are accessible from outside of current domain. For example, it is possible to specify that only the "data.xml" file can be accessible out of the domain.

Listing 10 - Sample of "clientaccesspolicy.xml" file

<?xml version="1.0" encoding="utf-8" ?>
<access-policy>
      <cross-domain-access>
            <policy>
                  <allow-from>
                        <domain uri="*" />
                  </allow-from>
                  <grant-to>
                        <resource path="data.xml" include-subpaths="false" />
                  </grant-to>
            </policy>
      </cross-domain-access>
</access-policy>

Besides, it is possible to demand HTTP-heading presence in request.

In this case cross-domain access is allowed only in case of this header presence.

Listing 11 - Sample of "clientaccesspolicy.xml" file

<?xml version="1.0" encoding="utf-8" ?>
<access-policy>
      <cross-domain-access>
            <policy>
                  <allow-from http-request-headers="SOAPAction"> 
                        <domain uri="*" />
                  </allow-from>
                  <grant-to>
                        <resource path="/" include-subpaths="true" />
                  </grant-to>
            </policy>
      </cross-domain-access>
</access-policy>

Undoubtedly such permission of access to the domain can have the consequence of reducing security of a resource. It is possible to give access to the inattentive application. That is why all web-services which should be accessible to other domains are frequently taken in a separate domain. For example, our application can work within "site1.com" domain, and web-services within "api.site1.com" domain. Thus we can save us from the attack that uses cookie of the user.

In this article we have considered dangers that exist at work with Silverlight services. The cross-domain access in Silverlight is forbidden by default. To switch it on, it is necessary to place a clientaccesspolicy.xml file in a domain root. However, it is necessary to do it cautiously. In these cases it is better to store all resources for cross-domain access in another domain.