Flash cross-origin policy file crossdomain. xml configuration details

Flash cross-origin policy file crossdomain. xml configuration details

0x00Directory

 

0x01 Introduction

0x02 crossdomain. xml configuration

0x03 Summary

 

0x01Introduction

 

The only restriction policy for cross-origin flash is the crossdomain. xml file, which limits whether flash can read and write data across domains and where data can be read and written across domains.

 

When the SWF file in the www.a.com domain needs to access the file www. B .com, SwF first checks whether there is crossdomain in the directory of the www. B .com server. XML file. If not, the access fails. If crossdomain. if the XML file exists and the www.a.com domain is configured to allow access, the communication is normal. The key to enabling flash to transmit data across domains is crossdomain. xml.

 

This article focuses on the configuration of crossdomain. xml files and the impact of different configurations on flash cross-domain.

 

0x02 crossdomain. xmlConfiguration

 

2.1 crossdomain. xmlLocation

If cross-origin access is required after flash 10, you must place the crossdomain. xml file in the root directory of the target domain. The configuration file under this root directory is calledMaster policy file". If the Master policy file does not exist, the domain will prohibit any flash cross-origin requests from third domains.

The Master policy file controls cross-site access.

You can also separately place a crossdomain that takes effect only for the path and its sub-path. xml configuration file, which needs to be loaded using the following statement in the flash as Script: [the specific loading permission restriction will be affected by the following site-control policy]

 

Security. loadpolicyfile ("http://www.xxx.com/subdir/crossdomain.xml ")

 

2.2 crossdomain. xmlConfiguration method and impact

Crossdomain. xml must strictly abide by the XML syntax,There is only one root nodeCross-Domain-PolicyAnd does not contain any attributes.The root node can only contain the following subnodes: site-control, allow-access-from, allow-access-from-identity, and allow-http-request-headers-from. The following describes the four subnodes:

 

2.2.1site-control:Check the attribute values of the node to check whether other policy files can be loaded. [If this policy file is not a master policy file, this node is automatically ignored]

 

Each site-control tag has only attributes.Permitted-Cross-Domain-policiesThis attribute specifies the loading policy for other policy files that are not the master policy file. The permitted-Cross-Domain-policies attribute values are as follows:

None:You cannot use the loadpolicyfile method to load any policy file, including this primary policy file.

Master-only:Only the Master policy file [default value] can be used.

By-Content-Type:Only the loadpolicyfile method can be used to load files whose content-type is text/X-Cross-Domain-policy under HTTP/HTTPS as cross-domain policy files.

By-ftp-filename:Only the file named crossdomain. xml under the FTP protocol can be loaded using the loadpolicyfile method as the Cross-Domain Policy file.

ALL:You can use the loadpolicyfile method to load any file in the target domain as a cross-domain policy file, or even a JPG file can be loaded as a policy file! [If you use this option, you can wait for it to be XX.]

 

If you need to apply a separate flash Cross-Domain Restriction policy to a subdirectory of the website, you must set site-control in the master policy file.

 

The following example configures the site-control policy to load other text/X-Cross-Domain-policy files on the server as cross-domain policy files.

 

<Cross-domain-Policy>

<Site-control permitted-Cross-Domain-policies = "by-Content-Type"/>

</Cross-Domain-Policy>

 

2.2.2 allow-access-from:Check the attribute values of the node to check the source domain of the Flash file that can read the content of the current domain.

The allow-access-from tag has three attributes:

· Domain:This attribute specifies an exact IP address, an exact domain, or a wildcard domain (any domain ). Only the specified domain in the domain has the permission to read the content in the domain through flash.

 

You can use either of the following methods to represent a wildcard domain:

1) A single asterisk (*), such as <allow-access-fromdomain = "*"/>, indicates that all domains and IP addresses are matched, in this case, the content in this domain can be accessed across domains. [This is extremely insecure!]

2) The suffix asterisk (*) indicates that only the domains ending with the specified suffix are matched. For example, * .qq.com can match game.qq.com and QQ.com. The configuration, such as www. Q *. com or www. QQ. *, is invalid.

 

Tips:When the domain is specified as an IP address, only requests from the source that uses this IP address as the URL are accepted.EquivalentOnly one domain name]. If the domain is set to 192.168.1.100, it is allowed to use http: // 192.168.1.100/flash.swf to request the domain content, however, when you use the domain name www.a.com pointing to 192.168.1.100 for access, [http://www.a.com/flash.swf] will be rejected because Flash cannot understand dns.pdf :)

 

· To-Ports:This attribute value indicates the range of socket connection ports that allow access to the content of the local domain. You can use to-ports = "1125-" to limit the port range, or use wildcard characters (*) to allow all ports.

· Secure:This attribute value indicates whether the information is encrypted. When the crossdomain. xml file is loaded using https, the default value of secure is true. In this case, flash cannot transmit non-HTTPS encrypted content. If it is set to false manually, Flash is allowed to transmit non-HTTPS encrypted content.

 

The example below is configured to allow all the second-level domain names under QQ.com [including QQ.com itself] to access the content in this domain through HTTPS.

 

<Cross-domain-Policy>

<Allow-access-from domain = "* .qq.com" secure = "true"/>

</Cross-Domain-Policy>

 

2.2.3allow-access-from-Identity:This node configures a cross-origin access policy to allow the source with a specific certificate to access resources in this domain across domains. Each allow-access-from-identity node can contain up to oneSignatorySubnode. Shape:

 

<Allow-access-from-identity>

<Signatory>

<Certificate

Fingerprint = "01: 23: 45: 67: 89: AB: CD: EF: 01: 23: 45: 67: 89: AB: CD: EF: 01: 23: 45: 67"

Fingerprint-algorithm = "SHA-1"/>

</Signatory>

</Allow-access-from-identity>

 

2.2.4allow-http-request-headers-from:This node authorizes the third-party domain flash to send User-Defined HTTP headers to this domain.

The allow-access-from node authorizes the third domain to extract data from this domain, while the allow-http-request-headers-from node authorizes the third domain to send data to this domain as an HTTP header.[In short, allow-access-fromIs to control the read permission, allow-http-request-headers-fromIs to control with HTTPWrite Permission In the Header Format]

Allow-http-request-headers-from contains three attributes:

· Domain:The function and parameter format are similar to the domain in the allow-access-from node.

· Headers:A list separated by commas (,) indicates the HTTP header that can be sent. Wildcard characters (*) are available to indicate all HTTP headers.

· Secure:The role and usage are the same as that of secure in the allow-access-from node.

 

In the following example, any domain can send the soapaction header to the current domain:

 

<Cross-domain-Policy>

<Allow-http-request-headers-from domain = "*" headers = "soapaction"/>

</Cross-Domain-Policy>

 

0x03Summary

 

Incorrect crossdomain. xml policies may cause serious security problems, such as information leakage and csrf. From the above, we can see that we should pay attention to the following points during the security evaluation:

 

1) domain attribute detection of the allow-access-from label: The domain attribute should be set as needed according to the minimum principle, and only trusted source cross-origin requests are allowed for the content of the domain.Do not set this attribute value to"*".

2) domain attribute detection of the allow-http-request-headers-from label: The domain attribute should be set as needed based on the minimum principle, and only trusted sources are allowed to send content to the domain across domains.Do not set this attribute value to"*".

3) permitted-Cross-Domain-policies attribute detection of the site-control label: This attribute is set based on actual business needs and feasibility.Do not set this attribute value to"All".