レガシー・プラットフォーム

クロスサイト・リクエスト・フォージェリー

オンラインで編集

基礎のフレームワークには、クロスサイト・リクエスト・フォージェリー (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 要求とを区別していない。
基礎フレームワークの CSRF 保護は、最初のポイントには適用されません。これは、ブラウザーのポリシーであるからです。 しかし、認証に Cookie と追加トークンの両方を使用することにより、2 番目と 3 番目のポイントには適用されます。 サーバーにヒットする各要求内の固有のトークンを常に確認することにより、通常は CSRF 攻撃を防ぐことができます。 基礎フレームワークでは、トークンは次のような方法で使用されています。
  1. ログインが完了すると、そのセッションに対して (検証の目的で) 新規作成のトークンが設定されます。 このトークンは、アプリケーションのクライアント・サイドで利用可能です。
  2. トークンは、以下の方法で使用されます。
    • このトークンが、すべての AJAX 要求および基礎フレームワークのユーティリティー内で使用されます。
    • サーバーに対して POST 要求または GET 要求が行われると、アプリケーションはその要求内で CSRF トークンが使用可能であることを自動的に検証します。