別のドメインからiFrameコンテンツにアクセスする

今日、私たちのプロジェクトindexisto.comでGoogleウェブマスターマーカーツールの類似物を作成した方法についてお話したいと思います。 MarkerはGoogle Webmasterアカウントのツールであり、Open Graphページにタグを付けることができることを思い出してください。 これを行うには、マウスでページ上のテキストを選択し、それがタイトルであり、これが評価であることを示すだけです。 ウェブマスターのオフィスのiframeにページが読み込まれます。







今、あなたのサイトで似たようなページに出会ったグーグルは、その上にどんな種類のコンテンツが公開されているか、そしてそれを本質的に美しく分析する方法を知っています（記事、製品、ビデオ..）



同様の機能が必要でした。 タスクは単純で、クライアント側のみに見えました。 ただし、実際には、ソリューションはクライアント側とサーバー側の接合部にあります（「クリーンな」JSプログラマーはさまざまなプロキシサーバーについて何も知らず、発射体に近づくのに非常に長い時間がかかる場合があります）。 同時に、最初から最後まですべての技術を説明する記事をインターネット上で見つけられませんでした。 また、 BeLoveユーザーとセキュリティチームの支援に感謝します。







この場合、ウェブマスターが（マウスのクリックで）ページ上の特定の要素のxPath値を簡単に取得できるようにしたいと思います。

iframe「同じオリジン」

そのため、管理パネルで、ユーザーは自分のサイトのページのURLを入力する必要があります。iFrameに表示し、必要に応じてマウスをつついて、目的のxPathを取得します。 すべては問題ありませんが、ブラウザのセキュリティポリシーにより、管理パネル（ドメイン）のiframeに読み込まれた別のドメインからページのコンテンツにアクセスすることはできません。

CORS-クロスオリジンリソース共有

何人かの人々はCORSを使用するように私に助言した。 ブラウザ内の別のドメインからのコンテンツへのアクセスに関する多くの問題を解決し、同じ生成元ポリシーの制限を回避できるファッショナブルなテクノロジー。

外部ドメインのページのコンテンツへのアクセスを許可するサイトは、httpヘッダーに単純に書き込みます。

Access-Control-Allow-Origin: http://example.com
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

また、ブラウザの別のドメインのページから送信されるリクエストのhttpヘッダーには、発信元フィールドが必要です。

 Origin: www.mysupersite.com
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ブラウザがリクエスト自体に発信元フィールドを追加することは明らかです。 Habréに関する記事を追加し、最新のブラウザが同じドメインのリクエストにもOriginを追加することを確認します。





ただし：

1. ブラウザは 、iframeに読み込まれたページのリクエストヘッダーにオリジンを配置しません （理由は誰にも説明できますか？）
2. ウェブマスターにAccess-Control-Allow-Originヘッダーの書き込みを依頼したくない

iframeサンドボックス

別のトレンディな技術。 サンドボックスは、Iframeタグの属性です。 値allow-same-originをこの属性の値の1つとして設定できます。 このトピックを掘り始める前に、この属性が何をしているのか正確には知りませんでしたが、非常に魅力的でした。 ただし、sandbox属性は、iframeに読み込まれたページで実行できることを制限するだけで、親ドキュメントからフレームのコンテンツにアクセスする問題とは関係ありません。



具体的には、値allow-same-origin （またはその不在）は、iframeは常に他の誰かのドメインからダウンロードされたと見なされることを示しています（たとえば、そのようなフレームから親ドキュメントのドメインにAJAXリクエストを送信することはできません）

Googleでどのように行われるか見てみましょう

兄貴がしたことの時間を描く





iframe要素のsrc属性に注意してください： src="https://wmthighlighter.googleusercontent.com/webmasters/data-highlighter/RenderFrame/007....."



-Googleドメインから管理パネルにページが読み込まれます。 さらに深刻なのは、ソースドキュメント内のスクリプトや写真でさえ、プロキシを介して実行されることです。 すべてのsrc、href ...は、htmlでプロキシされたものに置き換えられます。 このようなもの：











ページが使用するすべてのリソースは、Googleプロキシにも保存されます。 Googleプロキシサーバー上のロゴの例を次に示します 。

CGIProxy？

同じことを行うには、 CGIProxyのような本格的なプロキシを作成する必要があるように思えました 。 このプロキシサーバーは、Googleのwmthighlighter.googleusercontent.comとほぼ同じことを行います。

スクリプトのURLにアクセスして、ブラウジングセッションを開始します。 プロキシ経由でページを取得すると、リンク先のすべてが自動的にプロキシを経由します。 閲覧したページをブックマークすることができ、ブックマークは最初に行ったようにプロキシを通過します。

あなたのプロキシ！

ただし、タスクを絞り込むと、単純なプロキシを作成する方が簡単です。 実際には、Googleがこの方法で行うため、すべてのページコンテンツをプロキシ経由で実行することは完全にオプションです。 ドメインのHTMLを提供するだけで、元のドメインからリソースをロードできます。 これまでに削除したHttps。

