Cross Site XMLHttpRequest - Revision history

Jongetje: formatting changes

2007-06-06T21:22:04Z

formatting changes

← Older revision		Revision as of 21:22, 6 June 2007
Line 90:		Line 90:
	** Messes up soap: Should be researched/tested		** Messes up soap: Should be researched/tested
	** XSS/CSRF: If website A.com is vulnerable to an XSS exploit, then all the data of all other domains having accepted *.A.com is suddenly vulnerable		** XSS/CSRF: If website A.com is vulnerable to an XSS exploit, then all the data of all other domains having accepted *.A.com is suddenly vulnerable
	** Propagation of XSS: Suppose we have 3 domains, A.com, B.com and C.com. B.com retrieves data of A.com and renders this data in a <pre> environement. Domain C retrieves the content of the <pre> block of B.com. The user cannot control any values of C.com, thus C.com claims to be safe against XSS exploits		** Propagation of XSS: Suppose we have 3 domains, A.com, B.com and C.com. B.com retrieves data of A.com and renders this data in a "<pre" environement. Domain C retrieves the content of the "<pre" block of B.com. The user cannot control any values of C.com, thus C.com claims to be safe against XSS exploits

	Now suppose we can control the data of A.com ; B.com will not have an XSS exploit since it is in a<pre> tag. Unfortunately C.com has an XSS exploit and will render the code of A.com. This code now runs in the context of C.com and is able to request other data of B.com;		Now suppose we can control the data of A.com ; B.com will not have an XSS exploit since it is in a "<pre" tag. Unfortunately C.com has an XSS exploit and will render the code of A.com. This code now runs in the context of C.com and is able to request other data of B.com;
	Conclusion is that the statement in the previous bullet might have more implications than one thought.		Conclusion is that the statement in the previous bullet might have more implications than one thought.

Jongetje: /* Security worries, added stuff about propagation of XSS vulnerable material */

2007-06-06T21:19:27Z

Security worries, added stuff about propagation of XSS vulnerable material

← Older revision		Revision as of 21:19, 6 June 2007
Line 90:		Line 90:
	** Messes up soap: Should be researched/tested		** Messes up soap: Should be researched/tested
	** XSS/CSRF: If website A.com is vulnerable to an XSS exploit, then all the data of all other domains having accepted *.A.com is suddenly vulnerable		** XSS/CSRF: If website A.com is vulnerable to an XSS exploit, then all the data of all other domains having accepted *.A.com is suddenly vulnerable
			** Propagation of XSS: Suppose we have 3 domains, A.com, B.com and C.com. B.com retrieves data of A.com and renders this data in a <pre> environement. Domain C retrieves the content of the <pre> block of B.com. The user cannot control any values of C.com, thus C.com claims to be safe against XSS exploits

			Now suppose we can control the data of A.com ; B.com will not have an XSS exploit since it is in a<pre> tag. Unfortunately C.com has an XSS exploit and will render the code of A.com. This code now runs in the context of C.com and is able to request other data of B.com;
			Conclusion is that the statement in the previous bullet might have more implications than one thought.


	* Implementation attacks		* Implementation attacks
	** premature loading of data (fixed by the inner nsIStreamListener)		** premature loading of data (fixed by the inner nsIStreamListener)
	** side channel attacks (e.g. timing, computational load, measuring network speed/usage)		** side channel attacks (e.g. timing, computational load, measuring network speed/usage)

Jongetje: /* Security worries */

2007-06-04T20:24:00Z

Security worries

← Older revision		Revision as of 20:24, 4 June 2007
Line 71:		Line 71:
	* I don't see an adequate threat model described here -- what are the kinds of activities that a potential attacker might use this channel to do, and what are some ways to prevent this? For example, how will cross site XHR be used in conjunction with cross site scripting attacks?		* I don't see an adequate threat model described here -- what are the kinds of activities that a potential attacker might use this channel to do, and what are some ways to prevent this? For example, how will cross site XHR be used in conjunction with cross site scripting attacks?
	** Good point. We should create a real threat model.		** Good point. We should create a real threat model.


			* My main concern are the statements as: "make it impossible to distinguish between a access-control-failed error and network errors such as 404s."
			** How will we be able to eliminate timing attacks? There are 4 events which might abort an cross domain XHR req:
			*** Namelookup failed (hostname does not exist or is offline)
			*** Real 404
			*** rejection based upon Content-Access-Control header
			*** Rejection based upon XML <?access-control?> tag
			An attacker can check the time it takes before a request is rejected and based upon this conclude whether a certain server is running (inside a corporate firewall)



			----

			Threads/risks:
			* Functional attacks
			** DDOS : Most requests could already be done with img tags etc. Crafting post requests becomes easier(better control over post data)
			** Messes up soap: Should be researched/tested
			** XSS/CSRF: If website A.com is vulnerable to an XSS exploit, then all the data of all other domains having accepted *.A.com is suddenly vulnerable

			* Implementation attacks
			** premature loading of data (fixed by the inner nsIStreamListener)
			** side channel attacks (e.g. timing, computational load, measuring network speed/usage)

