ideas-to-use-iframe

Hackerのフェイク関数を見破るためにiframeを使用する方法を考察する。

// (1) iframe のエレメントを生成する。
const el_iframe=document.createElement("iframe");

// この時点では、el_iframe.contentDocument は null である。

// (2) iframe を DOM 内に挿入する。
document.body.appendChild(el_iframe);

// el_iframe.contentDocument は null でないが、override されている可能性がある。

問題は、(2)である。この appendChild が override されていれば、
el_iframe も改ざんされている可能性がある。
el_iframe.contentDocument.write も、もはや本物である確証はない。
従って、この appendChild(el_iframe) を迂回することが重要になる。

【idea 1】
<iframe>.......</iframe>のようにHTMLコードで挿入した場合、
appendChild を迂回できないだろうか？
結論：無理みたい ==> srcdoc.php

【idea 2】
MutationObserver で body を観察して、appendChild(el_iframe) で挿入した場合、
たとえこれが、Hacker の appendChild だったとしても、MutationObserver の
callback が呼ばれて、el_iframe.contentDocument から document の
オブジェクトを取得できる。これはまだ Hacker が document を override
する前である。この時点で、document.write の pointer を取得しておけば、
後で変更されたかどうかわかる。

結論：MutationObserverのcallbackはDispatcherから来る別のスレッドで
やってくるので、Hackerが先にdocumentを取得してしまう。

definePropertyのgetや、Proxyなどを使って、Hackerより先に
documentの取得を試みたが、無理そうである。
test0.php |
test1.php |
test2.php |
test3.php |
test4.php |

原因は、iframeのdocumentを取得するためには、
document.createElementとdocument.body.appendChildを
呼ばなければいけないので、それらの関数をoverrideされると、
Hackerが先にdocumentを取得してしまうのである。

この問題を解決するには、document.createElementと
document.body.appendChildの２つの関数が、絶対に
Overrideされていないことを確認する必要がある。

やる価値はあると思う。なぜなら、この方法では、
完全に純粋なdocument&windowオブジェクトが
入手できるからである。