February 21, 2010 - 21:36 UTC - Tags: crossdomain xml xsrf flash crossdomain.xml csrf flex
Most web browsers implement the Same Origin Policy
to address this concern. Unfortunately a lot of sites are not paying attention to what this policy really means.
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.
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="*" />
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.
- The victim is a member of A and is logged in
- 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.)
- 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)
- 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
- 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.
: 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