30

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

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

  • fakebank.com/withdrawForm.html- 出金フォームを表示する GET リクエスト
  • fakebank.com/doWithdraw- この URL に POST して、引き出しを行います

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

に秘密のコードを埋め込む Synchronizer Token Pattern を実装するとしましょうfakebank.com/withdrawForm.html。maliciousSite.comそのフォームの GET リクエストをスプーフィングし、html の結果を解析し、トークンを取得して、そのトークンを使用して POST リクエストを作成することはできませんか?

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

4

2 に答える 2

28

これが安全であり、単純に を実行してトークンを盗んでから をmaliciousSite.com実行できない理由は、要求が のサーバーではなく、ユーザーのブラウザによって行われるためです。から返されるすべてのデータは、 のサーバーではなく、ユーザーのブラウザに返されます。トークンを取得するために GET を実行すると、ユーザーに発行されたものとは異なるトークンになります 。同一ドメイン制限のため、 送信先のユーザーのブラウザーにこの Cookie を設定することはできません。GETPOSTmaliciousSite.comfakebank.commaliciousSite.commaliciousSite.commaliciousSite.comfakebank.com

CSRF攻撃は、適切な形式のリクエストを使用して直接POSTリクエストするようにユーザーのブラウザを騙すことによって機能します。サーバーはリクエストされた を喜んで実行し、本体で提供されたパラメータを使用して資金を送金します(これには、攻撃者が所有する宛先アカウントが含まれます)。のサーバーは、アクションが実行されているため、返されたデータを確認する必要はありません (これらの CSRF トークンを使用しない限り、何らかの方法で漏洩しない限り知ることはできません。それを要求することはできません)。 . が CSRF トークンを使用している場合は、トークンが欠落しているリクエストを 送信するため、進行中の潜在的な CSRF 攻撃を示します。fakebank.com/withdrawForm.htmlPOSTfakebank.comPOSTPOSTmaliciousSite.commaliciousSite.comfakebank.commaliciousSite.comfakebank.commaliciousSite.comPOST

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

説明が不十分な場合はお知らせください。もう少しわかりやすく説明できるように努めます。

于 2013-04-17T02:25:52.250 に答える