Tell you what crossdomain. XML is.

Document directory

• Table of contents
• How websites need to respond

Tell you what crossdomain. XMLHTTP: // www.crossdomainxml.org/
I don't talk much about other things. The above URL is very full.
I would like to add a few words to the question "Why is it not working.
First, crossdomain. XML is placed in the server-side file. What is put on the server-side is placed under the domain name of the machine where the file you want to obtain is located. For example, if my website is xxx.me.com and my website has a SwF to obtain files on xxx.you.com, crossdomain. xml must be placed on xxx.you.com. The content in crossdomain. XML is

<?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>


See.

//////////////////////////////////////// //////////////////////////////////////// /////////////////////////////////
Deneb meketa

Adobe

Table of contents

1. Introduction
2. Changes in behavior due to immediate strictness
3. Meta-policies
4. Socket policy files
5. Workflows
6. Appendix A: browser Dependencies
7. Appendix B: Log message reference

• Printable version
• Send feedback
• Get an e-mail update of new articles
• 
  

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 release L 2008 Security Update (9, 0, 10.0), and Flash Player (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, 1.5 has implemented fully strict behavior for sockets (phase 10.0); Flash Player has implemented Phase 2 of the new restrictions; and the Phase 2 default URL meta-policy has been changed from the maximally restrictivenoneTo the less restrictivemaster-only, Permitting URL Master policy files (those/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 cocould 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 chapterProgramming ActiveX 3.0On 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 Limit l 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-essential a new set of security best practices concerning policy files.

For most sites, we don't recommend CT 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, 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:

1. 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.
2. Immediately:Read the section on socket policy files, then follow the workflow steps for logging 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.
3. As time permits:Read the section on meta-policies, then follow the workflow steps for choosing and locking ing 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 cocould 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 cocould 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 cocould Add a policy file to the site against an administrator's wishes, or even accidentally create a policy file they did not intend. this issue is essential one of controlling what policy files are permitted to exist on a server. server administrators shoshould be able both to set a server-wide policy on policy files (we call thisMeta-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 knownDNS rebindingCan target Flash Player, as well as browsers, virtual machines, and other User-Agent programs. a dns rebinding attack exploits a User-Agent'sSame-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 ActionScriptSocketAndXMLSocketClasses), 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 shoshould 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 fromlocalhostSockets may now specify that only HTTPS SWFs from given domains may connect, usingsecure="true"Declaration previusly reserved for HTTPS policy files. This can help secure hybrid applications that couple online Flash content with native local applications.

Page 1 of 7

Next Page

About the authordeneb 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. he swears that he gets no pleasure out of inflicting security rules on the world, and wishes that the bad people wowould 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.