スーパーパフォーマンスや設定の利便性の目標はそれだけの価値はありません。node.jsからphpまで、何でもすばやく実行できます。 Javaでサーブレットを作成しました。

ダウンロードページ

プロキシサーブレットは何をすべきですか？ getパラメーターを使用して、ロードするページのURLを取得し、ページをダウンロードします。



必ずページのエンコーディングを決定してください（http応答またはhtmlの文字セットを使用）-プロキシは、ロードしたページと同じエンコーディングで応答する必要があります。 また、念のためにContent-Typeも定義しますが、テキスト/ htmlでページを取得し、同じ方法で提供することは明らかです。

  final String url = request.getParameter("url"); final HttpGet requestApache = new HttpGet(url); final HttpClient httpClient = new DefaultHttpClient(); final HttpResponse responseApache = httpClient.execute(requestApache); final HttpEntity entity = responseApache.getEntity(); final String encoding = EntityUtils.getContentCharSet( entity ); final String mime = EntityUtils.getContentMimeType(entity); String responseText = IOUtils.toString(entity.getContent(), encoding);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

*他の誰かのコードを評価したい人のために：私たちのチームでは誰もが同じeclicpseコードの書式設定を持ち、ファイルを保存するとき、他の場所で変更しない場合、Eclipseはすべての最終変数に追加します。 結局のところ、これは非常に便利です。

ページコードで相対URLを絶対URLに変更する

ページ内のsrcおよびhref（スタイルファイル、画像のパス）を使用してすべての属性を調べ、相対URLを絶対URLに置き換える必要があります。 そうしないと、ページはプロキシのいくつかのフォルダーから画像をダウンロードしようとしますが、これは自然には持っていません。 どの言語にも既製のクラスがあります。または、stackoverflowでこのケースのコードスニペットを見つけることができます。

  final URI uri = new URI(url); final String host = uri.getHost(); responseText = replaceRelativeLinks(host,responseText);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

htmlを送信します

