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

February 21, 2010 - 21:36 UTC   -   Tags: crossdomain xml xsrf flash crossdomain.xml csrf flex Most web browsers implement the Same Origin Policy which limits how javascript etc. can interact across domains. Without this policy an attacker could setup a site, and if tricked into visiting it, the attacker could read data from all your logged in sessions (gmail, banking etc.) and perform actions against those sites on your behalf. This policy was seen as a bit to restrictive for flash/flex/silverlight which may need to read data from other domains. Adobe introduced the cross domain policy to address this concern. Unfortunately a lot of sites are not paying attention to what this policy really means.

Crossdomain.xml

The cross domain policy specifies which domains are allowed to read data from your site from a flash/flex application. So given a site A, the crossdomain.xml will specify whether or not a flash/flex/silverlight application hosted on site B is allowed to read data from A when running in the users browser.

The crossdomain.xml file is normally present on the root of the web server.

Unrestricted crossdomain.xml

Unfortunately a lot of developers are not paying attention to what this file actually means or accidentally deploy the wrong version to production. So they set up an unrestricted crossdomain.xml policy file looking like this:<?xml version="1.0" encoding="UTF-8"?>
<cross-domain-policy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://www.adobe.com/xml/schemas/PolicyFile.xsd">
<allow-access-from domain="*" />
</cross-domain-policy>This file basically allows a flash/flex/silverlight application running on any domain to read data from the site. While this may not be a problem for a site having only public data, this is most certainly a problem for sites where users have private data. The attack goes like this.

1. The victim is a member of A and is logged in
2. The attacker posts a flash application reading data from A to his domain B, and tricks the victim into accessing B (through email, IM, twitter etc.)
3. The victim opens the url, and runs the flash application (the application might be hidden, so the victim may not even know it's running)
4. The flash application reads data from and interacts with site A. As it's running in the users browser, it takes advantage of the fact that the user is logged in
5. The stolen data is sent to the attacker

This is a Cross Site Request Forgery attack performed from the flash application. However normal XSRF-protection does not work, because as opposed to classic XSRF, the malicioius flash application can also read data from the target domain, and thus circumvent hmacs/nonces attached to forms or urls.

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.

Risk

Update 2007-04-27: This can be abused in a way that allows an attacker to surf the site proxying through the users browser: Malaria proxy

How do I lock the crossdomain.xml down?

You lock it down by specifying actual domains that you trust to read data from your site, instead of just "*". If you actually want to allow flash applications running on any site to read specific public data, then stick that data in a folder and supply a separate crossdomain.xml file in that folder.

Adobe has a good article explaining how to setup different crossdomain files for different folders.

More information

• Jeremiah Grossman's "Crossdomain.xml Invites Cross-site Mayhem"
• Adobe's Cross-domain policy file specification