comments (not for humans)
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

genoceres
That's fine as a point, but all user b has to do is build a proxy script on his own site (to which his flash is allowed to talk) that forwards the requests to site A.

The crossdomain policy file does not protect against this very simple way around the problem.
Erlend
Yes, but I think you are missing the point. If the browser reads data directly from site A, the browser will automatically inlcude the user's cookies for A. If the user is logged in to site A, this means the malicious flash/flex application will be able to read data from site A using the users logged in session.
However if the request is proxied through site B, then the browser will send the users cookies for site B to the proxy - not the cookies for site A. The Same Origin Policy takes care of this. So the malicious flash/flex app can no longer use the session cookies of the user, thus the request to A will be blocked if it requires authentication at site A.
Comments closed for this post