CSRFとは？

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

• XSSのようにセッションIDが盗聴されてユーザー権限を使われて嫌がらせされるのだろう
• 利用者が意図したリクエストであるかどうかを識別するとは？

発生しうる脅威

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

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

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

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

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

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

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

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

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

• ほとんどのサイトに注意が必要だ。

根本的解決

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

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

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

• hiddenパラメータとは？
• 秘密情報とhiddenのvalueが同じであればリクエストが完了する
• hiddenパラメータは盗聴されないのか?

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を送信しないようにしている利用者が、そのサイトを利用できなくなる不都合が生じる可能性があります。本対策の採用には、これらの点にも注意してください。

• Refererとは？
• ウェブサイトに罠を張り6-(i)-cの対策が作動しないこともある
• ユーザーが使うブラウザやパーソナルファイアウォール等の設定でRefererを送信しない設定にするとRefererを使って判断するサイトを使用できない

保険的対策

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

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

hiddenパラメータとは？

Refererとは？

hiddenパラメータは盗聴されないのか?

メモ: 前述のように、隠し入力欄に秘密を配置することは、本質的に安全ではありません。鍵の組み合わせやエンコーディングによって実現すべきものです。隠し入力欄の値は秘密とデータを関連付け、フォームがサーバーに送信されるときに自動的に含められます。本当にウェブサイトを安全にするには、よく設計された秘密を使用する必要があります。

リクエストのパラメータでもhiddenは表示される

title=My+excellent+blog+post&content=This+is+the+content+of+my+excellent+blog+post.+I+hope+you+enjoy+it!&postId=34657

• 秘密が大事

感想

• hiddenの値をどういう設計をするかが重要
• 再度パスワードを要求する方法は比較的簡単
• Refererの対策は注意が必要
• basic認証とは？