Sicking: /* Security worries */

2007-02-28T09:15:52Z

Security worries

← Older revision		Revision as of 09:15, 28 February 2007
Line 51:		Line 51:

	* Should we check for PIs even if HTTP headers has said that access is granted? It'll always be possible to circumvent those headers using .mimetypeOverride which'll make us not treat the doc as XML and thus we won't even look for PIs. Alternatively we could ignore the .mimetypeOverride when checking for PIs but that might be a problem with poorly configured servers (which is the whole reason for .mimetypeOverride)		* Should we check for PIs even if HTTP headers has said that access is granted? It'll always be possible to circumvent those headers using .mimetypeOverride which'll make us not treat the doc as XML and thus we won't even look for PIs. Alternatively we could ignore the .mimetypeOverride when checking for PIs but that might be a problem with poorly configured servers (which is the whole reason for .mimetypeOverride)
	** Do not pay attention to .mimetypeOverride when checking for PIs		** Do not pay attention to .mimetypeOverride when checking for PIs (It's ok to require that servers are properly configured. May not work for everyone, but it's safer)
	** If headers grant access do check for PIs		** If headers grant access do check for PIs
	** If headers denies access don't check for PIs		** If headers denies access don't check for PIs
Line 65:		Line 65:
	** Not including the authentication header makes it harder on CGIs since the webserver might deny access before the CGI even gets a chance to react.		** Not including the authentication header makes it harder on CGIs since the webserver might deny access before the CGI even gets a chance to react.

	* Do NOT send custom headers or cookies when talking to external sites -- this risks exposing sensitive IDs, usernames, and passwords when talking to third party services.		* Do NOT send custom headers or cookies when talking to external sites -- this risks exposing sensitive IDs, usernames, and passwords when talking to third party services.
			** We'll only include the cookie headers for the external site. Not the headers of the requesting site. It should be ok to include the cookie headers for the external site since such requests can be created already.
			** Might be a good idea to disallow custom headers when talking to external sites since such headers could confuse the server in unpredictable ways.

	* I don't see an adequate threat model described here -- what are the kinds of activities that a potential attacker might use this channel to do, and what are some ways to prevent this? For example, how will cross site XHR be used in conjunction with cross site scripting attacks?		* I don't see an adequate threat model described here -- what are the kinds of activities that a potential attacker might use this channel to do, and what are some ways to prevent this? For example, how will cross site XHR be used in conjunction with cross site scripting attacks?
			** Good point. We should create a real threat model.

Sicking: /* Security worries */

2007-02-28T09:10:42Z

Security worries

