English
アーカイブ
第4章 1.リクエスト強要（CSRF）対策
公開日：2007年6月28日
独立行政法人情報処理推進機構
セキュリティセンター
本ページの情報は2007年6月時点のものです。
記載の資料は資料公開当時のもので、現在は公開されていないものも含みます。
リクエスト強要（CSRF）
リクエスト強要（CSRF：Cross-site Request Forgery）とは、別のサイトに用意したコンテンツ上の罠のリンクを踏ませること等をきっかけとして、インターネットショッピングの最終決済や退会等Webアプリケーションの重要な処理を呼び出すようユーザを誘導する攻撃である。
ブラウザが正規の Webコンテンツにアクセスした際には毎回、セッションを維持するために所定の Cookie、Basic認証データあるいは Digest認証データがブラウザから Webサーバ宛に送出されるという性質を、この攻撃は悪用する。
ユーザの意図に反することを検証できないWebアプリケーション
この攻撃の対象となるのは、トランザクション投入のきっかけとなったフォーム画面が自サーバから供給（POST）されたものであることを確認していない Webアプリケーションである。言い換えれば、ブラウザから自動的に得られる情報のみに基づいてユーザやセッションを識別しているナイーブな Webアプリケーションである。このような Webアプリケーションは、ユーザの意図に反してリクエストが送出されたことを検証できない。
具体的には次のようなWebアプリケーションが対象となる。
- Cookieを用いてセッションIDを搬送している Webアプリケーション
- Basic認証を用いているWebアプリケーション
- Digest認証を用いているWebアプリケーション
- そのほかWebクライアントから自動で得られる情報にもとづきユーザやセッションを識別しているWebアプリケーション
参考：
リクエスト強要（CSRF）のメカニズム
攻撃対象とは別の Webサーバに罠のリンクが用意される。ユーザがその罠を踏んで、攻撃手段が仕込まれる。
Cookieをはじめとする認証データ、識別データは、HTTPリクエストの対象コンテンツ（「目的地」）が正規のものでありさえすれば、Webアプリケーションが用意したものでない偽のフォームやハイパーリンク（「偽の出発地」）から発せられたものであっても送出される。例えば、Cookieを用いてセッション管理を行っている Webアプリケーションの場合、ブラウザから自動送出される Cookieに WebセッションIDを搭載し、サーバがそのIDを見て個々のブラウザを識別している。
-
図4-1： リクエスト強要（CSRF）
特段の対策がとられていない Webアプリケーションは、HTTPリクエストに伴って送られてきたCookieに正規のセッションIDが入っていさえすれば、そのリクエストが受け入れて、ユーザ本人の意志に反した処理を行ってしまうおそれがある。
特に、ユーザがログイン中に攻撃されると、ログイン後にしか操作しないような重要なトランザクションを送ってしまうことになる。（注： この攻撃の構図は、ユーザがログインしていることを要さない画面のフォームについても成立しうる。）
リクエスト強要（CSRF）対策
リクエスト強要（CSRF）への対策は、ユーザ本人以外の者が捏造（ねつぞう）したコンテンツに基づいて発せられたHTTPリクエストを Webアプリケーションが受け付けないようにすることである。
そのためには、代金決済やコミュニティ脱退等の重要な処理の場面において、秘密の「照合情報」をWebアプリケーションとブラウザの間でやりとりし、第三者が用意した偽のコンテンツから発せられたリクエストを区別できるようにする。
具体的には、フォームを表示するプログラムによって他者が推定困難なランダム値を hiddenフィールドとして埋め込み送信し、フォームデータを処理するプログラムによってそのランダム値がフォームデータ内に含まれていることを確認する。
そのランダム値がフォ－ムデータに含まれていない場合、処理を見合わせるようにする。
照合情報
照合情報には、他者が推測困難な値を用いる。そのような値として下記の 3つが挙げられる。
- セッションIDそのもの もしくは セッションIDから導かれるハッシュ値 等
- セッション開始時に一度生成され各ページで使われる、セッションIDとは無関係の値
- ページごとに生成される、毎回異なる値（ページトークン）
ただし、最近ではページトークンを自動生成してくれるWebアプリケーションフレームワークも珍しくなくなってきている。そのようなフレームワークを使う場合、わざわざ「セッションIDそのもの」や、その派生値を選択する必要はない。
照合情報の検証においては、実際に値を「照合」する。例えば、特定のアルゴリズムが満足させられることをもって適正と判断する方式では、攻撃者が自分自身に宛てて発行された照合用情報を罠の中に仕込むことによって対策を迂回することができてしまう。
フレームワークの選択
フォームへの照合情報の埋め込みを自動的に行う Webアプリケーションフレームワークがあり、増えつつある。（例： Ruby on Rails、 Grails、CakePHP 等）
このような Webアプリケーションフレームワークが選択されている場合、その照合情報の埋め込み機能が有効となるように設定し、照合情報の検証を行う
TLSの使用
リクエスト強要（CSRF）対策に用いる照合情報は、他者に傍受されると都合が悪い。また、リクエスト強要（CSRF）対策が必要となる場面においては、ユーザやWebアプリケーションにとって重要なデータが送受信されることが十分考えられる。したがって、この場面においては、TLS（Transport Layer Security）の使用が不可欠である。