クロスサイトリクエストフォージェリ（CSRF）【情報処理安全確保支援士試験令和6年度春期午前Ⅱ 問1】

情報処理安全確保支援士試験令和6年度春期午前Ⅱ 問1

クロスサイトリクエストフォージェリ攻撃の対策として、効果がないものはどれか。

ア　Webサイトでの決済などの重要な操作の都度、利用者のパスワードを入力させる。
イ　Webサイトへのログイン後、毎回異なる値をHTTPレスポンスボディに含め、Webブラウザからのリクエストごとに送付されるその値を、Webサーバ側で照合する。
ウ　Webブラウザからのリクエスト中のRefererによって正しいリンク元からの遷移であることを確認する。
エ　WebブラウザからのリクエストをWebサーバで受け付けた際に、リクエストに含まれる”<“、”>”などの特殊文字を、”<”、”>”などの文字列に書き換える。

情報処理安全確保支援士やネットワークスペシャリストの資格取得を目指す皆さんにとって、Webセキュリティは避けて通れない重要なテーマですよね。今回は、数あるサイバー攻撃の中でも特に巧妙で、対策が難しいとされているクロスサイトリクエストフォージェリ（CSRF）について、皆さんがしっかり理解できるように、詳しく解説していきます！

クロスサイトリクエストフォージェリ（CSRF）って、なに？

まず、「クロスサイトリクエストフォージェリ」って、なんだか舌を噛みそうな名前ですよね（笑）。略してCSRF（シーサーフ）と呼ばれることが多いです。

簡単に言うと、CSRFは「Webサイトにログインしているユーザーの権限を悪用して、意図しない操作を実行させる攻撃」のことです。

「え？ログインしてるのに、勝手に操作されちゃうの？」そうなんです。これだけ聞くと、ちょっと怖いですよね。

もう少し具体的に説明します。あなたが、とあるWebサイトにログインして操作しているとします。そのWebサイトでは、例えば「商品の購入」や「パスワードの変更」といった重要な操作が可能です。

CSRF攻撃者は、この「ログインしている」という状態を悪用します。悪意のあるWebサイトやメールに、あなたを誘導し、そこに仕込まれた「罠」によって、あなたがログインしているWebサイトに対して、意図しないリクエストを送信させてしまうんです。

なぜCSRFは起こるの？背景と経緯

CSRF攻撃が成立してしまう背景には、Webの基本的な仕組みが関係しています。

Webブラウザは、一度ログインしたサイトに対しては、そのログイン情報（セッション情報など）を自動的に送信します。これによって、ユーザーは毎回ログイン情報を入力しなくても、Webサイトを快適に利用できます。

この便利な仕組みを悪用するのがCSRFです。

悪意のあるサイトにアクセスした際に、そのサイトに埋め込まれたスクリプトなどが、あなたがログイン中の別のサイトへリクエストを送る際、ブラウザは「ログイン中だから、このリクエストは信頼できるだろう」と判断し、セッション情報も一緒に送信してしまいます。これが、CSRFの主な発生要因なんです。

この手の攻撃は、Webが普及し始めた初期から存在していましたが、当時はあまり注目されていませんでした。しかし、Webアプリケーションの複雑化と、それに伴うユーザーのログイン状態の保持が一般的になるにつれて、CSRFはより深刻な脅威として認識されるようになりました。特に、2000年代後半から、その危険性が広く知られるようになり、対策の重要性が叫ばれるようになりました。

恐ろしいCSRFの具体事例

CSRFがどのように悪用されるのか、具体的な例を挙げてみましょう。

ECサイトでの意図しない購入
あなたがよく使うECサイトにログインしている状態で、攻撃者が用意した悪意のあるページを開いてしまったとします。そのページには、「あなたのログイン中のECサイトで、高額な商品を購入する」というリクエストが隠されているかもしれません。あなたは何も操作していないのに、商品が購入されてしまう…なんてことが起こりえます。
インターネットバンキングでの不正送金
これも恐ろしい事例です。もし、あなたがインターネットバンキングにログインしている最中に、CSRF攻撃を受けてしまったら、攻撃者が指定する口座へ勝手に送金されてしまう可能性があります。もちろん、多くの金融機関では厳重なセキュリティ対策が施されていますが、原理的にはこのような攻撃も可能です。
SNSでの勝手な投稿や設定変更
SNSにログイン中にCSRF攻撃を受けると、意図しない投稿がされたり、プロフィール情報が変更されたりする可能性があります。例えば、「スパムメッセージを投稿する」といった悪用も考えられます。

これらの事例は、すべて「ユーザーが意図しない操作」が、ユーザー自身がログインしている状態で実行されてしまうという点が共通しています。

CSRF対策はどうすればいいの？

さて、ここが皆さんが一番知りたいところですよね！CSRFから身を守るための対策はいくつかあります。

1. CSRFトークンの導入（これが一番重要！）

最も効果的なCSRF対策として広く用いられているのが、CSRFトークンの導入です。

これは、Webアプリケーションがユーザーごとに一意の「秘密の文字列（トークン）」を生成し、それをフォームなどに埋め込んでおくという仕組みです。

ユーザーがフォームを送信する際には、このトークンも一緒にサーバーに送られます。サーバー側では、受け取ったトークンが、事前に発行したトークンと一致するかどうかを検証します。

