告诉你到底什么是crossdomain.xml-CSDN博客

http://www.crossdomainxml.org/
别的废话不多说了，上面的网址很全。
为还存在疑惑“怎么不起作用呀”的网友补充几句话。
首先，crossdomain.xml是放在服务器端的文件，什么叫做放在服务器端，就是放在你要获取的文件的所在的那台机器的那个域名下面。比如我自己的网站是xxx.me.com，我的网站上有一个swf要获取xxx.you.com上的文件，那么crossdomain.xml要放在xxx.you.com上才可以。crossdomain.xml里面的内容就是

<?xml version="1.0"?> <!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd"> <cross-domain-policy> <allow-access-from domain="*.me.com" /> </cross-domain-policy>

明白了吧。

Deneb Meketa

Adobe

Created:

3 December 2007

Modified:

24 October 2008

User Level:

Intermediate

Products:

Flash Player

Policy file changes in Flash Player 9 and Flash Player 10

This article refers to Flash Player 9 Update 3 (9,0,115,0), Flash Player 9 April 2008 Security Update (9,0,124,0), and Flash Player 10.0 (10,0,2,xx and later).

Note: This article was updated in October 2008. There are only three substantial changes to be aware of: Flash Player 9,0,124,0 has implemented fully strict behavior for sockets (Phase 1.5); Flash Player 10.0 has implemented Phase 2 of the new restrictions; and the Phase 2 default URL meta-policy has been changed from the maximally restrictive none to the less restrictive master-only, permitting URL master policy files (those at /crossdomain.xml) to continue working without the introduction of a meta-policy.

In 2003, Flash Player 7 software introduced a channel of client-server communication that was new to the web: direct cross-domain data loading, authorized by policy files. Before policy files, web content could only perform two-way communication with its own server, such as runtime configuration or transactions without page reloads. Policy files allowed servers to open up their data selectively to client content from other domains, or generally to content from anywhere. Since the introduction of policy files, domain boundaries have been less of a barrier for authors of rich Internet applications.

Like most new technologies, policy files weren't perfect when they were first introduced. After four years, the Internet security community has found two undesirable situations (described later in this article) that can arise from the existence of policy files. The basic premise of policy files remains valid, and Flash developers can continue to rely on policy files just as they have since Flash 6. To address the new concerns, however, Adobe is specifying some stricter rules for the use of policy files. Additionally, there are a number of improvements that make policy files more useful and usable. We will try to explain the reasons for our changes clearly and simply.

This article assumes some familiarity with policy files. For a detailed introduction to policy files, see the Flash Player Security chapter of Programming ActionScript 3.0 on Adobe LiveDocs; Cross-domain policy file usage recommendations for Flash Player; and the Cross-domain policy file specification. For information about HTTP header-sending permissions in policy files, which is not covered in this article, see the relevant section in Understanding Flash Player 9 April 2008 Security Update compatibility.

How websites need to respond

To conform to the stricter rules, websites that serve policy files will need to make some minor changes. These changes are mainly for the protection of those sites themselves—essentially a new set of security best practices concerning policy files.

For most sites, we don't expect the changes to be difficult—but because of the large number of sites impacted, Adobe implemented the stricter requirements in Flash Player in three phases. In Phase 1, which began with Flash Player 9,0,115,0, a small number of strict rules were enforced immediately, but most violations of the strict rules resulted only in warnings visible in Debug versions of Flash Player. In Phase 1.5, which began with Flash Player 9,0,124,0, the warnings of Phase 1 became errors in the specific case of socket operations. In Phase 2, which began with Flash Player 10.0, all of the warnings of Phase 1 became errors and the transition to stricter rules was complete.

We recommend that website administrators follow these steps:

