Web Appsec — Part 1 — Same Origin Policy

5 min readOct 1, 2018

Web applications are central to our day-to-day activities — this includes banking, shopping, email, and social media. Given that the web has become a central fixture in our lives, understanding the fundamentals of web application security is more crucial than ever. Books like the The Tangled Web, Web Application Hacker’s Handbook and Hacking Exposed: Web Applications are great introductions to the concepts but are not up-to-date. This tutorial series is meant to be a beginner friendly introduction to web application security, taking into account newer attacks, techniques and mitigation methods. I will be working off the assumption that readers are acquainted with the specifics of HTML and JS.

This is my first attempt at making a series and will most likely go through multiple revisions. Feel free to tweet me at @itsC0rg1 and share your feedback, I look forward to sharing this journey with you.

URL

Universal Resource Locator (URL) is the address used to uniquely reference a remote resource. It is populated in the address bar of the browser, for example, your address bar should currently show — “https://medium.com/@itsc0rg1/web-appsec-part-1-same-origin..", which is the URL for the page you are currently on. The structure of the URL is broken down below, but not all sections are required in every instance,

Scheme / Protocol — The protocol being used to retrieve the resource. Can be http,https, ftp, data, javascript (these two will become interesting in later parts) and so on.
Credentials — Username and password used to authenticate the user to the server. If the password is empty server will try to fetch the resource anonymously.
Domain — This section can either be a DNS name or an IP address (v4 / v6).
Port — Port on the server that the client is trying to reach.
Path — Path of the file being requested from the server.
Filename — Name of the file that is being requested by the client.
Query string — Parameters that are parsed by the server to perform actions based on the values. These parameters are typically generated by HTML forms.
Fragment — This section is never sent to the server. It is typically used by the browser to shift focus to a specific section of a web page or read by Javascript using location.hash to perform client side actions.

A more detailed overview of URLs is available in Chapter 2 of “The Tangled Web”, I highly recommend reading it. For the subsequent sections, we will be focusing on the protocol, domain and port.

Same Origin Policy

Let’s dive into the foundational principle of web application security, the Same Origin Policy. The policy is implemented by the browser, it will prevent scripts from one origin from accessing content on another. Origin is defined as a combination of — port, protocol and fully qualified domain name (FQDN), two pages are treated as the same origin if all three match.

Walkthrough

Consider https://www.example.com/test.html, this will,

*Typically, http is served over 80 and https is over 443, ** Internet Explorer ignores ports

Document Object Model (DOM)

Without the Same Origin Policy, Javascript can read cookies, modify / access the DOM of the across different websites. The browser will only allow scripts on one page to access / modify the DOM (Document Object Model) of another page if the origins match. Speaking of DOM, it is a tree representation of the webpage, making it easier for browsers to parse and interact with the webpage. For example, the following webpage,

<html>
 <head>
  <title> Corgi facts </title>
  <h1> Corgis are the best! </h1>
 </head>
 <body>
  <p id="intro"> Corgis were herding dogs</p>
  <b> Corgi is #11 in terms of intelligence in dogs </b>
 </body>
</html>

Will be represented as,

Using Javascript you can access specific elements on the DOM, for example if you wish to fetch the <p> tag, you can use -

document.getElementById("intro")

to fetch,

<p id="intro"> Corgis were herding dogs</p>

If you wish to fetch only the content within the <p> tag,

document.getElementById("intro").innerHTML

will return,

Corgis were herding dogs

Same Origin Policy in action

Consider the following example, an attacker creates an iframe which points to a shopping site. Without the SOP, you could make a victim buy items,

<iframe id="shop" src="https://www.exampleshop.com"></iframe>
 <script>
  var evilFrame = document.getElementById('shop');
  evilFrame.addEventListener("load", function() {
   document.getElementById('shop').contentWindow.document.
    getElementById('buy').click();
</script>

This will fail, with the following error appearing in the Javascript Console —

Uncaught DOMException: Blocked a frame with origin "https://www.attacker.com" from accessing a cross-origin frame.

Fetching the Origin using Javascript

Document.domain and location.hostname will return the domain, but not protocol or port. To fetch the origin in its entirety, you can use the read only property location.origin.

For example, https://www.corgi.com will return,

document.domain → "www.corgi.com"location.hostname → "www.corgi.com"location.origin → "https://www.corgi.com"

Domain lowering

A document can set its domain to its super domain, for example, woof.corgi.com can set its domain to corgi.com (but not .com). In addition to this, browsers will allow a document to access another if the origins match or if both documents have the same value set using the document.domain property. That is, two documents have to set their values to match, aka opt-in to share, this means that a document which has the same document.domain value as the origin of another cannot access their content.

Next up

We will explore HTTP protocol, headers and cookies in the next post. Following that we will dive into CORS (Cross Origin Resource Sharing), a mechanism that allows web page with different domains to share information.

References

Web Appsec — Part 1 — Same Origin Policy

Written by its C0rg1