Ah, I see your point. You are not wrong.

In your example, B.com’s data is more vulnerable, since any client it permits (A.com) may have XSS vulnerabilities.

However, A.com is *less* vulnerable, since it no longer has to rely on JSON importing in order to access B.com’s data. It can load the data via XmlHttpRequest and not fear that man-in-the-middle attacks or ownage of B.com would render its own site (A.com) vulnerable.

That’s the point I was trying to make. As a whole, I think it’s an improvement, since the risk is assumed by the data provider, rather than the consumer. But depending on your role, it’d be reasonable to feel differently. If you’re the data provider, you might prefer that your clients assume all the risk.

-Ethan

I understand what you are saying. However, what I am trying to say is that with or without crossdomain.xml, XMLHttpRequest objects and JavaScript remoting hacks work. Let me make it clearer. :)

Due to the Same Origin Policies JavaScript can access only the current origin. Even if you implement the crossdomain.xml file, JavaScript again will be able to access the current origin. Why? Compatibly issues. We cannot move to the new technology over the night. With or without crossdomain.xml JSON or JavaScript remoting, if you like, will still work. The only thing that will change is increased attack surface due to the trust relationship between apps. Let me explain.

Let’s say that we have app on A.com and another one on B.com. B.com says that A.com can access its data. Effectively, this means that If I can get XSS on A.com, I will be able to read the data on that domain including the data on B.com due to the trust relationship. Today this is not possible. I need two XSS vulns rather the one.

Again, correct me if I am wrong :)

There are different attacks being addressed. Same-domain restrictions on data loading (e.g. XmlHttpRequest) are intended to protect the server hosting the *data*. Imagine, for example, servers behind a firewall. They should not be automatically query-able by external content running in a browser.

However, this restriction in the browser provided no means for servers to *permit* cross-domain data access. crossdomain.xml addresses this limitation with an explicit permission mechanism. JSON output also addresses this restriction, but opens up an opportunity for attack to server hosting the *requesting application*.

Loading a .js file from another domain opens up your web app to attack. The loaded JS is essentially imported into your app’s domain, giving it full privilege to query your app’s server — complete with session credentials!

So, further use of crossdomain.xml for real data loading via XmlHttpRequest should reduce the use of cross-domain JSON for otherwise safe data loading operations.

No mention in notes about proper syntax to point to a Adobe media &/or red5 based RTMP stream.

I would expect it to do this.

Anyone know of some docs/release notes with an example of such?

Cheers GregH