正規のアクセスの場合
ユーザーがブラウザで正規の操作をすると、正しいトークンが送信され、処理が実行されます。
CSRF攻撃の場合
攻撃者は、この秘密のトークンを知ることができません。そのため、攻撃者が作成した偽のリクエストには、正しいトークンが含まれていません。サーバーはトークンの不一致を検知し、不正なリクエストとして処理を拒否します。

このCSRFトークンは、その名の通り「改ざん防止の印」のような役割を果たします。多くのWebフレームワークには、このCSRFトークンを簡単に導入できる機能が備わっていますので、積極的に活用しましょう。

2. Refererヘッダの確認

Webブラウザは、HTTPリクエストを送信する際に、そのリクエストがどのページから来たのかを示すRefererヘッダという情報を一緒に送ります。

Webアプリケーション側で、このRefererヘッダをチェックし、自サイト以外からのリクエストであれば拒否するという方法もCSRF対策として有効です。

ただし、Refererヘッダはユーザーのプライバシー設定によっては送信されない場合があるため、CSRFトークンと比べると信頼性はやや劣ります。補助的な対策として位置づけるのが良いでしょう。

3. SameSite属性付きCookieの利用

HTTP Cookieには、SameSiteという属性を設定することができます。これは、Cookieがどのサイトからのリクエストとともに送信されるかを制御するものです。

SameSite=Lax
他のサイトからのGETリクエスト（リンクのクリックなど）ではCookieが送信されますが、POSTリクエストなどでは送信されません。多くのWebアプリケーションで安全な設定として推奨されています。
SameSite=Strict
同じサイトからのリクエストでのみCookieが送信されます。より厳格なセキュリティを求める場合に有効ですが、使い勝手が悪くなる可能性もあります。
SameSite=None
どのようなサイトからのリクエストでもCookieが送信されます。これはCSRFのリスクを高めるため、推奨されません。

SameSite属性を適切に設定することで、ブラウザがセッション情報を悪意のあるサイトからのリクエストと共に送信してしまうことを防ぎ、CSRF対策として有効です。

4. 重要な操作の都度、パスワード再認証

Webサイトでの決済やパスワード変更など、特に重要な操作を行う際に、再度パスワード入力を求めることも効果的な対策の一つです。これは、攻撃者がユーザーのセッション情報だけを悪用しても、重要な操作を完遂できないようにするためです。

今後の動向と私たちにできること

Webアプリケーションのセキュリティは、常に攻撃者とのイタチごっこです。新たな攻撃手法が生まれる一方で、それを防ぐための対策も進化していきます。

CSRF対策においては、主要なフレームワークやライブラリが標準でCSRF対策機能を提供しており、開発者が意識しなくても対策が導入される傾向にあります。しかし、その仕組みを理解しておくことは、情報処理安全確保支援士やネットワークスペシャリストを目指す皆さんにとって非常に重要です。なぜなら、万が一の事態に備え、適切にセキュリティ設計を行い、問題発生時に原因を特定し、対処するためには、深い知識が不可欠だからです。

また、ユーザー側としても、安易に不審なリンクをクリックしない、信頼できないサイトにはアクセスしないなど、基本的なセキュリティ意識を持つことが大切です。

さて、問題の解説です

クロスサイトリクエストフォージェリ攻撃の対策として、効果がないものはどれか。

ア　Webサイトでの決済などの重要な操作の都度、利用者のパスワードを入力させる。
イ　Webサイトへのログイン後、毎回異なる値をHTTPレスポンスボディに含め、Webブラウザからのリクエストごとに送付されるその値を、Webサーバ側で照合する。
ウ　Webブラウザからのリクエスト中のRefererによって正しいリンク元からの遷移であることを確認する。
エ　WebブラウザからのリクエストをWebサーバで受け付けた際に、リクエストに含まれる”<“、”>”などの特殊文字を、”<”、”>”などの文字列に書き換える。

エ　WebブラウザからのリクエストをWebサーバで受け付けた際に、リクエストに含まれる”<“、”>”などの特殊文字を、”<”、”>”などの文字列に書き換える。

正解です。
これはXSS（クロスサイトスクリプティング）対策です。
特殊文字をエスケープすることで、HTMLやJavaScriptの挿入を防ぎます。
CSRFはHTMLタグやスクリプトの挿入が本質ではないため、無関係です。

ア　Webサイトでの決済などの重要な操作の都度、利用者のパスワードを入力させる。

有効な対策です。
毎回パスワードを聞くことで、本人の操作かどうかを確認できます。
攻撃者はユーザのパスワードを知らないため、不正リクエストは失敗します。

イ　Webサイトへのログイン後、毎回異なる値をHTTPレスポンスボディに含め、Webブラウザからのリクエストごとに送付されるその値を、Webサーバ側で照合する。

これはCSRFトークン方式で、有効な対策です。
トークンはセッションごとに（あるいはリクエストごとに）異なり、攻撃者はその値を知ることができないため、有効です。

ウ　Webブラウザからのリクエスト中のRefererによって正しいリンク元からの遷移であることを確認する。

有効な対策です。
多くのブラウザでは、リクエスト時にRefererヘッダを送信し、正規のページ（同じドメインなど）からのリクエストかどうかを確認できます。
ただし、完全ではなく、プライバシー設定でRefererが省略されることもあります。

CSRF対策のまとめ

対策方法	効果有無	補足
CSRFトークンを使う	○	標準的な方法
Refererヘッダのチェック	△	プライバシー設定で送信されない場合がある
パスワード再入力	○	利用者には負担だが強力
`< >`などの文字をエスケープ	✕	XSS対策であり、CSRFには無効