0

In my webpage from donain A I show another website from domain B in an iframe. I think website B can choose some fresh colors so I want to edit the background color of the body and change it to blue.

If I try this with javascript by getting the DOM of the iframe, and then editing the body's background color, I get a security error because website B is on another domain.

If open up the developer tools (F12) and I just edit the dom there it works fine.

So I'm really confused: why would a browser allow me to edit the dom by hand, but not by javascript? Obviously any kind of security measures this cross domain policy is supposed to imply is compromised by anybody who can press F12, thus it makes no sense for the browser to block access.

Alternatively, I could just scrape website B with my server, and put the (illegally) retrieved HTML inside my own website (with a nicer color). Again I bypassed the cross domain policy and thus did what the cross domain policy forbids me to do.

As a related question, is there anyway to change the color of an element with javascript inside an iframe without getting a cross domain error?

user1884155
  • 3,616
  • 4
  • 55
  • 108
  • 2
    [**Same Origin Policy**](http://en.wikipedia.org/wiki/Same-origin_policy) – adeneo Apr 17 '15 at 15:07
  • http://stackoverflow.com/questions/3076414/ways-to-circumvent-the-same-origin-policy – adeneo Apr 17 '15 at 15:07
  • Because Javascript can be evil and attack you, whereas the browser assumes that you will not be evil and attack yourself. (this assumption is [not always true](http://stackoverflow.com/q/21692646/34397)) – SLaks Apr 17 '15 at 15:07
  • @SLaks wetware, always the weakest link :( – Paul S. Apr 17 '15 at 15:09
  • @adeneo I understand the policy, but why does the browser tools lets me bypass it anyway? Additionally, I can scrape the site and edit it too. What good does the policy do here? – user1884155 Apr 17 '15 at 15:09
  • @user1884155 the difference here is who can access _JavaScript_ vs who can access the _Console_ – Paul S. Apr 17 '15 at 15:10
  • @user1884155: Because you can be trusted to not attack yourself. (usually) – SLaks Apr 17 '15 at 15:10
  • @slaks: I don't understand. Could you plz give an answer with examples. "the browser assumes..."? I can edit any html I want with the browser, what is it assuming? – user1884155 Apr 17 '15 at 15:11
  • @user1884155: That you aren't going to steal money from your own bank account. – SLaks Apr 17 '15 at 15:11
  • @user1884155 it's assuming that a 3rd party isn't controlling the _Console_ input, whereas a third party could be loading in an external JavaScript resource – Paul S. Apr 17 '15 at 15:11

2 Answers2

1

The Same Origin Policy prevents malicious Javascript from interacting with other domains.
Otherwise, attackers could write code that silently interacts with your email or bank account.

The dev tools assume that you will not be evil and attack yourself. (this assumption is not always true)

Community
  • 1
  • 1
SLaks
  • 868,454
  • 176
  • 1,908
  • 1,964
  • But I'm in domain A, and I'm changing the website from domain B? Why does it not trust my own javascript (from domain A) and mistrust the content from domain B (not my own) – user1884155 Apr 17 '15 at 15:13
  • It has no right to assume that JavaScript in domain A is not malicious. – SLaks Apr 17 '15 at 15:26
1

why would a browser allow me to edit the dom by hand

If is your browser. It trusts you.

but not by javascript?

Your browser doesn't trust the person who wrote the JavaScript on Domain A with the rights to access the data that the person who wrote the page on Domain B gave to you.

What if Domain A was a random site you found linked in your email and Domain B was your online banking?

It is important to remember that there are potentially three people involved:

  • The person controlling the browser
  • The person controlling Domain A
  • The person controlling Domain B

Some of those may be the same person, but they may not and the browser has no way to tell.

Alternatively, I could just scrape website B with my server

In that case, Domain B is trusting Domain A with the data in the first place.

Domain A wouldn't have access to things that your browser has access to (such as your cookies for Domain B) which might cause Domain B to give you different data (like your own banking records).

As a related question, is there anyway to change the color of an element with javascript inside an iframe without getting a cross domain error?

Only with the cooperation of Domain B, in which case you could use postMessage to ask Domain B to change the colour. (Domain B would have to register an event listener so it could hear the request).

Quentin
  • 914,110
  • 126
  • 1,211
  • 1,335
  • let's say the same origin policy didn't exist and I open a bank website in an iframe. what javascript could I write in my own website to steal money? – user1884155 Apr 17 '15 at 15:15
  • 1
    @user1884155 `iframe.src = 'client_internet_bank.com';` then after load, `iframe.contentDocument.getElementById('login_form').addEventListener('submit', function (e) {/* send login data elsewhere before proceeding*/})` .. But don't worry - this won't work on any mainstream browser :) – Paul S. Apr 17 '15 at 15:17
  • 1
    You could write javascript targeting a specific bank's website that could scrape account numbers or something more general that just tracked what websites you were going to and logged all your mouse clicks / keystrokes which after a day's browsing could basically give whoever access to all of your passwords. – hobberwickey Apr 17 '15 at 15:17
  • Hypothetically and simplistically : `document.frames[0].forms[0].recipient = 12345; document.frames[0].forms[0].sortcode = 401212; document.frames[0].forms[0].amount = 12345.00; document.frames[0].forms[0].submit()= 12345;` – Quentin Apr 17 '15 at 15:18