← Older revision		Revision as of 09:10, 28 February 2007
Line 32:		Line 32:

	* The first thing that worries me is that you can make POST submissions to any url and include XML data as payload. It is already possible to make POST submissions to any url, but the only possible payload is plain/text encoded form data or multipart/mixed encoded files and form data. With Cross-Site XMLHttpRequest it would be possible to send XML data. In particular there is worry that this would make it possible to do SOAP requests to any server. Note that while the page would be unable to access the data returned by the SOAP request, that isn't necessary if the request itself is "transfer all users money to account 12345-67". To avoid this we could either use the model as for non-GET-non-POST requests defined in the XHR spec [http://lists.w3.org/Archives/Public/public-webapi/2006Jun/0012], or we could use something like [http://lxr.mozilla.org/mozilla/source/extensions/webservices/docs/New_Security_Model.html]		* The first thing that worries me is that you can make POST submissions to any url and include XML data as payload. It is already possible to make POST submissions to any url, but the only possible payload is plain/text encoded form data or multipart/mixed encoded files and form data. With Cross-Site XMLHttpRequest it would be possible to send XML data. In particular there is worry that this would make it possible to do SOAP requests to any server. Note that while the page would be unable to access the data returned by the SOAP request, that isn't necessary if the request itself is "transfer all users money to account 12345-67". To avoid this we could either use the model as for non-GET-non-POST requests defined in the XHR spec [http://lists.w3.org/Archives/Public/public-webapi/2006Jun/0012], or we could use something like [http://lxr.mozilla.org/mozilla/source/extensions/webservices/docs/New_Security_Model.html]
			** It is already possible to POST arbitrary data using <form encoding="text/plain">
			** Should still investigate if this will mess up SOAP servers
			** Using magic url is bad if you want different policies for different files in the same directory.
			** Caching should prevent excessive extra GETs even in the case of POST

	* Should we try to follow these specs even when accessing files on the same domain? From the sites point of view they can't rely on that anyway since all browsers don't support the access-control spec (and old versions never will).		* Should we try to follow these specs even when accessing files on the same domain? From the sites point of view they can't rely on that anyway since all browsers don't support the access-control spec (and old versions never will).
			** No. It'll just trick developers into thinking they are protected against things they really aren't.

	* We have to make sure to not notify the onreadystatechange listener or any other listeners until we've done all access control checks. Otherwise it would be possible to check for the availability of files on other servers though you couldn't actually read the content.		* We have to make sure to not notify the onreadystatechange listener or any other listeners until we've done all access control checks. Otherwise it would be possible to check for the availability of files on other servers though you couldn't actually read the content.
			** Should be taken care of by the inner nsIStreamListener approach

	* We have to make sure to not put data in .responseText until we've passed access control checks even for XML files.		* We have to make sure to not put data in .responseText until we've passed access control checks even for XML files.
			** Should be taken care of by the inner nsIStreamListener approach

	* We have to make it impossible to distinguish between a access-control-failed error and network errors such as 404s. Can the implementation "recancel" a canceled channel?		* We have to make it impossible to distinguish between a access-control-failed error and network errors such as 404s. Can the implementation "recancel" a canceled channel?
			** Might be possible to recancel, have to check implementations.
			** Alternative might be to make sure that clients of the new code doesn't use the errorcode on the channel but rather the one passed in from onStartRequest/onStopRequest

	* Should we check for PIs even if HTTP headers has said that access is granted? It'll always be possible to circumvent those headers using .mimetypeOverride which'll make us not treat the doc as XML and thus we won't even look for PIs. Alternatively we could ignore the .mimetypeOverride when checking for PIs but that might be a problem with poorly configured servers (which is the whole reason for .mimetypeOverride)		* Should we check for PIs even if HTTP headers has said that access is granted? It'll always be possible to circumvent those headers using .mimetypeOverride which'll make us not treat the doc as XML and thus we won't even look for PIs. Alternatively we could ignore the .mimetypeOverride when checking for PIs but that might be a problem with poorly configured servers (which is the whole reason for .mimetypeOverride)
			** Do not pay attention to .mimetypeOverride when checking for PIs
			** If headers grant access do check for PIs
			** If headers denies access don't check for PIs
			*** This is so that it's easy to deny access everywhere on a server level

	* We should make sure to make it impossible to set authentication headers since that would make it easier for a site to attempt (distributed) brute force hacking against authenticated servers. Note though that such hacking would be significantly complicated by the fact that the server must be password protected but still have files that it grants access to a 3rd party server, which doesn't really make a lot of sense.		* We should make sure to make it impossible to set authentication headers since that would make it easier for a site to attempt (distributed) brute force hacking against authenticated servers. Note though that such hacking would be significantly complicated by the fact that the server must be password protected but still have files that it grants access to a 3rd party server, which doesn't really make a lot of sense.
			** Also disallow passing login arguments to .open()

	* Timeless left some comments at [http://docs.google.com/Doc?id=dhmd4jxt_27ggbhc8]		* Timeless left some comments at [http://docs.google.com/Doc?id=dhmd4jxt_27ggbhc8]

			* Should we send authentication information with the first GET request for the case when we do two requests? Should we send cookies? Alternative is to prefix authentication and cookie headers with 'xmlhttprequest-' or similar to avoid affecting existing servers but allow aware servers to look at relevant headers.
			** We might as well include authentication headers and cookies in the original GET since that request can be done by any thirdparty anyway.
			** Not including the authentication header makes it harder on CGIs since the webserver might deny access before the CGI even gets a chance to react.

	* Do NOT send custom headers or cookies when talking to external sites -- this risks exposing sensitive IDs, usernames, and passwords when talking to third party services.		* Do NOT send custom headers or cookies when talking to external sites -- this risks exposing sensitive IDs, usernames, and passwords when talking to third party services.

	* I don't see an adequate threat model described here -- what are the kinds of activities that a potential attacker might use this channel to do, and what are some ways to prevent this? For example, how will cross site XHR be used in conjunction with cross site scripting attacks?		* I don't see an adequate threat model described here -- what are the kinds of activities that a potential attacker might use this channel to do, and what are some ways to prevent this? For example, how will cross site XHR be used in conjunction with cross site scripting attacks?

BradNeuberg: /* Security worries */

2007-02-25T07:02:32Z

Security worries

← Older revision		Revision as of 07:02, 25 February 2007
Line 46:		Line 46:

	* Timeless left some comments at [http://docs.google.com/Doc?id=dhmd4jxt_27ggbhc8]		* Timeless left some comments at [http://docs.google.com/Doc?id=dhmd4jxt_27ggbhc8]

			* Do NOT send custom headers or cookies when talking to external sites -- this risks exposing sensitive IDs, usernames, and passwords when talking to third party services.

			* I don't see an adequate threat model described here -- what are the kinds of activities that a potential attacker might use this channel to do, and what are some ways to prevent this? For example, how will cross site XHR be used in conjunction with cross site scripting attacks?

Sicking: /* Security worries */

2007-02-21T23:26:47Z

Security worries

← Older revision		Revision as of 23:26, 21 February 2007
Line 44:		Line 44:

	* We should make sure to make it impossible to set authentication headers since that would make it easier for a site to attempt (distributed) brute force hacking against authenticated servers. Note though that such hacking would be significantly complicated by the fact that the server must be password protected but still have files that it grants access to a 3rd party server, which doesn't really make a lot of sense.		* We should make sure to make it impossible to set authentication headers since that would make it easier for a site to attempt (distributed) brute force hacking against authenticated servers. Note though that such hacking would be significantly complicated by the fact that the server must be password protected but still have files that it grants access to a 3rd party server, which doesn't really make a lot of sense.

			* Timeless left some comments at [http://docs.google.com/Doc?id=dhmd4jxt_27ggbhc8]

HeikkiToivonen: /* Details */

2007-02-21T00:32:34Z

Details

← Older revision		Revision as of 00:32, 21 February 2007
Line 10:		Line 10:

	Additionally [http://lists.w3.org/Archives/Public/public-webapi/2006Jun/0012] is a draft spec for how XMLHttpRequest should interact with the access-control spec. This spec describes some headers that should be included when making a cross site request. (Though I personally wonder if this part should be moved into the access-control spec.) It also describes how to deal with http methods other than GET and POST.		Additionally [http://lists.w3.org/Archives/Public/public-webapi/2006Jun/0012] is a draft spec for how XMLHttpRequest should interact with the access-control spec. This spec describes some headers that should be included when making a cross site request. (Though I personally wonder if this part should be moved into the access-control spec.) It also describes how to deal with http methods other than GET and POST.

			What about [http://lxr.mozilla.org/mozilla/source/extensions/webservices/docs/New_Security_Model.html]?

	== Suggested Implementation ==		== Suggested Implementation ==

Sicking: /* Security worries */

2007-02-20T19:13:28Z

Security worries

← Older revision		Revision as of 19:13, 20 February 2007
Line 40:		Line 40:

	* Should we check for PIs even if HTTP headers has said that access is granted? It'll always be possible to circumvent those headers using .mimetypeOverride which'll make us not treat the doc as XML and thus we won't even look for PIs. Alternatively we could ignore the .mimetypeOverride when checking for PIs but that might be a problem with poorly configured servers (which is the whole reason for .mimetypeOverride)		* Should we check for PIs even if HTTP headers has said that access is granted? It'll always be possible to circumvent those headers using .mimetypeOverride which'll make us not treat the doc as XML and thus we won't even look for PIs. Alternatively we could ignore the .mimetypeOverride when checking for PIs but that might be a problem with poorly configured servers (which is the whole reason for .mimetypeOverride)

			* We should make sure to make it impossible to set authentication headers since that would make it easier for a site to attempt (distributed) brute force hacking against authenticated servers. Note though that such hacking would be significantly complicated by the fact that the server must be password protected but still have files that it grants access to a 3rd party server, which doesn't really make a lot of sense.

Peterv: Link to latest version of spec

2007-02-20T15:32:12Z

Link to latest version of spec

← Older revision		Revision as of 15:32, 20 February 2007
Line 5:		Line 5:
	== Details ==		== Details ==

	There are currently two draft specs from w3c for how this should work. The signaling for when a document is accessible is spec'ed in the access-control draft spec [http://~~lists~~.w3.org/~~Archives~~/~~Public/public~~-~~appformats~~/~~2006Oct/att-0001/AC-2006-10-02-Porter.html~~]. This states that the site can insert <?access-control?> processing instructions into XML files that says which sites can access the file. It also allows for http-headers to be added to allow access to be controlled to any file type.		There are currently two draft specs from w3c for how this should work. The signaling for when a document is accessible is spec'ed in the access-control draft spec [http://www.w3.org/TR/access-control/]. This states that the site can insert <?access-control?> processing instructions into XML files that says which sites can access the file. It also allows for http-headers to be added to allow access to be controlled to any file type.

	The PI contains lists of URL patterns that describe which URLs can access the file. These patterns can contain wildcards, but follow strict parsing rules rather than being general URLs.		The PI contains lists of URL patterns that describe which URLs can access the file. These patterns can contain wildcards, but follow strict parsing rules rather than being general URLs.