f4a:
Flash-based cross-domain ajax requests

Javascript cannot make asynchronous http requests to domains other than the page it is on. This limitation has confounded many people for some time.

For example, Javascript running on yoursite.com cannot fetch data from mysite.com. Even if mysite.com really wants you to have the data.

In recent years, smart folks have looked for ways to cheat this rule, and invented several. At this point, there is no way to flat-out fool it.

This is a refinement of one of those methods - the flash-based one.

It uses two files: A .swf file and a .js wrapper. The total size is less than 4k.

Acknowledgments

The idea is not mine. Julien Couvreur demonstrated it first. This code was inspired by his FlashHelper.js and Flash4AJAX.swf. The main difference is that this version does not require the .swf file to be hosted on the same domain as the page which makes the asynchronous request.

Good things:

• Works in FF, Safari, and IE (6 and 7)
• Works for GET and POST requests (unlike the <script>-tag injection approach)
• Is client-side only (none of the additional latency of the proxy approach)
• Works with cookies.
• Free! Totally free, you don't even need Adobe software, thanks to the good folks behind mtasc.

Other things:

You can't just connect to any old domain - the domain has to have a crossdomain.xml file in its root. This is the main drawback of the flash-based approach

It depends on SWFObject

Flash 8 or better is required

Security things:

The limit on cross-domain requests was created for a reason. It's another way for evil folks to do their evil stuff.

f4a.swf does have a few countermeasures. With every request, it sends an additional parameter: f4a_domain. This is the domain of the current page that the f4a.swf object is in. The idea is to allow storing this domain when a session is initiated, and comparing it to the domain for successive requests that include the session cookie. This prevents exploits like this one against sites using the f4a cross-domain request method.

However, if a malicious site knows the domain of a previously-established session (possibly by accessing the browser history), the evil site could use a modified version of the f4a code to spoof the f4a_domain value. For this reason, it is a good idea to store the value of HTTP_REFERER in the session as well, and compare that with subsequent requests. For actionscript http requests, the HTTP_REFERER is the URI of the .swf file that generated the request.

Note - in IE, the HTTP_REFERER header can be overwritten by actionscript. I don't have any ideas for how to fix or work around this.

The demo has a testbench example of this security model. To exploit it would require the following:

1. A user to access the demo and send the login request to the "evilness test" page to initiate a session.
2. The user to visit some evil site.
3. The evil site send a POST request to the evilness test page's "trusted action" api target, using the user's pre-existing session.

If you are able to get such an exploit to work, please send me the URL of your evil site for verification.

f4a.as and f4a_js.js are licensed under the GPL. If you make improvements, please drop a line.

If you want to compile a changed version of the .as source, first get mtasc.

Then do:

	mtasc -swf f4a.swf -main -header 1:1:20  -cp "/Users/lloyd/mtasc-1.12-osx/std8" -v -version 8 f4a.as
	

(replace the /Users/lloyd/mtasc-1.12-osx/std8 path with the correct location for where you have mtasc installed)

Check out the demo!

Download the files: .swf, .js (see the demo for how to use them).

(Developers only) Download the .as source code. (see the "development" section for how to compile)