Difference between revisions of "Test RIA cross domain policy (OTG-CONFIG-011)"

From OWASP
Jump to: navigation, search
(6 intermediate revisions by one user not shown)
Line 3: Line 3:
  
 
== Brief Summary ==
 
== Brief Summary ==
<br>
 
 
Rich Internet Applications (RIA) have adopted Adobe's crossdomain.xml policy files in order to allow for controlled cross domain access to data and service consumption using technologies such as Oracle Java, Silverlight, and Adobe Flash. Therefore, a domain can grant remote access to its services from a different domain. However, often the policy files that describe the access restrictions are poorly configured. Poor configuration of the policy files enables Cross-site Request Forgery attacks, and may allow third parties to access sensitive data meant for the user.  
 
Rich Internet Applications (RIA) have adopted Adobe's crossdomain.xml policy files in order to allow for controlled cross domain access to data and service consumption using technologies such as Oracle Java, Silverlight, and Adobe Flash. Therefore, a domain can grant remote access to its services from a different domain. However, often the policy files that describe the access restrictions are poorly configured. Poor configuration of the policy files enables Cross-site Request Forgery attacks, and may allow third parties to access sensitive data meant for the user.  
  
<br>
 
 
== Description of the Issue ==  
 
== Description of the Issue ==  
<br>
+
=== What are cross-domain policy files ===
...here: Short Description of the Issue: Topic and Explanation
+
A cross-domain policy file specifies the permissions that a web client such as Java, Adobe Flash, Adobe Reader, etc. to access data across different domains. For Silverlight, Microsoft adopted a subset of the Adobe's crossdomain.xml, and additionally created it's own cross-domain policy file: clientaccesspolicy.xml.
<br>
+
 
 +
Whenever a web client detects that a resource has to be requested from other domain, it will first look for a policy file in the target domain in order to determine if performing cross-domain requests, including headers, and socket-based connections are allowed.
 +
 
 +
Master policy files are located at the domain's root. A client may be instructed to load a different policy file, however, it will always check the master policy file first to ensure that the master policy file permits the requested policy file.
 +
 
 +
==== Crossdomain.xml vs. Clientaccesspolicy.xml ====
 +
Most RIA applications support crossdomain.xml. However in the case of Silverlight, it will only work if the crossdomain.xml specifies that access is allowed from any domain. For more granular control with Silverlight, clientaccesspolicy.xml must be used.
 +
 
 +
Policy files grant several types of permissions:
 +
* Accepted policy files (Master policy files can disable or restrict specific policy files)
 +
* Sockets permissions
 +
* Header permissions
 +
* HTTP/HTTPS access permissions
 +
* Allowing access based on cryptographic credentials
 +
 
 +
An example of an overly permissive policy file:
 +
<pre>
 +
<?xml version="1.0"?>
 +
<!DOCTYPE cross-domain-policy SYSTEM
 +
"http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
 +
<cross-domain-policy>
 +
  <site-control permitted-cross-domain-policies="all"/>
 +
  <allow-access-from domain="*" secure="false"/>
 +
  <allow-http-request-headers-from domain="*" headers="*" secure="false"/>
 +
</cross-domain-policy>
 +
</pre>
 +
 
 +
 
 +
 
 +
=== How can RIA policy files be abused ===
 +
* Overly permissive RIA policy files
 +
* Generating server responses that may be treated as cross-domain policy files
 +
* Using file upload functionality to upload files that may be treated as cross-domain policy files.
 +
 
 +
=== Impact of abusing crossdomain.xml policy files ===
 +
* Cross-domain access to site
 +
* Defeat CSRF protections
 +
* Read data restricted or otherwise protected by cross-origin policies.
 +
 
 
== Black Box testing and example ==
 
== Black Box testing and example ==
'''Testing for Topic X vulnerabilities:''' <br>
+
'''Testing for RIA policy files weakness:''' <br>
 
...<br>
 
...<br>
 
'''Result Expected:'''<br>
 
'''Result Expected:'''<br>
Line 18: Line 54:
 
== References ==
 
== References ==
 
'''Whitepapers'''<br>
 
