clauwa.info

The “Same Origin Policy” or “Single Domain Restriction” which is implemented by most web browser security models, prevents a document or script loaded from one web page domain from getting or setting properties of a document from another domain (that means that they must have the same protocol, domain and port in order to be allowed to access and modify each other).

Sharing data by references (that means by copying references of data and not copying values of data) across application boundaries, makes cross-site requests necessary. If for example a resource A is stored on an application A and should be shared with application B, application B only holds a reference of resource A and needs to make an cross-site request in order to fetch the description of the resource.

Solutions which allow Cross-Site Requests:

1) Cross Site Scripting (XSS)

With XSS, a web page from one origin can contain a script element from a different origin. The “foreign script”  runs with the same authority as scripts from the originating domain, allowing the script to steal cookies or directly access the originating server.

A possible solution to allow cross-site scripting without being so unsafe, is to limit the Javascript to a subset which is powerful enough to interchange data, but limits the security problems. JSONRequest is such a defined subset. It is a a global JavaScript object, which can only be used to send and receive JSON-encoded values and cannot be used to retrieve other text formats or cookies or passwords in HTTP headers. [1]

ADSafe and Caja seems also to define a “secure” subset of Javascript to allow cross-site scripting.

2) Using fragment identifiers (the hash part of an URL, like http://some.domain.com/path/to/page.html#fragmentIdentifier) for cross frame communication. Changing the fragment identifier does not cause the page to reload. Since the pages don’t reload, state can be maintained inside the page. This approach has several limitations. [2][3]

3) Using a Proxy which delegates the requests to right URL of the external domain instead of sending the request directly

4) Using Flash with cross-domain policy files which control the cross-domain calls. [4]

5) Waiting for the implementation of the W3C  proposal about access control for Cross-Site requests. The purposed staff will probably be integrated in HTML 5. They purpose mechanism to control which external sites are allowed to access which data via cross-site requests and also allow to define credentials which must be shown by any requesting client in order to be allowed to perform the request. [5]

6) Waiting for the implementation of the XMLHttpRequest 2 proposal of the W3C,  which should extend the functionality of the existing XMLHttpRequest object in order to allow for example cross-site requests. [6]

I am not sure if I mentioned ALL possibilities. If someone knows others, please tell me per email (clauwa{at}sbox{dot}tugraz{dot}at)  or comment.

[1] http://www.json.org/JSONRequest.html

[2] http://tagneto.blogspot.com/2006/06/cross-domain-frame-communication-with.html

[3] http://dojotoolkit.org/node/87

[4] http://code.google.com/p/doctype/wiki/ArticleFlashSecurityCrossDomain

[5] http://www.w3.org/TR/access-control/

[6] http://www.w3.org/TR/XMLHttpRequest2/