[Security] Why you need to lock down your Silverlight clientaccesspolicy.xml

March 1, 2010 - 19:37 UTC   -   Tags: silverlight crossdomain xsrf csrf To allow a Silverlight application to fetch data across domains, Silverlight employs a security policy in called clientaccesspolicy.xml. The policy allows a server admin to specify whether or not a Silverlight application running on a given domain is allowed to connect to the server to read data on behalf of the user. Unfortunately some people specify an unrestricted clientaccesspolicy.xml, which allows any server to make requests on behalf of the user, and thus allows a malicious Silverlight application to steal user data or perform actions on behalf of the user.

If you think this blog entry is similar to my prevous blog entry on crossdomain.xml, it's the exact same problem - only for Silverlight. Note that this is not a problem with the Silverlight security model - it's bad configuration.

Unrestricted clientaccesspolicy.xml

An unrestricted clientaccespolicy.xml typically looks something like this:<?xml version="1.0" encoding="utf-8"?>
<access-policy>
<cross-domain-access>
<policy>
<allow-from http-request-headers="*">
<domain uri="*"/>
<domain uri="http://*"/>
</allow-from>
<grant-to>
<resource path="/" include-subpaths="true"/>
</grant-to>
</policy>
</cross-domain-access>
</access-policy>As you can see, instead of specifying actual domains or server names, the policy is configured with wildcards "*", which allows any application to make requests on behalf of the users.

What's the risk?

A malicioius Silverlight application can perform actions on behalf of the user (Cross Site Request Forgery - XSRF) or steal user data. Token-based XSRF-protection does not work, because the malicious application can read data, and thus also see the protection tokens.
Update 2010-04-27: This can be abused in a way that allows an attacker to surf the site proxying through the users browser: Malaria proxy

Tested in real life?

I did a quick proof of concept to test this and was able to extract username, full name, phone number and payment history from the target site.

How do I lock the clientaccespolicy.xml down?

You lock it down by specifying actual domains that you trust to read data from your site, instead of just "*". Cesar de la Torre has a flow chart showing how the Silverlight plugin makes it's access decisions.