comments (not for humans)
Unrestricted crossdomain.xml and clientaccesspolicy.xml files can be abused by malicious RIAs - or MalaRIAs - to perform actions on behalf of the user. For this PoC (proof of concept) I setup a malicious RIA to act as a proxy by comibining it with a server side application. This would allow the attacker to use the combined solution as a proxy and surf web sites with unrestricted cross domain policies through the victim's browser.

Update 2010-04-07: Source code now available:


Unrestricted crossdomain.xml and clientaccesspolicy.xml files can be abused by an attacker. The attacker can setup a rouge RIA app - a malaRIA - on a site, and if he can trick the user to visit the site, the malicious RIA can perform actions on behalf of the user (CSRF). Because the RIA runs in the user's browser, the requests will reuse the user's authentication cookies. Because the RIA is able to both read and request data, normal CSRF protection does not work (nonces/tokens can be read).

Such a RIA can at the same time transfer data back and forth to the server from which it came through a socket. This can allow the attacker to send commands to the RIA, which will then perform these actions.

The MalaRIA proxy

The MalaRIA proxy consists of a silverlight or flex RIA application running in the browser and a java backend. The attack works like this:

  1. The victim logs in on site A
  2. The victim accesses evil site B and loads the RIA app
  3. The RIA app connects back to the java backend
  4. The attacker sets his browser to use the java app as a proxy in his browser
  5. A request to the proxy, is sent to the RIA app, which on behalf of the victim, gets the resource, and passes it back to the attacker
So the java application listens on port 8080 and acts as a proxy. It will pass any request to the MalaRIA app in the victim's browser. The MalaRIA app fetches the resource and passes it back to the attacker through the proxy. So the attacker can browse the site through the users browser.

Here is a video showing the components in action:

Attacking the intranet

Because the attack goes through the user's browser, the attacker may be able to gain access to an intranet server if that server has an unrestricted crossdomain.xml or clientaccesspolicy.xml. To detect an internal server the attacker can use referer headers, javascript port scanners, CSS history hacks etc. Jeremiah Grossman talked about attacking the intranet using javascript malware at Blackhat'06.

Update 2010-04-12: Adam tipped me about the post "Penetrating Intranets through Adobe Flex Applications" on how to exploit insecure proxy-config.xml through BlazeDS to attack the intranet. The authors have built a tool called Blazentoo to exploit such configs.


The current PoC does not support images and documents due to encoding issues. It should be possible to fix this, and thus this could potentially be used to also steal documentation.
Update 2010-04-14: Images and documents now supported.


Restrict access in your crossdomain.xml and clientaccesspolicy.xml files.

More information

The diagrams in this post were created with the great online diagram editor at
Soviet Punk
"Because the RIA runs in the user's browser, the requests will reuse the user's authentication cookies" How is that possible?


It happens automatically. All requests made from the browser to a given server, will include the cookies for that server (unless the secure flag is set for the cookie and the connection is not https anymore). A request from the RIA is treated like any other request (request for a script from a script tag, image from an image tag etc.) and thus includes the cookie.
Does this also work with chrome? Can the multi process architecture prevent something like this?
Your video is amazing !
Stephan Sokolow
@fusion: As I understand it, Chrome's sandbox would have no effect on this because the vulerability is more or less internal to Flash. (The only measures Chrome could take would break sites using Flash for anything more than a newgrounds-style self-contained animation)

This, among other reasons, is why smart people use things like NoScript and FlashBlock to supplement their own judgement... though they'd still be useless with an attacker smart enough to trick them into allowing the malicious RIA.
@fusion: I can confirm what Stephan wrote above. It works equally well with Chrome. The problem is the websites' policies.
quite good...and im interested on it...i know java a little...your project is briliant....but you must first set the browser of the victim. in short you must have access to his pc...
ahmm im wrong sorry.. dont read first... i think i make a little codes for the image... =)
Did I miss something or is all this is saying that if you allow connections to your webserver from arbitrary locations (via the crossdomain.xml) then you are (obviously) allowing people to do csrf attacks using flash?
@29a: That's exactly what I'm saying. People (Jeremiah Grossman, Chris Shiflett etc.) have been writing about this problem since back in 2006, and after 4 years people still deploy unrestricted policy files on their server. So I decided to show how easy it was to exploit this, and that an attacker could even use your browser as a proxy and surf the site live as you (not just automated CSRF). What's interesting about this, is that normal CSRF-prevention like nonces/tokens, doesn't work, because flash can both read responses (it can read the page including the nonce, and submit the CSRF with the correct nonce).

Awesome work!
The approach is so fresh. I am currently developing something similar but you beat me to it :)
Since the source code is out am going to read through and see if I can steal a few ideas, hope you dont mind ;)
No, by all means. That's why it's open source. Let me know if you have any questions. Eager to see what you're up to :)


Hello, does this vulnerability also affect the Moonlight plugin from the folks at Mono-devel?


Re: Moonlight?

I haven't tested it with the Moonlight plugin, but I think it does, because this is not a flaw in silverlight (or flex). The problem is the unrestricted policy set on the website.
Thats very nice of you :)
I will share my pre-release version with you very shortly, still coding. Think our tools might complement each other. thanks!

@Adam: Thanks for the link. Good post! Sort of the reverse approach of mine.
Could someone post built code on something like rapidshare please? I can't get it to build.
Can I have access to victim browser if I have MalaRIA proxy (files: malariaflexproxy.html and malariaproxy.swf) on my own site and send link from it to a victim?

I do this. I create my site and victim browser go to But all what I see in victim browser is:

Connecting back to malaria server...
Connected and ready
Got data from proxy
Trying: [GET text/html, ]

And nothing else. No data was received. What's wrong?
You are doing it right, however MalaRIA proxy was built to highlight the problem with open crossdomain.xml and clientaccesspolicy.xml files, meaning it only works if the target site (not the site hosting the flash/silverlight app) has an unrestricted such policy:
In your case, does NOT have such a policy (which is good, or else anyone could read your email by deploying MalaRIA or another flash/flex/silverlight application on their site). The same origin policy is meant to block this kind of traffic, however the flash/flex/silverlight relaxes this policy using the crossdomain.xml/clientaccesspolicy.xml files.
Does it mean, theoretically I can get access to victim browser if he going by link on my malware-site? But MalaRIA doesn't allow this.
@Andrew: No. You should read up on the Same Origin Policy. It stops this from happening, except in some very specific cases:
If a victim accesses malware server A, code from A can only access other data from A, unless
a) a site B has an open cross domain policy (in which case MalaRIA) can be used,
b) site B has an XSS flaw, which can be used to inject something like BeEF
c) malware server A contains an exploit which turns the user's computer into a zombie.
Comments closed for this post