Test RIA cross domain policy (OTG-CONFIG-008) - Revision history

Hblankenship: minor edit to grammar to remove extra 'can' in url

2018-03-05T05:28:35Z

minor edit to grammar to remove extra 'can' in url

Eduardo Castellanos at 10:22, 28 April 2015

2015-04-28T10:22:30Z

Andrew Muller: Andrew Muller moved page Test RIA cross domain policy (OTG-CONFIG-011) to Test RIA cross domain policy (OTG-CONFIG-008)

2014-08-08T11:54:36Z

Andrew Muller moved page Test RIA cross domain policy (OTG-CONFIG-011) to Test RIA cross domain policy (OTG-CONFIG-008)

Andrew Muller: Reorder Tools heading

2014-08-05T14:54:18Z

Reorder Tools heading

Jane O'Connor: Added Andrew's changes.

2014-08-01T19:22:25Z

Added Andrew's changes.

Jane O'Connor: Final edit

2014-05-13T22:00:30Z

Final edit

Eduardo Castellanos at 21:03, 13 March 2014

2014-03-13T21:03:41Z

Eduardo Castellanos at 11:29, 13 March 2014

2014-03-13T11:29:04Z

Eduardo Castellanos at 11:28, 13 March 2014

2014-03-13T11:28:39Z

Eduardo Castellanos at 11:13, 13 March 2014

2014-03-13T11:13:29Z

@@ Line 41: / Line 41: @@
-=== How can cross domain policy files can be abused? ===
+=== How can cross domain policy files be abused? ===
 * Overly permissive cross-domain policies.
 * Generating server responses that may be treated as cross-domain policy files.

@@ Line 66: / Line 66: @@
 '''Result Expected:'''<br>
 *A list of policy files found. <br>
-*A weak settings in the policies.<br>
+*A list of weak settings in the policies.<br>

@@ Line 67: / Line 67: @@
 *A list of policy files found. <br>
 *A weak settings in the policies.<br>
@@ Line 80: / Line 86: @@
 * Jeremiah Grossman: "Crossdomain.xml Invites Cross-site Mayhem" http://jeremiahgrossman.blogspot.com/2008/05/crossdomainxml-invites-cross-site.html
 * Google Doctype: "Introduction to Flash security " - http://code.google.com/p/doctype-mirror/wiki/ArticleFlashSecurity

@@ Line 2: / Line 2: @@
-== Brief Summary ==
+== Summary ==
 Rich Internet Applications (RIA) have adopted Adobe's crossdomain.xml policy files 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.
 === 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. use 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.
@@ Line 53: / Line 52: @@
-== Black Box testing ==
+== How to Test ==
 '''Testing for RIA policy files weakness:''' <br>
 To test for RIA policy file weakness the tester should try to retrieve the policy files crossdomain.xml and clientaccesspolicy.xml from the application's root, and from every folder found.<br><br>
@@ Line 83: / Line 82: @@
 <br>
-'''Tools'''<br>
+==Tools==
 * Nikto
 * OWASP Zed Attack Proxy Project
 * W3af

@@ Line 3: / Line 3: @@
 == 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.
+Rich Internet Applications (RIA) have adopted Adobe's crossdomain.xml policy files 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 ===
+=== 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.
+A cross-domain policy file specifies the permissions that a web client such as Java, Adobe Flash, Adobe Reader, etc. use 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.
-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.
+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 to determine if performing cross-domain requests, including headers, and socket-based connections are allowed.
 ==== 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:
@@ Line 22: / Line 27: @@
 * HTTP/HTTPS access permissions
 * Allowing access based on cryptographic credentials
 An example of an overly permissive policy file:
@@ Line 35: / Line 41: @@
 </pre>
 === How can cross domain policy files can be abused ===
-* Overly permissive cross-domain policies
+=== How can cross domain policy files can be abused? ===
-* Generating server responses that may be treated as cross-domain policy files
+* Overly permissive cross-domain policies.
 * Using file upload functionality to upload files that may be treated as cross-domain policy files.
 === Impact of abusing cross-domain access ===
-* Defeat CSRF protections
+* Defeat CSRF protections.
 * Read data restricted or otherwise protected by cross-origin policies.
-== Black Box testing and example ==
 '''Testing for RIA policy files weakness:''' <br>
-In order to test for RIA policy file weakness you should try to retrieve the policy files crossdomain.xml and clientaccesspolicy.xml from the application's root, and from every folder found.<br><br>
+To test for RIA policy file weakness the tester should try to retrieve the policy files crossdomain.xml and clientaccesspolicy.xml from the application's root, and from every folder found.<br><br>
-For example, if the application's URL is http://www.owasp.org, you should try to download the files http://www.owasp.org/crossdomain.xml and http://www.owasp.org/clientaccesspolicy.xml.
+For example, if the application's URL is http://www.owasp.org, the tester should try to download the files http://www.owasp.org/crossdomain.xml and http://www.owasp.org/clientaccesspolicy.xml.
 <br><br>
 After retrieving all the policy files, the permissions allowed should be be checked under the least privilege principle. Requests should only come from the domains, ports, or protocols that are necessary. Overly permissive policies should be avoided. Policies with "*" in them should be closely examined.  <br><br>
@@ Line 54: / Line 63: @@
   <allow-access-from domain="*" />
 </cross-domain-policy></pre>
 '''Result Expected:'''<br>
-A list of policy files found. <br>
+*A list of policy files found. <br>
-A weak settings in the policies.<br>
+*A weak settings in the policies.<br>

← Older revision	Revision as of 11:54, 8 August 2014
(No difference)

@@ Line 118: / Line 118: @@
 * Krzysztof Kotowicz: "How to upload arbitrary file contents cross-domain"- http://blog.kotowicz.net/2011/04/how-to-upload-arbitrary-file-contents.html
 * W3C: "Cross-Origin Resource Sharing" - http://www.w3.org/TR/cors/
 <br>
 '''Tools'''<br>
 * Nikto
 * OWASP Zed Attack Proxy Project
 * W3af

@@ Line 65: / Line 65: @@
 '''Testing for CORS policy weakness:''' <br>
-Issue an OPTIONS request to the server with the following headers set:<br>
+User your favorite interception proxy to issue an OPTIONS request to the server with the following headers set):<br>
 * Origin: Origin can be any URL other than the website you are testing on or null.
 * Access-Control-Request-Method: This can be GET, POST, PUT, DELETE, etc. You should try with different values.