これで、プロキシサーブレットの準備ができました。 目的のエンコーディングとMIMEを設定して、回答を送信します。

  protected void sendResponse(HttpServletResponse response, String responseText, String encoding, String mime) throws ServletException, IOException { response.setContentType(mime); response.setCharacterEncoding(encoding); response.setStatus(HttpServletResponse.SC_OK); response.getWriter().print(responseText ); response.flushBuffer(); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

展開とテスト

adminpanel.indexisto.com adminと同じアドレスにプロキシサーブレットをデプロイし、プロキシを介してウェブマスターのウェブサイトページをiframeにロードすると、クロスドメインの問題がすべてなくなります。

私たちのプロキシは

 http://adminpanel.indexisto.com/highlighter?url=http://habrahabr.ru
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

-これは、habrがドメインから起動する方法です。 iframeでこのアドレスを指定し、管理パネルのJSを介してHOM DOMツリーにアクセスしようとします-すべてが機能します。 Cookieを持たないプロキシからページが読み込まれるため、CSRFは当然機能しません。

SSRFの問題

アドレス「localhost」を持つサイトをiframeにロードします-おっと、ここがnginxの開始ページです。 プロキシサーバーと同じネットワーク上で内部（外部からは見えない）リソースを試してみましょう。 たとえば、secured_crm.indexisto.com-すべてが整っています。

もちろん、プロキシでこれらのことを禁止しようとします。誰かがローカルホストをプロキシしようとした場合、何も返さずに終了します：

 if (url.contains("localhost")||url.contains("127")||url.contains("highlighter")||url.contains("file")) { LOG.debug("Trying to get local resource. Url = " + url); return; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、すべてのネットワークリソースをここにリストするわけではありません。 そのため、マシンがインターネット、それ自体、およびプロキシ以外を認識しないように、プロキシを完全に隔離された環境に移動する必要があります。 車を選択し、そこでサーブレットを構成して起動します。

XSSの問題

私たちが書いたページをiframeにロードします：

 <script>alert('xss')</script>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

アラートがポップアップします。 悲しいです このiframe属性sandbox allow-scriptsを回避できますが、この属性を実際に理解していない古いブラウザーについてはどうでしょうか？ Cookieを盗むことはできますが、とにかくそのままにすることはできません。

別のマシンでサーブレットを取り出すだけでなく、別のサブドメインhighlighter.indexisto.comにします 。



到着し、クロスドメインの制限をバイパスして、独自のソリューションを破りました。 これで、iframeコンテンツに再びアクセスできなくなりました。

興味深い考え。

Googleからの解決策を継続し、別のウィンドウでプロキシを介して提供されるページを開きました







コンソールで奇妙なエラーに気づきました。

 CrossPageChannel: Can't connect, peer window-object not set.
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

組織化された方法でのすべてが、ドメインからiframeにページをロードするよりも複雑であることが明らかになりました。 ページは互いに通信します。 したがって、 window.postMessageに向かって進みます。

メッセージを投稿する

マウスでページ要素が選択されていることを確認するためにウェブマスターにスクリプトをページに挿入させ、それらの要素のxPathをpostMessageを介して親ドキュメントで送信することは人道的ではありませんでした 。 ただし、プロキシがiFrameに読み込まれたページにスクリプトを挿入するのを止める人はいません。

実装に必要なすべてのスクリプトはファイルに保存され、終了ボディの前に挿入されます：

 final int positionToInsert = responseText.indexOf("</body>"); final InputStream inputStream = getServletContext().getResourceAsStream("/WEB-INF/inject.js"); final StringWriter writer = new StringWriter(); IOUtils.copy(inputStream, writer); final String jsToInsert = writer.toString(); responseText = responseText.substring(0, positionToInsert) + jsToInsert + responseText.substring(positionToInsert, responseText.length());
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

警告の場合、警告を挿入します-すべてが機能します。

JSパート-腕の下の家の要素を強調表示し、xpathを取得します

さて、ウェブマスターのページに挿入したJSに進みます。

人がマウスを動かすdom要素を強調表示する必要があります。 要素は移動せず、ページ全体がジャンプするため、シャドウでこれを行うことをお勧めします。 私たちは体にマウスオーバーを掛け、ターゲットイベントを調べます。 同じハンドラーで、要素のxpathを計算します。 クリック時にxPath要素を計算することをお勧めしますが、このような実装ではブレーキに気付きませんでした。

 elmFrame.contentWindow.document.body.onmouseover= function(ev){ ev.target.style.boxShadow = "0px 0px 5px red"; curXpath = getXPathFromElement(ev.target); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここでは、DOM要素のxPathを取得するための実装を提供しません。 これを行う方法に関する多くのスニペットがあります。 これらのスニペットはタスクに合わせて変更できます。たとえば、xpathにはタグのみが必要です。 または、idが必要な場合はidが必要です。idがない場合はクラスが必要です。誰もが独自の要件を持っています。



次に、スクリプトが埋め込まれたHabrのハッキングされたメインページの例を示します。

http://highlighter.indexisto.com/?md5=6ec7rdHxUfRkrFy55jrJQA==&url=http%3A%2F%2Fhabrahabr.ru&expires=1390468360

JSパーツ-クリック処理

ユーザーがiframe内のページをクリックするとすぐに「消滅」します（iframe内のリンクをクリックすることはありません）。 また、受信したxPathの文字列を親ウィンドウに送信します（マウスを要素の上に置いて運転する段階でも保存しました）

 document.body.onclick = function(ev){ window.parent.postMessage( curXpath, "*"); ev.preventDefault(); ev.stopPropagation(); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

利益！

これですべてです。管理パネルでは、ウェブマスターがページ上の要素へのxpathパスをすばやく簡単に取得できるようになりました。

セキュリティ機能を追加する

さて、すべてが私たちのために働いたが、私たちのプロキシが完全に安全でない世界を見ているという事実とのポイントがあります。 誰でも何でも宣言できます。



nginxをプロキシの前に置き、ポート80をリッスンし、別のポートへのプロキシを削除します。 80を除く他のすべてのポートは、外界から閉鎖されています。



ここで、管理パネルからのみプロキシを機能させましょう。 Webマスターが自分のサイトのURLを入力した瞬間、サーバーにすばやく実行され、現在のTimeStamp + 1時間からURL自体とスーパーシークレットからmd5ハッシュが生成されます。

  final String md5Me = timeStampExpires + urlEncoded + "SUPERSECRET"; final MessageDigest md = MessageDigest.getInstance("MD5"); md.reset(); md.update(md5Me.getBytes("UTF-8")); String code = Base64.encodeBase64String(md.digest()); code = code.replaceAll("/", "_"); code = code.replaceAll("\\+","-");
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

また、コードでは通常の16進数とは異なりmd5行を取得しますが、base64エンコーディングでは、結果のmd5で、スラッシュとプラス記号にアンダースコアとダッシュを使用した奇妙な置換を行います。

実際、ngnixはbase64ファイル名セーフアルファベットtools.ietf.org/html/rfc3548#page-6を使用している

また、Javaは標準のbase64を提供します。



管理パネルのセキュリティmd5を使用してサーバーから応答を受信した後、次のURLをiframeにロードしようとしています。

highlighter.indexisto.com/?md5=Dr4u2Yeb3NrBQLgyDAFrHg==&url=http%3A%2F%2Fhabrahabr.ru&expires=1389791582



nginxモジュールHttpSecureLinkModuleを構成します。 このモジュールは、それに来たすべてのパラメーターのmd5をチェックし（adminサーブレットと同じ秘密キーがモジュールに登録されています）、リンクが削除されたかどうかをチェックし、この場合のみリクエストをプロキシサーブレットに転送します。



これで誰も管理領域外からプロキシを使用できなくなり、またどこかにサーバーにプロキシされた画像を挿入することもできなくなります-とにかく1時間で死にます。

それはすべての人々です！

Googleは当然、マーカーツールを使用してさらに大きく前進しました。 ページ上の要素を明確に識別するには、同じタイプの複数のページで同じ要素（記事のタイトルなど）をマークする必要があります。これにより、xpathをより正確に構築し、明らかに1ページのみで機能する「post-2334」の異なるidタイプをドロップできます。 管理パネルでは、許容できる結果を得るためにxpathを手で修正する必要があります