This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

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

From OWASP
Jump to: navigation, search
m (minor edit to grammar to remove extra 'can' in url)
 
(6 intermediate revisions by 3 users not shown)
Line 2: Line 2:
  
  
== Brief Summary ==
+
== 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.  
  
HTML5 also incorporates a new way of performing cross domain requests: Cross Origin Resource Sharing (CORS). These can also be improperly configured and enable an attacker to perform similar attacks.
 
  
== 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. 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.
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.
+
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.
 +
 
 +
 
 +
Master policy files are located at the domain's root. A client may be instructed to load a different policy file but 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 ====
 
==== 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.
 
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:
 
Policy files grant several types of permissions:
Line 24: Line 26:
 
* HTTP/HTTPS access permissions
 
* HTTP/HTTPS access permissions
 
* Allowing access based on cryptographic credentials
 
* Allowing access based on cryptographic credentials
 +
  
 
An example of an overly permissive policy file:
 
An example of an overly permissive policy file:
Line 36: Line 39:
 
</cross-domain-policy>
 
</cross-domain-policy>
 
</pre>
 
</pre>
=== What is CORS===
 
CORS is HTML5's way of enabling web applications to perform cross-domain requests. CORS works by appending an "Origin" header to the HTTP request, then the server responds with a "Access-Control-Allow-Origin" header stating which website can issue cross domain requests. The server may answer with the Access-Control-Allow-Origin header set to * to indicate that it is a public resource.
 
  
=== How can cross domain policies can be abused ===
+
 
* Overly permissive cross-domain policies
+
=== How can cross domain policy files be abused? ===
* Generating server responses that may be treated as cross-domain policy files
+
* Overly permissive cross-domain policies.
 +
* 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.
 
* Using file upload functionality to upload files that may be treated as cross-domain policy files.
* Being able to set custom response headers to indicate cross domain access. (Access-Control-Allow-Origin: *)
+
 
  
 
=== Impact of abusing cross-domain access ===
 
=== Impact of abusing cross-domain access ===
* Defeat CSRF protections
+
* Defeat CSRF protections.
 
* Read data restricted or otherwise protected by cross-origin policies.
 
* Read data restricted or otherwise protected by cross-origin policies.
  
== Black Box testing and example ==
+
 
 +
== How to Test ==
 
'''Testing for RIA policy files weakness:''' <br>
 
'''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>
 
<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>
 
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 59: Line 62:
 
  <allow-access-from domain="*" />  
 
  <allow-access-from domain="*" />  
 
</cross-domain-policy></pre>
 
</cross-domain-policy></pre>
 +
  
 
'''Result Expected:'''<br>
 
'''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 list of weak settings in the policies.<br>
 +
 
  
'''Testing for CORS policy weakness:''' <br>
+
==Tools==
User your favorite interception proxy to issue an OPTIONS request to the server with the following headers set):<br>
+
* Nikto
* Origin: Origin can be any URL other than the website you are testing on or null.
+
* OWASP Zed Attack Proxy Project
* Access-Control-Request-Method: This can be GET, POST, PUT, DELETE, etc. You should try with different values.
+
* W3af
* Access-Control-Request-Headers: This can be almost any request header. You should try to with sensitive headers. (This is optional)
 
<br>
 
A request will then look like this:
 
 
<pre>
 
OPTIONS /resources/target HTTP/1.1
 
Host: example.com
 
Connection: keep-alive
 
Access-Control-Request-Method: POST
 
Origin: http://owasp.org
 
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.9 Safari/536.5
 
Access-Control-Request-Headers: x-extraheader, content-type
 
Accept: */*
 
Referer: http://example.com/page.html
 
Accept-Encoding: gzip,deflate,sdch
 
Accept-Language: en-US,en;q=0.8,es;q=0.6
 
</pre>
 
  
A successful response would look like this: <br>
 
<pre>
 
HTTP/1.1 200 OK
 
Date: Thu, 13 Mar 2014 10:18:45 GMT
 
Server: Apache
 
Access-Control-Allow-Origin: http://example.com
 
Access-Control-Allow-Methods: POST, GET, OPTIONS
 
Access-Control-Allow-Headers: X-EXTRAHEADER, CONTENT-TYPE
 
Access-Control-Max-Age: 1728000
 
Vary: Accept-Encoding
 
Content-Encoding: gzip
 
Content-Length: 20
 
Keep-Alive: timeout=2, max=100
 
Connection: Keep-Alive
 
Content-Type: text/plain
 
</pre>
 
  
You should carefully inspect the "Access-Control-Allow-Origin", "Access-Control-Allow-Methods", "Access-Control-Allow-Credentials", "Access-Control-Allow-Headers", "Access-Control-Allow-Expose-Headers", and any other header that starts with "Access-Control-Allow-". The value of each of this headers should be set to the most restrictive setting. For example a specific domain for "Access-Control-Allow-Origin".
 
 
== References ==
 
== References ==
 
'''Whitepapers'''<br>
 
'''Whitepapers'''<br>
Line 115: Line 86:
 
* Jeremiah Grossman: "Crossdomain.xml Invites Cross-site Mayhem" http://jeremiahgrossman.blogspot.com/2008/05/crossdomainxml-invites-cross-site.html
 
* 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
 
* Google Doctype: "Introduction to Flash security " - http://code.google.com/p/doctype-mirror/wiki/ArticleFlashSecurity
* http://www.html5rocks.com/en/tutorials/cors/
 
* 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/
 
* Secureideas: "Grab a CORS Light" - http://blog.secureideas.com/2013/02/grab-cors-light.html
 
<br>
 
'''Tools'''<br>
 
* Nikto
 
* OWASP Zed Attack Proxy Project
 
* W3af
 

Latest revision as of 05:28, 5 March 2018

This article is part of the new OWASP Testing Guide v4.
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: https://www.owasp.org/index.php/OWASP_Testing_Project


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.


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.


Master policy files are located at the domain's root. A client may be instructed to load a different policy file but 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 cross domain policy files be abused?

  • Overly permissive cross-domain policies.
  • 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 cross-domain access

  • Defeat CSRF protections.
  • Read data restricted or otherwise protected by cross-origin policies.


How to Test

Testing for RIA policy files weakness:
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.

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.

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.

Example:

<cross-domain-policy> 
 <allow-access-from domain="*" /> 
</cross-domain-policy>


Result Expected:

  • A list of policy files found.
  • A list of weak settings in the policies.


Tools

  • Nikto
  • OWASP Zed Attack Proxy Project
  • W3af


References

Whitepapers