Specifications/Cross Domain Access Policies - Revision history

GPHemsley: GPHemsley moved page Specifications:Cross Domain Access Policies to Specifications/Cross Domain Access Policies without leaving a redirect

2015-05-12T01:26:10Z

GPHemsley moved page Specifications:Cross Domain Access Policies to Specifications/Cross Domain Access Policies without leaving a redirect

← Older revision	Revision as of 01:26, 12 May 2015
(No difference)

Doron: Cross domain and XForms/Web Forms 2.0

2005-05-25T04:32:46Z

Cross domain and XForms/Web Forms 2.0

← Older revision		Revision as of 04:32, 25 May 2005
Line 12:		Line 12:

	The goal of this document is to standardize these two approaches into a more generic model so that it can cover more use cases.		The goal of this document is to standardize these two approaches into a more generic model so that it can cover more use cases.

			It is also important to note that this does not only apply to "scripting" languages. For example, [http://www.w3.org/MarkUp/Forms/ W3C's XForms] allows sending and/or retrieving of XML without any scripting. Even just being able to send a SOAP request (which can be construted in XForms) cross-domain may be unsecure if the service does not expect being called from outside the firewall. [http://whatwg.org/specs/web-forms/current-work/ Web Forms 2.0] from the [http://whatwg.org WHATWG] allows sending of XML in a restricted fashion, which for example won't allow faking a SOAP request.

	== Controlling Cross-Domain Access on the Server ==		== Controlling Cross-Domain Access on the Server ==

Doron: subdirectory, not subdomain doofus.

2005-05-23T16:02:02Z

subdirectory, not subdomain doofus.

← Older revision		Revision as of 16:02, 23 May 2005
Line 69:		Line 69:

	=== Delegation ===		=== Delegation ===
	The optional '''delegate''' attribute (default is false) on the '''allow''' element allows the policy file to redirect the client to another policy file. In other words, if an outside (but allowed) domain is trying to access a web service on a ~~subdomain~~ on the current domain, then the client should look for a policy file in that ~~subdomain~~. If no policy file is found in the ~~subdomain~~, then access is rejected and ~~access~~ policy processing ceases.		The optional '''delegate''' attribute (default is false) on the '''allow''' element allows the policy file to redirect the client to another policy file. In other words, if an outside (but allowed) domain is trying to access a web service on a subdirectory on the current domain, then the client should look for a policy file in that subdirectory. If no policy file is found in the subdirectory, then access is rejected and policy processing ceases.

	Given this policy file at <tt><nowiki>http://www.company.com/cross-domain-policy.xml</nowiki></tt>:		Given this policy file at <tt><nowiki>http://www.company.com/cross-domain-policy.xml</nowiki></tt>:

Doron: "to" attribute

2005-05-23T16:00:25Z

"to" attribute

← Older revision		Revision as of 16:00, 23 May 2005
Line 32:		Line 32:

	=== Whitelisting ===		=== Whitelisting ===
	The policy file works like a whitelist. It lists which outside domains have access to web-services and what types of services they may consume. The '''allow''' element is used for this, and the domain is specified in ~~it's~~ '''from''' attribute. Full domains may be used, such as <tt><nowiki>www.foo.com</nowiki></tt>, or wildcarded ones such as <tt><nowiki>.foo.com</nowiki></tt>, or even just <tt><nowiki></nowiki></tt> to allow any domain. If no '''from''' attribute is set, then any domain is allowed. If the implementor is [http://www.ietf.org/html.charters/idn-charter.html IDN] aware, then the '''from''' attribute should be IDN aware as well.		The policy file works like a whitelist. It lists which outside domains have access to web services on this domain and what types of services they may consume. The '''allow''' element is used for this, and the domain is specified in its '''from''' attribute. Full domains may be used, such as <tt><nowiki>www.foo.com</nowiki></tt>, or wildcarded ones such as <tt><nowiki>.foo.com</nowiki></tt>, or even just <tt><nowiki></nowiki></tt> to allow any domain. If no '''from''' attribute is set, then any domain is allowed. If the implementor is [http://www.ietf.org/html.charters/idn-charter.html IDN] aware, then the '''from''' attribute should be IDN aware as well.

			For enhanced security, the '''allow''' element can also specify which subdirectory on the current domain this rule applies to, using the '''to''' attribute. So if '''to''' is set to <tt><nowiki>service/</nowiki></tt>, then that rule only applies for services located in that directory.

	=== Types of Services ===		=== Types of Services ===

Doron: added IDN

2005-05-23T15:53:25Z

added IDN

← Older revision		Revision as of 15:53, 23 May 2005
Line 32:		Line 32:

	=== Whitelisting ===		=== Whitelisting ===
	The policy file works like a whitelist. It lists which outside domains have access to web-services and what types of services they may consume. The '''allow''' element is used for this, and the domain is specified in it's '''from''' attribute. Full domains may be used, such as <tt><nowiki>www.foo.com</nowiki></tt>, or wildcarded ones such as <tt><nowiki>.foo.com</nowiki></tt>, or even just <tt><nowiki></nowiki></tt> to allow any domain. If no '''from''' attribute is set, then any domain is allowed.		The policy file works like a whitelist. It lists which outside domains have access to web-services and what types of services they may consume. The '''allow''' element is used for this, and the domain is specified in it's '''from''' attribute. Full domains may be used, such as <tt><nowiki>www.foo.com</nowiki></tt>, or wildcarded ones such as <tt><nowiki>.foo.com</nowiki></tt>, or even just <tt><nowiki></nowiki></tt> to allow any domain. If no '''from''' attribute is set, then any domain is allowed. If the implementor is [http://www.ietf.org/html.charters/idn-charter.html IDN] aware, then the '''from''' attribute should be IDN aware as well.

	=== Types of Services ===		=== Types of Services ===

Rgmnetid: Clean up and improve clarity (says me ;) )

2005-05-19T19:33:03Z

Clean up and improve clarity (says me ;) )

← Older revision		Revision as of 19:33, 19 May 2005
Line 2:		Line 2:

	== Introduction ==		== Introduction ==
	One of the oldest security ~~model~~ in browsers today is the cross-domain policy. Browsers restrict pages from accessing data from pages on other domains. However, modern browsers can now consume services, such as XML datasources or SOAP, and ~~such~~ public web services are being hampered by the strict cross-domain security model. This document attempts to specify a new model, by which domains can specify which ~~which~~ domains can access them.		One of the oldest security models in browsers today is the cross-domain policy. Browsers restrict pages from accessing data from pages on other domains. However, modern browsers can now consume services such as XML datasources or SOAP, and these types of public web services are being hampered by the strict cross-domain security model. This document attempts to specify a new model, by which domains can specify which other domains can access them.

	== Problem ==		== Problem ==
	Public web services can be consumed from any domain using server-side scripting. The reason browsers cannot allow the same is because they create a new problem which server-side scripts do not have, namely allowing the circumvention of firewalls, such as ~~the ones~~ used by corporate intranets.		Public web services can be consumed from any domain using server-side scripting. The reason browsers cannot allow the same behavior is because they create a new problem which server-side scripts do not have, namely, allowing the circumvention of firewalls such as those used by corporate intranets.

	A browser being used behind a firewall can connect to both the ~~internet~~ and the intranet. If browsers allowed websites to access any domain, a malicious ~~internet~~ site~~, when~~ visited by a firewall user, could ~~then~~ access web services inside the firewall~~, who~~ usually assume ~~that~~ they can ~~only~~ be accessed from behind the firewall. For example, a company may have a internally public web service into its employee database.		A browser being used behind a firewall can connect to both the Internet and the intranet. If browsers allowed websites to access any domain, then a malicious Internet site visited by a firewall user could access web services inside the firewall (where such services usually assume they can be accessed only from behind the firewall). For example, a company may have an internally public web service that queries into its employee database.

	Two ~~independant~~ groups ended up implementing a solution in a very similar way: allow the web service domain to specify who may access it, and then the client (such as a browser) makes sure the cross-domain call is permitted. Macromedia implemented this for Flash 7, and Netscape implemented this for consuming XML Web Services (SOAP/WSDL) from JavaScript in Mozilla-based products.		Two independent groups ended up implementing a solution in a very similar way: allow the web service domain to specify who may access it, and then the client (such as a browser) makes sure the cross-domain call is permitted. Macromedia implemented this for Flash 7, and Netscape implemented this for consuming XML Web Services (SOAP/WSDL) from JavaScript in Mozilla-based products.

	The goal of this document is to standardize ~~the~~ two approaches ~~and make it~~ more generic, so that it can cover more use cases.		The goal of this document is to standardize these two approaches into a more generic model so that it can cover more use cases.

	== Controlling Cross Domain Access on the Server ==		== Controlling Cross-Domain Access on the Server ==
	Both solutions used an XML file in the root ~~directoy~~ of the ~~webservice~~ provider. For example, if one were trying to load http://www.foo.com/service/foo.xml, the policy setting XML file would reside at http://www.foo.com/. Note that this policy file would not affect services provided on subdomains, such as http://service.foo.com/. If no file ~~was~~ found, then access ~~was~~ denied, ensuring that ~~all~~ existing ~~services~~ could ~~not~~ be called without specifically allowing it.		Both solutions used an XML file in the root directory of the web service provider. For example, if one were trying to load <tt><nowiki>http://www.foo.com/service/foo.xml</nowiki></tt>, the policy-setting XML file would reside at <tt><nowiki>http://www.foo.com/</nowiki></tt>. Note that this policy file would not affect services provided on subdomains, such as <tt><nowiki>http://service.foo.com/</nowiki></tt>. If no file were found, then access would be denied, ensuring that no existing service could be called without specifically allowing it.

	=== The Policy File ===		=== The Policy File ===
Line 25:		Line 25:
	</cross-domain-policy>		</cross-domain-policy>

	The root node is called '''cross-domain-policy''', and it contains as many '''allow''' elements as needed. The client walks the '''allow''' elements until it finds one that matches the request type and the caller's domain. If no match is found, the cross domain request is denied by the client. The DTD for the file:		The root node is called '''cross-domain-policy''', and it contains as many '''allow''' elements as needed. The client walks the '''allow''' elements until it finds one that matches both the request type and the caller's domain. If no match is found, the cross-domain request is denied by the client. The DTD for the file:

	<!ELEMENT cross-domain-policy (allow*)>		<!ELEMENT cross-domain-policy (allow*)>
Line 32:		Line 32:

	=== Whitelisting ===		=== Whitelisting ===
	The policy file works like a whitelist. ~~One~~ lists which domains ~~may~~ access web services ~~on this domain,~~ and what ~~type~~ of services may ~~be consumed from the allowed domain~~. The '''allow''' element is used for this, and the domain is specified in it's '''from''' attribute. Full domains may be used, such as www.foo.com, or wildcarded ones, such as .foo.com or even just to allow any domain. If no from attribute is set, then any domain is allowed.		The policy file works like a whitelist. It lists which outside domains have access to web-services and what types of services they may consume. The '''allow''' element is used for this, and the domain is specified in it's '''from''' attribute. Full domains may be used, such as <tt><nowiki>www.foo.com</nowiki></tt>, or wildcarded ones such as <tt><nowiki>.foo.com</nowiki></tt>, or even just <tt><nowiki></nowiki></tt> to allow any domain. If no '''from''' attribute is set, then any domain is allowed.

	=== Types of Services ===		=== Types of Services ===
	The type of service allowed is set via the case-sensitive type attribute on the allow element. The default type is "any", which allows any service to be accessed from that domain.		The type of service allowed is set via the case-sensitive '''type''' attribute on the '''allow''' element. The default type is "any", which allows any service to be accessed from that domain.

	<table cellspacing="0">		<table cellspacing="0">
Line 67:		Line 67:

	=== Delegation ===		=== Delegation ===
	The optional '''delegate''' attribute (default is false) on the '''allow''' element allows the policy file to ~~tell~~ the client ~~that~~ if ~~the webservice the matched~~ domain is trying to access ~~lives in~~ a subdomain on the current domain, then it should look for a policy file in that subdomain. If no policy file is found, access is rejected and ~~the~~ policy ~~file is no longer processed~~.		The optional '''delegate''' attribute (default is false) on the '''allow''' element allows the policy file to redirect the client to another policy file. In other words, if an outside (but allowed) domain is trying to access a web service on a subdomain on the current domain, then the client should look for a policy file in that subdomain. If no policy file is found in the subdomain, then access is rejected and access policy processing ceases.

	Given this policy file at http://www.company.com/cross-domain-policy.xml:		Given this policy file at <tt><nowiki>http://www.company.com/cross-domain-policy.xml</nowiki></tt>:

	<?xml version="1.0"?>		<?xml version="1.0"?>
Line 77:		Line 77:
	</cross-domain-policy>		</cross-domain-policy>

	If http://bar.foo.com tries to load the XML file http://www.company.com/service/foo.xml, the client will look for http://www.company.com/service/cross-domain-policy.xml. If found, that policy file is proccessed and the current policy file is discarded. If the file is missing, the current policy file is discarded ~~as well~~ and access is rejected.		If <tt><nowiki>http://bar.foo.com</nowiki></tt> tries to load the XML file <tt><nowiki>http://www.company.com/service/foo.xml</nowiki></tt>, the client will look for <tt><nowiki>http://www.company.com/service/cross-domain-policy.xml</nowiki></tt>. If found, that policy file is proccessed and the current policy file is discarded. If the file is missing, the current policy file is discarded anyway and access is rejected.

	== Concerns ==		== Concerns ==
	<ul>		<ul>
	<li>In a multi-user system, the root node needs the policy file and it also needs to delegate so that the users can regulate access. Should we perhaps put the file in the same subdirectory as the service is located? If we did, would this be a security risk? I would think not, since if the user got compromised, only his web service would be accessed, and the compromiser would already have access to all ~~it's~~ data.</li>		<li>In a multi-user system, the root node needs the policy file and it also needs to delegate so that the users can regulate access. Should we perhaps put the file in the same subdirectory where the service is located? If we did, would this be a security risk? I would think not, since if the user got compromised, only his web service would be accessed, and the compromiser would already have access to all its data.</li>
	</ul>		</ul>

Doron at 16:29, 19 May 2005

2005-05-19T16:29:03Z

← Older revision		Revision as of 16:29, 19 May 2005
Line 21:		Line 21:
	<?xml version="1.0"?>		<?xml version="1.0"?>

	<cross-domain-policy xmlns="<nowiki>http://somedomain/2005/x-domain-policy</nowiki>">		<cross-domain-policy xmlns="<nowiki>http://somedomain/2005/cross-domain-policy</nowiki>">
	<allow type="any" from="*.company.com" delegate="false"/>		<allow type="any" from="*.company.com" delegate="false"/>
	</cross-domain-policy>		</cross-domain-policy>
Line 73:		Line 73:
	<?xml version="1.0"?>		<?xml version="1.0"?>

	<cross-domain-policy xmlns="http://somedomain/2005/x-domain-policy">		<cross-domain-policy xmlns="<nowiki>http://somedomain/2005/cross-domain-policy</nowiki>">
	<allow type="xml" from="*.foo.com" delegate="true"/>		<allow type="xml" from="*.foo.com" delegate="true"/>
	</cross-domain-policy>		</cross-domain-policy>

Doron at 18:23, 18 May 2005

2005-05-18T18:23:06Z

← Older revision		Revision as of 18:23, 18 May 2005
Line 1:		Line 1:
			Note: This is a work in progress

	== Introduction ==		== Introduction ==
	One of the oldest security model in browsers today is the cross-domain policy. Browsers restrict pages from accessing data from pages on other domains. However, modern browsers can now consume services, such as XML datasources or SOAP, and such public web services are being hampered by the strict cross-domain security model. This document attempts to specify a new model, by which domains can specify which which domains can access them.		One of the oldest security model in browsers today is the cross-domain policy. Browsers restrict pages from accessing data from pages on other domains. However, modern browsers can now consume services, such as XML datasources or SOAP, and such public web services are being hampered by the strict cross-domain security model. This document attempts to specify a new model, by which domains can specify which which domains can access them.

Doron: /* Resources */

2005-05-18T18:22:23Z

Resources

← Older revision		Revision as of 18:22, 18 May 2005
Line 84:		Line 84:
	== Resources ==		== Resources ==
	<ul>		<ul>
	<li>~~<a href="~~http://www.macromedia.com/cfusion/knowledgebase/index.cfm?id=tn_14213">Macromedia Flash Cross Domain Policy Documentation~~</a>~~</li>		<li>[http://www.macromedia.com/cfusion/knowledgebase/index.cfm?id=tn_14213 Macromedia Flash Cross Domain Policy Documentation]</li>
	<li>~~<a href="~~http://lxr.mozilla.org/mozilla/source/extensions/webservices/docs/New_Security_Model.html">Mozilla's Web Services Security Model Documentation~~</a>~~</li>		<li>[http://lxr.mozilla.org/mozilla/source/extensions/webservices/docs/New_Security_Model.html Mozilla's Web Services Security Model Documentation]</li>
	</ul>		</ul>

Doron: /* Types of Services */

2005-05-18T17:44:34Z

Types of Services

← Older revision		Revision as of 17:44, 18 May 2005
Line 37:		Line 37:
	<table cellspacing="0">		<table cellspacing="0">
	<tr>		<tr>
	<td>'''Type'''</td>		<td width="20%">'''Type'''</td>
	<td>'''Description'''</td>		<td>'''Description'''</td>
	</tr>		</tr>