My trip down hackers lane continues. Read part 1 here where I discovered the Csla WcfPortal is used. Before starting my “attack” I do some recon.

Silverlight has a build-in security step that requests the clientaccesspolicy.xml file before allowing a connection to a network resource. When that request fails the crossdomain.xml file is requested. Both files exist on the host of the Silverlight Portal. I could host a XAP on a bogey server and no bells would go off accessing the WcfPortal.

Clientaccesspolicy.xml

The content of the clientaccesspolicy file below allows access to all network resources (like services) on the host. By editing the highlighted line to contain something like uri=”http://my.domain.com/” only a XAP file hosted on my.domain.com port 80 has access to the network sources.
💡 TIP: use the domain of the source parameter from the object tag in the html page that embeds the XAP.

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

Also the access to all resources is granted in the grant-to section on line 9. Maybe some restriction could be applied there as well. Like the Services directory where the WcfPortal lives.

Crossdomain.xml

Silverlight uses the Adobe file crossdomain as fallback when the clientaccesspolicy is not available. Only when the file grants unresticted access, like the code below, Silverlight uses the file.

<?xml version="1.0" encoding="utf-8" ?> 
<cross-domain-policy>
  <allow-access-from domain="*" /> 
  <allow-http-request-headers-from domain="*" headers="*" /> 
</cross-domain-policy>

No changes should be made, except maybe remove the file.

Are these files a security risk? They might be. Think about restricting access as another hurdle a hacker must take and how much it would be in your way.