Web UI フレームワークのセキュリティー - クロスサイト要求偽造

Web UI フレームワークは、クロスサイト要求偽造 (CSRF) からアプリケーションを保護します。CSRF は、 Web サイトを悪用して、Web サイトが信頼するユーザーから許可されていないコマンドを送信します。 CSRF (XSRF とも呼ばれる) は、ユーザーが特定のサイトに対して持っている信頼を悪用する、クロスサイト・スクリプティング (CSS または XSS) とは異なります。 CSRF は、ワンクリック・アタック、サイド・ジャッキング、またはセッション・ライディングとも呼ばれます。

CSRF は、ユーザーに認証済みとして認識 (または、想定) されているサイトにアクセスするページに、リンクまたはスクリプトを組み込むことによって機能します。 例えば、ユーザー A が、ユーザー B がメッセージを投稿済みのフォーラムをブラウズしているとします。 CSRF を使用して、ユーザー B が次のような HTML イメージ・エレメントを作成すると、これはイメージ・ファイルになるのではなく、ユーザー A の銀行の Web サイトにあるスクリプトを参照し、$1,000,000 の引き出しを要求します。

<img src="http://bank.example/withdraw?amount=1000000&for=USER-B">

ユーザー A の銀行が認証情報を Cookie に保持し、その Cookie が期限切れになっていない場合、ユーザー A のブラウザーがイメージをロードしようとすると、認証 Cookie と一緒に引き出しフォームが送信され、ユーザー A の承認なしに取引が許可されます。

このシナリオでは、問題は、以下の 3 つのポイントに要約できます。
  • ブラウザーのポリシーにより、要求が別の Web サイトから発信されていても、認証 Cookie は銀行のサーバーに送信される。
  • ユーザー A の銀行は、認証情報を Cookie に保管し、認証の目的で完全に Cookie に依存している。
  • ユーザー A の銀行は、GET 要求と POST 要求とを区別していない。
Web UI フレームワークの CSRF 保護は 1 点目には適用されません。なぜなら、それはブラウザー・ポリシーであるためです。 しかし、認証に Cookie と追加トークンの両方を使用することにより、2 番目と 3 番目のポイントには適用されます。 サーバーにヒットする各要求内の固有のトークンを常に確認することにより、通常は CSRF 攻撃を防ぐことができます。 Web UI フレームワークでは、トークンは以下のように使用されます。
  1. ログインが完了すると、そのセッションに対して (検証の目的で) 新規作成のトークンが設定されます。 このトークンは、アプリケーションのクライアント・サイドで利用可能です。
  2. トークンは、以下の方法で使用されます。
    • このトークンは、すべての AJAX 要求に対して使用され、Web UI フレームワーク・ユーティリティー内にあります。
    • サーバーに対して POST 要求または GET 要求が行われると、アプリケーションはその要求内で CSRF トークンが使用可能であることを自動的に検証します。