web-dev-qa-db-ja.com

シンクロナイザートークンパターンを使用してCSRFを安全に防ぐにはどうすればよいですか？

シンクロナイザートークンパターンを使用してCSRF（CSRFはクロスサイトリクエストフォージェリを意味します）を防ぐことについて読んでいますが、実際にどのように安全であるかわかりません。

2つのURLを持つ偽の銀行サイトfakebank.comがあるとしましょう。

  • fakebank.com/withdrawForm.html-出金フォームを表示するGETリクエスト
  • fakebank.com/doWithdraw- POSTこのURLに撤回を行う

セキュリティ上の欠陥についての私の理解は、maliciousSite.comがPOSTリクエストをfakebank.com/doWithdrawにスプーフィングする可能性があることです。現在、fakebankにログインしている場合、POSTは成功します。

fakebank.com/withdrawForm.htmlにシークレットコードを埋め込むシンクロナイザートークンパターンを実装するとします。 maliciousSite.comは、そのフォームのGETリクエストをスプーフィングし、htmlの結果を解析してトークンを取得し、そのトークンを使用してPOSTリクエストを作成することはできませんか？

これは、fakebank.comがHTTPリファラーまたはオリジンをチェックしていないか、maliciousSite.comがリファラー/オリジンがfakebank.comであることをスプーフィングしていることを前提としています。

javascriptsecuritywebcsrf
24
Juliet

これが安全であり、maliciousSite.comが単にGETを実行してトークンを盗み、次にPOSTを実行できない理由は、リクエストがユーザーのブラウザによって行われるためであり、 maliciousSite.comのサーバーによって。 fakebank.comから返されるすべてのデータは、maliciousSite.comのサーバーではなく、ユーザーのブラウザに返されます。 maliciousSite.comがGETを実行してトークンを取得する場合、それはユーザーに発行されたものとは異なるトークンになります。 maliciousSite.comは、同じドメインの制限のため、このCookieをユーザーのブラウザに設定してfakebank.comに送信することはできません。

CSRF POST攻撃は、適切に形成されたPOSTリクエストを使用して、ユーザーのブラウザをだましてfakebank.com/withdrawForm.htmlを直接リクエストさせることで機能します。 fakebank.comのサーバーは、要求されたPOSTを正常に実行し、POST本体で提供されたパラメーター（攻撃者が所有する攻撃者に属する宛先アカウントを含む）を使用して資金を転送します。 maliciousSite.com）。 maliciousSite.comのサーバーは、アクションが実行されたため、返されたデータを確認する必要はありません（fakebank.comがこれらのCSRFトークンを使用しない限り、maliciousSite.comはそれがないとわからない可能性があります）何らかの方法で漏えいしました。それを求めることはできません）。 fakebank.comがCSRFトークンを使用している場合、maliciousSite.comはトークンが欠落しているPOSTリクエストを送信するため、CSRF攻撃が進行中である可能性があります。

この方法の脆弱性には、十分に秘密にされておらず、何らかの方法で漏えいしているCSRFトークンの使用が含まれます。また、CSRFトークンが十分にランダムでない場合、maliciousSite.comはそれを推測できる可能性があります。また、ブラウザによる同一ドメインポリシーの適用に弱点がある場合、これが悪用される可能性があります。一般的に言って、最近のブラウザはこれに対して脆弱ではありません。

これが不十分な説明である場合はお知らせください。もう少しわかりやすく説明します。

23
Freedom_Ben

そしてそれがまさにポイントです。ブラウザの 同一生成元ポリシー は他のサイトへの[〜＃〜] get [〜＃〜]リクエストを許可しません。したがって、ブラウザ内でJavasciptを使用するだけで、別のサイトからCSRFトークンを取得できるサイトはありません。

3
deceze