Immediately: Read the section on immediate strictness, then follow the workflow steps for diagnosing and fixing immediate issues. This step only applies to sites that serve Flash Player compatible content (SWF files). This step accounts for the effects of Phase 1.
Immediately: Read the section on socket policy files, then follow the workflow steps for configuring socket policy files. This step applies primarily to sites that already provide policy files, but can also provide useful defensive measures to sites with no policy files or SWF files. This step accounts for the effects of Phase 1.5.
As time permits: Read the section on meta-policies, then follow the workflow steps for choosing and configuring a meta-policy. This step applies primarily to sites that already provide policy files, but can also provide useful defensive measures to sites with no policy files or SWF files. This step accounts for the effects of Phase 2.

Issues addressed

Two issues are addressed by the stricter policy file rules:

Policy file control. There is a possibility that a file on a server that does not appear to be a policy file may in fact be used as a policy file. For example, if a server permits uploads by users, but does not intend to open data for cross-domain access, it is possible that a user could deliberately construct a policy file but disguise it as a different type of file, such as an ordinary text, XML, or HTML file, or even as a binary type, such as a PNG or JPEG image file. A user who successfully uploaded this disguised policy file could then write a SWF file that takes advantage of the disguised policy file to load data from outside the server's domain. Similarly, a site maintainer with limited privileges could add a policy file to the site against an administrator's wishes, or even accidentally create a policy file they did not intend to. This issue is essentially one of controlling what policy files are permitted to exist on a server. Server administrators should be able both to set a server-wide policy on policy files (we call this a meta-policy), and to easily search for all policy files on their server, allowing auditing of all cross-domain permissions present on the server. The stricter policy file rules in Flash Player allow meta-policy declarations by server administrators, and perform greater sanity checking on policy files to help ensure that they are properly formatted.

DNS hardening. A class of cross-site scripting attacks known as DNS rebinding can target Flash Player, as well as browsers, virtual machines, and other user-agent programs. A DNS rebinding attack exploits a user-agent's same-origin policy, in which content from a given Internet domain is permitted to load and communicate with other resources in its own domain without explicit permission. An attacker who controls their own domain, and runs their own DNS server, can dynamically reconfigure their DNS server so that a given domain name resolves first to an IP address under the attacker's control (which may be used to serve a malicious SWF file or other content), then later to a different IP address that the attacker does not control. If the user-agent program does not detect the change in IP addresses, its same-origin policy will permit the attacker's content to access the second IP address without permission from the second host. Flash Player relies on browsers to provide HTTP networking, so any rebinding vulnerabilities that involve only HTTP must be solved in browsers. However, Flash Player also provides socket-level networking (via the ActionScript Socket and XMLSocket classes), and the strict policy file rules in Flash Player 9,0,115,0 help mitigate DNS rebinding vulnerabilities as they pertain to sockets. Specifically, the strict rules always require permission from a socket policy file in order to make a socket connection, even when the socket server appears to be the same as a connecting SWF file's domain of origin. In addition, beginning with version 9,0,115,0, Flash Player matches socket connections to their corresponding socket policy files based on IP addresses, not just domain names.

Other improvements

While addressing the above issues, we have also added some new features to make policy files more useful and usable:

Verbose logging of policy file events from Debug versions of Flash Player. All failures and successes in loading and processing policy files are reported, as well as failures and successes of operations that depend on those policy files. This should help not only with the transition to the stricter rules, but also generally in finding and solving problems with any policy file deployment.
A fixed socket master policy file port, TCP port 843, that is consulted by default for socket policy files. This provides a standard way to serve socket policy files, rather than the "choose any port" system used previously.
An option to require strong client authentication for local sockets. Socket policy files served from localhost sockets may now specify that only HTTPS SWFs from given domains may connect, using the secure="true" declaration previously reserved for HTTPS policy files. This can help secure hybrid applications that couple online Flash content with native local applications.

About the author

Deneb Meketa is an engineer on the Adobe Flash Player team. He never set out to be the Security Guy, but that's kinda what he's turned into. He swears that he gets no pleasure out of inflicting security rules on the world, and wishes that the Bad People would chill out and leave us all alone. Nevertheless, he has a lot of fun working on the internals of Flash Player, which is a really cool piece of software.