'''Whitepapers'''<br>
http://www.adobe.com/devnet/articles/crossdomain_policy_file_spec.html
+
* Adobe: "Cross-domain policy file specification" - http://www.adobe.com/devnet/articles/crossdomain_policy_file_spec.html
 +
* Oracle: "Cross-Domain XML Support" - http://www.oracle.com/technetwork/java/javase/plugin2-142482.html#CROSSDOMAINXML
 +
* MSDN: "Making a Service Available Across Domain Boundaries" - http://msdn.microsoft.com/en-us/library/cc197955(v=vs.95).aspx
 +
* MSDN: "Network Security Access Restrictions in Silverlight" - http://msdn.microsoft.com/en-us/library/cc645032(v=vs.95).aspx
 +
* Stefan Esser: "Poking new holes with Flash Crossdomain Policy Files" http://www.hardened-php.net/library/poking_new_holes_with_flash_crossdomain_policy_files.html
 +
* Jeremiah Grossman: "Crossdomain.xml Invites Cross-site Mayhem" http://jeremiahgrossman.blogspot.com/2008/05/crossdomainxml-invites-cross-site.html
 +
* http://code.google.com/p/doctype-mirror/wiki/ArticleFlashSecurity
 
<br>
 
<br>
 
'''Tools'''<br>
 
'''Tools'''<br>
...<br>
+
* Nikto

Revision as of 17:49, 19 February 2013

This article is part of the new OWASP Testing Guide v4. 
At the moment the project is in the REVIEW phase.

Back to the OWASP Testing Guide v4 ToC: https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents Back to the OWASP Testing Guide Project: http://www.owasp.org/index.php/OWASP_Testing_Project

Contents


Brief Summary

Rich Internet Applications (RIA) have adopted Adobe's crossdomain.xml policy files in order to allow for controlled cross domain access to data and service consumption using technologies such as Oracle Java, Silverlight, and Adobe Flash. Therefore, a domain can grant remote access to its services from a different domain. However, often the policy files that describe the access restrictions are poorly configured. Poor configuration of the policy files enables Cross-site Request Forgery attacks, and may allow third parties to access sensitive data meant for the user.

Description of the Issue

What are cross-domain policy files

A cross-domain policy file specifies the permissions that a web client such as Java, Adobe Flash, Adobe Reader, etc. to access data across different domains. For Silverlight, Microsoft adopted a subset of the Adobe's crossdomain.xml, and additionally created it's own cross-domain policy file: clientaccesspolicy.xml.

Whenever a web client detects that a resource has to be requested from other domain, it will first look for a policy file in the target domain in order to determine if performing cross-domain requests, including headers, and socket-based connections are allowed.

Master policy files are located at the domain's root. A client may be instructed to load a different policy file, however, it will always check the master policy file first to ensure that the master policy file permits the requested policy file.

Crossdomain.xml vs. Clientaccesspolicy.xml

Most RIA applications support crossdomain.xml. However in the case of Silverlight, it will only work if the crossdomain.xml specifies that access is allowed from any domain. For more granular control with Silverlight, clientaccesspolicy.xml must be used.

Policy files grant several types of permissions:

  • Accepted policy files (Master policy files can disable or restrict specific policy files)
  • Sockets permissions
  • Header permissions
  • HTTP/HTTPS access permissions
  • Allowing access based on cryptographic credentials

An example of an overly permissive policy file:

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM
"http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
   <site-control permitted-cross-domain-policies="all"/>
   <allow-access-from domain="*" secure="false"/>
   <allow-http-request-headers-from domain="*" headers="*" secure="false"/>
</cross-domain-policy>


How can RIA policy files be abused

  • Overly permissive RIA policy files
  • Generating server responses that may be treated as cross-domain policy files
  • Using file upload functionality to upload files that may be treated as cross-domain policy files.

Impact of abusing crossdomain.xml policy files

  • Cross-domain access to site
  • Defeat CSRF protections
  • Read data restricted or otherwise protected by cross-origin policies.

Black Box testing and example

Testing for RIA policy files weakness:
...
Result Expected:
...

References

Whitepapers


Tools

  • Nikto