1)ユーザーは、すべてがCSRFトークンによって保護されている1つのタブでbank.comにログインしています。次に、別のタブでevil.comを開きます。
2)evil.comのJavascriptは、csrf_tokenを知っている場合にのみ、bank = com/send_moneyにPOSTリクエストを送信しようとする可能性があります。
3)csrf_tokenを明らかにするために、evil.comのJavaScriptは、bank.com/send_moneyに対してGET ajax呼び出しを実行して、ブラウザーでこのページにアクセスすることで取得するのとまったく同じhtmlユーザーを取得しようとする場合があります。そして、トークンを読み取ります。
質問-なぜ最後のステップが失敗し、常に失敗するのですか?
私が理解している限り、bank.comは実際にこのリクエストに応答してすべてのhtmlを適切にレンダリングしますが、クライアント側では、ブラウザは別のドメインからのコンテンツにアクセスできないように決定するため、失敗します。
Evil.comからbank.com/send_moneyへのiframeがある場合、iframeはすべてのhtmlを正常にロードしますが、ブラウザはこのhtmlをJavaScriptで使用できず、iframeでのみ表示できると判断します。したがって、JSはトークンを取得できず、POSTリクエストを実行できません。
それが正しいか?これはだまされますか?
same-Originポリシー が原因で、JavaScriptは他のサイトのコンテンツを読み取ることができません。
これはWebセキュリティの最も基本的な原則の1つであり、CSRF保護をはるかに超えています。同じ起源のポリシーがなければ、どのウェブサイトでもウェブメーラーを介して電子メールを読んだり、Paypalアカウントを確認したり、Facebookから個人情報を入手したりすることができます。そのため、ブラウザーベンダーはこれを防ぐために多くの努力をしています。
すべてのセキュリティメカニズムと同様に、バグがある可能性があります。そして DNS rebinding と呼ばれる特定の攻撃もあります。しかし、全体として、同じ起源のポリシーは非常にうまく機能し、簡単に打ち負かすことはできません。