安全なウェブサイトの作り方 - 1.6 CSRF（クロスサイト・リクエスト・フォージェリ）

概要

ウェブサイトの中には、サービスの提供に際しログイン機能を設けているものがあります。ここで、ログインした利用者からのリクエストについて、その利用者が意図したリクエストであるかどうかを識別する仕組みを持たないウェブサイトは、外部サイトを経由した悪意のあるリクエストを受け入れてしまう場合があります。このようなウェブサイトにログインした利用者は、悪意のある人が用意した罠により、利用者が予期しない処理を実行させられてしまう可能性があります。このような問題を「CSRF（Cross-Site Request Forgeries／クロスサイト・リクエスト・フォージェリ）の脆弱性」と呼び、これを悪用した攻撃を、「CSRF攻撃」と呼びます。

発生しうる脅威

CSRF攻撃により、発生しうる脅威（脚注1）は次のとおりです。

ログイン後の利用者のみが利用可能なサービスの悪用: 不正な送金、利用者が意図しない商品購入、利用者が意図しない退会処理等

ログイン後の利用者のみが編集可能な情報の改ざん、新規登録: 各種設定の不正な変更（管理者画面、パスワード等）、掲示板への不適切な書き込み等

注意が必要なウェブサイトの特徴

次の技術を利用してセッション管理を実装しているウェブサイトが、CSRF攻撃による影響を受ける可能性があります。

Cookieを用いたセッション管理
Basic認証
SSLクライアント認証

また、上記を実装するウェブサイトのうち、ログイン後に決済処理等の重要な処理を行うサイトは、攻撃による被害が大きくなるため、特に注意が必要です。

金銭処理が発生するサイト: ネットバンキング、ネット証券、ショッピング、オークション等

その他、ログイン機能を持つサイト: 管理画面、会員専用サイト、日記サイト等

届出状況

CSRFの脆弱性に関する届出が、ウェブサイトの届出全体に占める割合は、1パーセント未満と多くはありません。しかしながらこれらの脆弱性については、ソフトウェア製品の届出を含め、2006年頃から継続的に届出を受けています。届出の報告内容としては、ネットワーク対応ハードディスク等、組み込み製品のウェブ管理画面に同脆弱性が存在する例等があります。下記は、IPAが届出を受け、同脆弱性の対策が施されたソフトウェア製品の例です。

根本的解決

6-(i)-a 処理を実行するページをPOSTメソッドでアクセスするようにし、その「hiddenパラメータ」に秘密情報が挿入されるよう、前のページを自動生成して、実行ページではその値が正しい場合のみ処理を実行する。

ここでは具体的な例として、「入力画面 → 確認画面 → 登録処理」のようなページ遷移を取り上げて説明します。まず、利用者の入力内容を確認画面として出力する際、合わせて秘密情報を「hidden パラメータ」に出力するようにします。この秘密情報は、セッション管理に使用しているセッションIDを用いる方法の他、セッションIDとは別のもうひとつのID（第2セッションID）をログイン時に生成して用いる方法等が考えられます。生成するIDは暗号論的擬似乱数生成器を用いて、第三者に予測困難なように生成する必要があります。次に確認画面から登録処理のリクエストを受けた際は、リクエスト内容に含まれる「hiddenパラメータ」の値と、秘密情報とを比較し、一致しない場合は登録処理を行わないようにします（脚注2）。このような実装であれば、攻撃者が「hiddenパラメータ」に出力された秘密情報を入手できなければ、攻撃は成立しません。

なお、このリクエストは、POSTメソッドで行うようにします（脚注3）。これは、GET メソッドで行った場合、外部サイトに送信されるRefererに秘密情報が含まれてしまうためです。

6-(i)-b 処理を実行する直前のページで再度パスワードの入力を求め、実行ページでは、再度入力されたパスワードが正しい場合のみ処理を実行する。

処理の実行前にパスワード認証を行うことにより、CSRFの脆弱性を解消できます（脚注4）。ただし、この方法は画面設計の仕様変更を要する対策であるため、画面設計の仕様変更をせず、実装の変更だけで対策をする必要がある場合には、6-(i)-a または 6-(i)-c の対策を検討してください。

この対策方法は、上記 6-(i)-a と比べて実装が簡単となる場合があります。たとえば、セッション管理の仕組みを使用しないでBasic認証を用いている場合、6-(i)-a の対策をするには新たに秘密情報を作る必要があります。このとき、暗号論的擬似乱数生成器を簡単には用意できないならば、この対策の方が採用しやすいと言えます。

6-(i)-c Refererが正しいリンク元かを確認し、正しい場合のみ処理を実行する。

Refererを確認することにより、本来の画面遷移を経ているかどうかを判断できます。Refererが確認できない場合は、処理を実行しないようにします（脚注5）。またRefererが空の場合も、処理を実行しないようにします。これは、Refererを空にしてページを遷移する方法が存在し、攻撃者がその方法を利用して CSRF 攻撃を行う可能性があるためです。

ただし、ウェブサイトによっては、攻撃者がそのウェブサイト上に罠を設置することができる場合があり、このようなサイトでは、この対策法が有効に機能しない場合があります。また、この対策法を採用すると、ブラウザやパーソナルファイアウォール等の設定でRefererを送信しないようにしている利用者が、そのサイトを利用できなくなる不都合が生じる可能性があります。本対策の採用には、これらの点にも注意してください。

保険的対策

6-(ii) 重要な操作を行った際に、その旨を登録済みのメールアドレスに自動送信する。

メールの通知は事後処理であるため、CSRF 攻撃を防ぐことはできません。しかしながら、実際に攻撃があった場合に、利用者が異変に気付くきっかけを作ることができます。なお、メール本文には、プライバシーに関わる重要な情報を入れない等の注意が必要です。

以上の対策により、CSRF攻撃に対する安全性の向上が期待できます。CSRFの脆弱性に関する情報については、次の資料も参考にしてください。

脚注

(脚注1)

前述「1.4セッション管理の不備」における脅威と比較してみると、攻撃者は、「ログインした利用者のみが閲覧可能な情報」を閲覧することができない、という違いがあると言えます。ただし、「パスワード変更」のように、次の攻撃（なりすまし）に繋がる攻撃が成功した場合には、情報漏えいの脅威も発生する可能性があります。
(脚注2)

3.6の修正例1を参照。(PDF:2.2 MB)
(脚注3)
HTTP/1.1の仕様を定義しているRFC2616には、「機密性の求められるデータの送信にはGETメソッドを使わず、POSTメソッドを使うべきである」という内容の記述があります（15.1.3 Encoding Sensitive Information in URI's）。
- RFC2616：「Hypertext Transfer Protocol -- HTTP/1.1」
(脚注4)

3.6の修正例2を参照。(PDF:2.2 MB)
(脚注5)

3.6の修正例3を参照(PDF:2.2 MB)