Same-Origin Policy

Properties#

• Why. Suppose you are redirected to an evil site that looks like your bank’s site (e.g. http://www.comdirekt.de). Without the SOP, its script could talk to the bank’s server just like the real site; with a stolen session cookie it could act in your name without you even participating.
• Enforced by the browser. The request may well reach the other server; the browser refuses to hand the result to the script.

CORS#

Cross-Origin Resource Sharing relaxes the SOP on the server’s initiative. When JavaScript requests a resource from a different host+port, the browser adds the request header

Origin: http://<host name>:<port>

The result (think: JSON) is accepted only if the response contains a matching header

Access-Control-Allow-Origin: http://<host name>:<port>

otherwise the browser reports “Cross-Origin Request Blocked: …”. Access-Control-Allow-Origin: * allows any requesting site to use the result.

Exceptions#

• Scripts can be loaded from anywhere, important for libraries: <script src="http://code.jquery.com/jquery-1.10.2.js"></script>. This seemed reasonable because images and other objects can be loaded from anywhere, too.
• This enabled JSONP, formerly the standard way to send JSON cross-origin: dynamically add <script>callback("…")</script> to the DOM, which executes callback with the data. No longer allowed, but similar exploits still exist.

The SOP addresses the third kind of web-app vulnerability, “communication of trusted information to an untrusted site”; the other two are access to private data (HTTP Server) and executing injected code (Code Injection Protection).

Example#

Sources#

• Slides 10, p. 17 (three kinds of vulnerabilities), p. 21 (SOP), p. 22 (CORS), p. 23 (exceptions, JSONP)
• DBIS_VL10 > Same-origin policy (SOP), DBIS_VL10 > CORS, DBIS_VL10 > Exceptions to the SOP
• Sheet 10, Exercise 1.3 (relative paths)