web-dev-qa-db-ja.com

IFrameの脆弱性の分類

非常に奇妙なEdgeのケースに遭遇したとき、私が_example.com_と呼ぶWebサイトのバグ報奨金に参加していました。このWebサイトでは、_tracking.com_と呼ぶことができるWebサイトのGoogleアナリティクスと同様の広告とトラッキングを使用しています。サンプルWebサイトにアクセスすると、追跡Webサイトへのiframeがあります。 iframeのソースを以下に示します。

_<body>
<script type="text/javascript">
     ((function (e, t)
     {

          var n = function () {
               var e = t.createElement("iframe");
               e.src = "https://tracking.com/container/?utm_source=[INJECT];
               e.style.cssText = "position: absolute";
               t.body.appendChild(e)
          }

          if (t.readyState === "complete")
          {
               n()
          }
          else
          {
               if (typeof e.addEventListener !== "undefined")
               {
                    t.addEventListener("DOMContentLoaded", n, false)
               }
               else
               {
                    e.attachEvent("onload", n, false)
               }
          }
     })(window, document));
</script>
</body>
_

サンプルWebサイトには、_utm_source_というパラメーターもあります。このパラメーターには、JavaScriptをiframeに挿入できます（上記のコードで[INJECT]を配置した場所）。たとえば、https://example.com/?utm_source=";</script><script>alert(document.domain)</script>にアクセスすると、アラートが生成されますtracking.comに埋め込まれたページには、tracking.comと表示されます。問題は、追跡Webサイトがバグ報奨金の対象外であり、追跡Webサイトが問題の原因であるかどうかさえわからないことです。例のWebサイトでは、ユーザーが任意のJSを追跡Webサイトのiframeに挿入できるようです。これは報告する価値のあるバグですか、それともiframeをエスケープする簡単な方法がありませんか？

これまでのところ、iframeをエスケープするために_</iframe>_およびe.onload=alert(1)などのインジェクションを試みましたが、成功していません。サンプルとトラッキングWebサイトは異なるドメインにあるので、「X-Frame-Options」ヘッダーが「SAMEORIGIN」に設定されているため、トラッキングWebサイトから親Webサイト（例）にアクセスできません。

初心者として、このバグはそれをどのように分類すべきか、そしてそれが何らかの方法で悪用可能かどうかについて私を非常に混乱させています。ヒントがあれば大歓迎です！

xssexploitjavascripthtmliframe
1
Michael Hoefler

説明から、_example.com_はユーザー指定の値を適切に処理しているようです（つまり、指定されたscript/_e.src_に注入していないため、試行した理由はt work）。 _example.com_のDOMを調べて、これを確認できます。

代わりに、_example.com_は値を文字列として適切に処理し、_tracking.com_に渡します。これにより、安全に処理されません（_https://tracking.com/container/?utm_source=[INJECT]_に直接アクセスすることでこれを確認できますが、範囲外であるため） 、私はそれを回避しようとします; _tracking.com_で誤ってトリガーしたことによるHTTPログがまだある場合は、それらをチェックすることができます）。

上記を前提として、_tracking.com_が他の方法で_example.com_によって信頼されていない（たとえば、興味深いポストメッセージ、CORSなどを受け入れるまたは送信する）と仮定すると、SOPほとんどの悪意のあるアクションを防ぎます。

残されたものは、フレームインジェクションと呼ばれます。それは可能かもしれません：

  • _example.com_が_tracking.com_をフレーム化するページに機密性の高いGETパラメータを持ち、これらを保護する対策を講じていない場合、それらをログに記録できる可能性があります。
  • 一部のクリックジャッキング保護をバイパスできる場合があります（ こちら を参照）。
  • _example.com_を介して_top.location.href="http://www.evil.com";_から離れることができる場合があります（タブナビゲートと同様）
  • _tracking.com_（改ざん）からの広告の代わりに独自のコンテンツを挿入できます。
  • this.focus();を介して_example.com_からフォーカスを盗み、不注意なユーザーから機密情報を傍受する目的でユーザーのキーストロークをログに記録できる場合があります（機能する場合、_example.com_の操作性に影響します）。したがって、これは非常にノイズの多い攻撃であり、アプリケーションレベルのDOSが少し投入されます）。

これらのいずれかをテストする場合は、_tracking.com_へのトラフィックを_/etc/hosts_を介して制御するホストにリダイレクトし、スコープ外のドメインにさらにヒットしないようにします。

これを_example.com_に報告するかどうかは、プログラムに大きく依存します。一部はおそらく範囲外（_tracking.com_は脆弱なサイトです）または有益な情報（例：タブを操作する影響の例）であると考えるでしょう。ただし、_example.com_への影響を示すことができ、特に_example.com_がそれ自体をどのように防ぐことができるか（リファラーリークを防ぐなど）を示すことができる場合は、試してみる価値があります。

1
tim