8

Consider the following scenario:

Alice wishes to browse Victor's website while on the job at Initech. Victor's website is hosted on an alternative domain name system to which Initech's DNS does not peer. Eve (wishing to facilitate the free and open exchange of knowledge) hosts a webpage containing JS that performs domain-name resolution and URL masking such that when Alice visits victor.eve.tld an iFrame loads victor.alt based off of the static IP address Victor has designated in the victor.alt DNS record.

For seamless domain-name masking, Victor must place CORS authorization in the headers from his site to dance around the single origin policy. However, Victor suspects that Michael is trying to hack into Eve's web server and plant malicious JS into Eve's webpage (the parent of the iFrame). Victor wants verify that Michael has not modified the contents of the parent frame before he enables CORS authorization.

Victor has a copy of Eve's site and can include hashes of the material w/ out contacting Eve's server, so if he has read access, he can match the content. Micheal does not have access to Initech servers and connections from both sites are secured using TLS: assume that Micheal cannot carry out a man-in-the-middle attack.

Is it possible for an iFrame to verify the contents of the parent window:

  • using any CORS configuration?
  • while allowing read-only access?
  • while limiting the the parent window's access to the content of the iFrame?

There are prior discussions regarding client-side JS verification from an untrusted cache (with a trusted connection, no MtM) but this situation requires validation by the material that is being fetched. There are also numerous posts regarding the use of iFrames to sandbox untrusted code. However, iFrame sand-boxing questions tend to revolve around a the parent window trusting the child, as does most of the external literature on the subject (frame-busting, etc).

Furthermore, Eve's server cannot actively participate in the process: she can only serve static HTML, JS, and CSS files. Victor cannot proxy information through Eve's server, he can only interact with his own or 3rd party servers.

Community
  • 1
Indolering
  • 852
  • 6
  • 21

1 Answers1

2
  • using any CORS configuration?

If Eve sets her CORS header to Access-Control-Allow-Origin "victor.alt" Victor can verify the contents of the HTML it retrieves and verify all referenced scripts as well.

  • while allowing read-only access?
  • while limiting the the parent window's access to the content of the iFrame?

Neither of these exist, an iFrame cannot read the contents of another iFrame unless they are on the same domain.

However, you could push any user information you want to keep private from Victor into a sandboxed iFrame and using window.postMessage to communicate between frames. Victor can monitor the activity between the two to ensure that no information is being leaked.

Indolering
  • 852
  • 6
  • 21
Philipp Gayret
  • 1,383
  • 2
  • 10
  • 14
  • I've updated the question to clarify that Victor does not need to check Eve's site at run time, he can simply include them in his JS. – Indolering Sep 10 '13 at 04:51
  • Okay, it seems as if CORS does not allow for read-only access. Indeed, *none* of the browser security mechanisms include read-only mechanisms. The only parts that need to persist across sessions is domain<->IP mappings in localStorage. What if the read/write access was set by script that was sandboxed from **all** parties? The parent frame only needs to rewrite .alt -> eve.tld and manage the URL states. – Indolering Sep 10 '13 at 05:44
  • When you said "Victor does not need to check Eve's site at run time", he has to to verify it has no malicious JS injected. Also what do you mean exactly with "What if the read/write access was set by script that was sandboxed from all parties?" You really cant have read access to a parent or child frame, you can pretty much only use postMessage to communicate ( or change the URL #hashthing ) – Philipp Gayret Sep 10 '13 at 14:13
  • I just didn't understand why you were verifying the site contents using a proxy. As far as the read/write access, if a user made it to the correct IP, then Victor really doesn't care what DNS information Alice has. Thus he only needs to verify the URL rewriting JS and we can prevent Victor from tampering with the DNS information. – Indolering Sep 10 '13 at 16:16
  • You need a proxy when you cannot CORS directly from iframe victor.alt to victor.eve.tld, that's what i posted in the answer. ( The proxy is more or less our read access to the top window, because we cannot read the iframe nor can we request victor.eve.tld/ which would be the other option ) – Philipp Gayret Sep 10 '13 at 20:50
  • Alright, ive updated my answer, lastly, "For seamless domain-name masking, Victor must place CORS authorization in the headers from his site to dance around the single origin policy" Why do we need to use CORS? Wouldn't it be a lot simpler if you'd use the fragment identifier, and changing the iframe location when it changes, and vice-versa? – Philipp Gayret Sep 10 '13 at 21:03
  • let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/10544/discussion-between-indolering-and-philipp) – Indolering Sep 10 '13 at 22:13