Liberal Crossdomain.xml Exploit Example – Part 1

So, I decided to whip up this PoC of a liberal crossdomain.xml policy and what you can do with it. It’s been on my mind recently and thought a tangible example would help solidify in mind some of the possibilities. First, the basics-

What is a crossdomain.xml file?

A crossdomain.xml file essentially lets a domain specify the domains from which flash applets are loaded that are allowed to access it. The domain(s) that the crossdomain.xml file specifies are the domain from which the applet is loaded, not the domain that references the flash file.

Why does this matter?

Keep in mind that when a flash applet makes a call to retrieve data from a domain, the browser includes any cookies for that domain with the call. So, if it’s a domain that you’re authenticated with, then the flash applet will have the same access to that domain as the user does when accessing the site.

A working example

There are 2 domains for this example- and These are both domains that I own and have used for this demo.

Try going to You will get a message that looks like this-

You are not logged in. Please login

because you are not logged in. That page requires you to be authenticated to view it. (In this cause “authenticated” means a cookie is set with your username:password in it)

Then go to and input anything as the user name and anything as the password. In my example, I used “chs” for both. You will be redirected to with a message that looks like-

Thanks for logging in! Your credentials are: chs:chs. Do not share them with others.  You must be authenticated to view this page.

Since you are authenticated, it lets you get to that page and shows you your username:password in this example. In a real world site it could be a page that shows you bank balances, sensitive data, etc.

Now, in another browser tab open It appears that nothing happens. But, in the background it connected to, got the response, and logged it.

You can see the results at

Currently it looks like-

Thanks for logging in! Your credentials are: chs:chs. Do not share them with others. You must be authenticated to view this page.

So, the flash applet that I wrote on connected to and pulled the content utilizing your existing session with

Why did that happen?

The reason this happened was because had a liberal crossdomain.xml policy. In this example, it lets any flash applet connect. It looks like-

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "">
<allow-access-from domain="*"/>

When a flash applet tries to connect to a domain, the flash container attempts to retrieve crossdomain.xml and applies the policy it contains. Since the above one allows access from any domain, the flash applet from was allowed to connect, access the page, and log the results.

Part 2

This entry was posted in Security. Bookmark the permalink.
  • Thomas

    Is there any way to view what’s the code of your flash applet ?


  • I did a survey of the top 1 million sites to see just how many were vulnerable to this sort of attack and published the results:

  • Why was your injectionvector website taken down?

    • chs

      Thanks for the heads-up. The domain expired and it’s in the redemption phase right now, so it’s gone. I’ll spin up another domain and move the content there.