It’s pretty easy to base authentication off of a database table that maps tokens to users. That’s what I’ve done in the past. It gets away from cookies / basic auth but it does require the user to reauthenticate every time they use the app (unless you use a Local Shared Object).

-James

After spending more time thinking about it, I think I understand now. The malicious app is making a request to the original resource on firststepsinflex.com . Browser sends a cookie there, because that is where the cookie originated.

So, I am actually in agreement with Ricardo that crossdomain policy is a weak link in this approach. Can you talk a bit (perhaps in a next blog) about alternatives to securing BlazeDS app via web-service tokens, rather than cookie/basic auth?

Great article and discussion, but I feel like I am still missing something.

Your entire attack vector is based on “you are already authenticated” fact, but shouldn’t cookies follow the server origin policy? That is, the session cookie should only be sent to original server it came from, no? The cross domain policy helps with access to other resources to be pulled in, but the outgoing request to those other domains shouldn’t really contain the source cookie from firststepsinflex.com domain, as I understand the HTTP specs…

Can you shed some light on this?

Crossdomain.xml is really just a way for a server admin to opt-in to telling the browser to allow cross- domain requests to their server. It doesn’t create any new security. It selectively reduces the existing security provided by the browser. Proxies on the other-hand don’t change anything about the client-side security and should be a much preferred choice over crossdomain.xml files.

-James

Thanks for your reply!

So correct me if I’m wrong, but shouldn’t this work the opposite way and the client application have a list of allowed domains it can retrieve data from? I just fail to see the profit in having a client specific setting hanging on a server that knows “nothing” about the client.

This has been a topic of discussion between me and Flex developers for a while, as I don’t like to pollute my servers with several crossdomain.xml files across all of the back-end domains I use, serving several Flash front-ends from several other different domains (having to pre-set them all on separate locations). Of course I could just have an alias serving a allow from all site, but I feel that then it would be plain stupid and it would raise the issues you pointed out here.

Ricardo

You are right that crossdomain.xml files do not actually protect data on a server. They only provide a way for the browser to bypass the same-origin policy. There were some attacks that utilized fake crossdomain policy files. For instance if a site allowed anyone to upload files to it then an attacker could easily inject custom policy that would open the site to attacks. This type of attack was blocked with the introduction of master policies. Read more about those in the articles I link to above.

-James

I could have limited the crossdomain requests on firststepsinflex.com to only be allowed to come from http://www.jamesward.com which would have made things more secure. But in that case I’m putting 100% trust in http://www.jamesward.com to not host any malicious applications. Since http://www.jamesward.com runs Wordpress and a numer of other applications which could potentially allow an attacker to put a malicious application on http://www.jamesward.com it’s usually easier to just follow my two rules than to place that amount of trust in another site.

-James

From a non Flex developer point of view, crossdomain.xml only relation to the server is that it “lays there”. To my knowledge, it isn’t configured together with any of the services provided there, so to the server it is just a normal file it serves via HTTP like any other, if it is a server policy file, the server knows nothing about that.

I mean, it would all make sense if for instance you would show me some web server configuration that would load that file and respect the policies set there. If those are security validations made on the client side then for me there is no security at all.

I would appreciate if someone can clear this out for me, as this always felt really wrong for me and I expect that there is something that I’m passing out on.