Gayblack Canadian Man

Foreign Policy Analysis
Same-origin policy

Same-origin policy


In computing, the same-origin policy is an
important concept in the web application security model. The policy permits scripts running on pages
originating from the same site – a combination of scheme, hostname, and port number – to
access each other’s DOM with no specific restrictions, but prevents access to DOM on different sites. The same-origin policy also applies to XMLHttpRequest
and to WebSocket. This mechanism bears a particular significance
for modern web applications that extensively depend on HTTP cookies to maintain authenticated
user sessions, as servers act based on the HTTP cookie information to reveal sensitive
information or take state-changing actions. A strict separation between content provided
by unrelated sites must be maintained on the client side to prevent the loss of data confidentiality
or integrity. History
The concept of same-origin policy dates back to Netscape Navigator 2 in 1995. All modern browsers implement some form of
the Cross Origin Policy as it is an important security cornerstone. The policies are not required to match an
exact specification but are often extended to define roughly compatible security boundaries
for other web scripting languages, such as Adobe Flash or Adobe Acrobat, or for mechanisms
other than direct DOM manipulation, such as XMLHttpRequest. Origin determination rules
The algorithm used to calculate the “origin” of a URI is specified in RFC 6454, Section
4. For absolute URIs, the origin is the triple
{protocol, host, port}. If the URI does not use a hierarchical element
as a naming authority or if the URI is not an absolute URI, then a globally unique identifier
is used. Two resources are considered to be of the
same origin if and only if all these values are exactly the same. To illustrate, the following table gives an
overview of typical outcomes for checks against the URL “http:www.example.compage.html”. Unlike other browsers, Internet Explorer does
not include the port in the calculation of the origin, using the Security Zone in its
place. Relaxing the same-origin policy
In some circumstances the same-origin policy is too restrictive, posing problems for large
websites that use multiple subdomains. Here are four techniques for relaxing it:
document.domain property If two windows contain scripts that set domain
to the same value, the same-origin policy is relaxed for these two windows, and each
window can interact with the other. For example, cooperating scripts in documents
loaded from orders.example.com and catalog.example.com might set their document.domain properties
to “example.com”, thereby making the documents appear to have the same origin and enabling
each document to read properties of the other. This might not always work as the port stored
in the internal representation can become marked as null. In other words example.com port 80 will become
example.com port null because we update document.domain. Port null might not be treated as 80 and hence
might fail or succeed depending on your browser. Cross-Origin Resource Sharing
The second technique for relaxing the same-origin policy is being standardized under the name
Cross-Origin Resource Sharing. This draft standard extends HTTP with a new
Origin request header and a new Access-Control-Allow-Origin response header. It allows servers to use a header to explicitly
list origins that may request a file or to use a wildcard and allow a file to be requested
by any site. Browsers such as Firefox 3.5 and Safari 4
use this new header to allow the cross-origin HTTP requests with XMLHttpRequest that would
otherwise have been forbidden by the same-origin policy. Cross-document messaging
Another new technique, cross-document messaging allows a script from one page to pass textual
messages to a script on another page regardless of the script origins. Calling the postMessage() method on a Window
object asynchronously fires an “onmessage” event in that window, triggering any user-defined
event handlers. A script in one page still cannot directly
access methods or variables in the other page, but they can communicate safely through this
message-passing technique. JSONP
JSONP allows a page to receive JSON data from a different domain by adding a

Leave a Reply

Your email address will not be published. Required fields are marked *