2011-12-05 20 views
8

iframeを持つページがあります。ページとiframeのソースは異なるドメインにあります。 iframeの中で、私はCuteEditorというリッチテキストエディタを使用しています(それはとてもかわいいと判明しています)。 CuteEditorには「ドキュメント」にアクセスしようとする特定のJavaScript関数がありますが、ブラウザは同じドメインにないためアクセスを拒否しています。それはminfiedとすべての変数名は不可解ですので、難読化されていますので、問題外であるiframeから親フレームにアクセスできないようにするにはどうすればよいですか?

Permission denied to access property 'document' http://dd.byu.edu/plugins/cuteeditor_files/Scripts/Dialog/DialogHead.js Line 1

ジャバスクリプトの編集:

はここで正確なエラーです。

これは作業プロジェクトであり、これは私が使用するように言われているエディタですので、別のエディタを使用することは現在のところ不安です。

iframeを内蔵したままにする方法はありますか?だから、iframe内のすべてを行い、親フレームに飛び出そうとしませんか?

答えて

-2

あなたはそのことについて心配する必要はありません。

iframeがcross-originを話す唯一の方法は、postMessageです。これは、そのドメインを直接聞いている場合にのみ可能です。

https://developer.mozilla.org/en/DOM/window.postMessage

+0

ただし、このエラーのため、CuteEditorはiframe内で動作しません。それでは別の問題ですか? – Justin

+0

わかりません。あなたのソースコードを見る必要があります。 –

7

子はiframeが別のドメインからロードされた場合、親ページやDOMにアクセスすることはできません。

ただし、man-in-the-middle攻撃には次のような脆弱性が存在します。 http://yoursite.com離れてあなたのページの負荷を仮定とiframeがhttp://badsite.org

  • 最初http://badsite.orgに行くと、これは、man-in-the-middle攻撃を必要とするステップであるhttp://yoursite.com/badpage

  • にリダイレクトします。攻撃者は、ユーザーとyoursite.comの間を行き来するか、またはDNSルックアップに対する回答を制御できる必要があります。これは簡単に聞こえます。パブリックWiFiアクセスポイントを管理できる人は誰でも(スターバックス、ホテル、空港を考えてみてください)、実際のサイトではなく攻撃者のサイトからhttp://yoursite.com/badpageのコンテンツを配信することです。

  • 攻撃者は、(偽の)http://yoursite.org/badpageから好きな悪意のあるコードを提供することができます。これはメインページと同じドメインにあるため、親DOMにアクセスできます。

HTML5 iframeサンドボックスの属性がこれを回避する方法のようです。 specを読むことができますが、最も適切な説明はhereです。

これはChromeIE10FireFoxSafariでサポートしているようです。

「allow-same-origin」属性がではなく、に設定されている場合、「コンテンツは固有の起源のものとして扱われます」という仕様があります。これにより、ブラウザがURLを何と考えているかに関係なく、子供のiframeが親のDOMの一部にアクセスできなくなります。

+0

攻撃は述べたように簡単ではありません。デバイスがDNSからyoursite.comにアドレスを取得すると、デバイスはさらにアクセスするためにキャッシュします。この攻撃を完全に実装するには、HTTPプロキシが必要です。中間者は、http://yoursite.com/badpageをiframe srcとして使用するようにWebページを書き直す必要があります。これは、ページを変更するためにプロキシがHTTPSとしてHTTPSを模倣しなければならないため、HTTPSを使用するとさらに複雑になります。それは不可能ではありませんが、サイトが攻撃者にとって魅力的でない限り(銀行、オークション、またはパスワードを収集するために使用できる大規模なサイトなど)、露出は低いです。 – fernacolo

関連する問題