クロスサイトリクエストフォージェリ（CSRF）とは、Webアプリケーションの「セッション管理」機能に潜む、セキュリティ上の欠陥を狙ったサイバー攻撃の一種です。

ユーザーのログインしたセッションIDを悪用し、当人になりすまして不正リクエストを送信。Webアプリケーション上で不正な操作を行います。

CSRFの被害に遭うと、意図しない悪質な情報発信や不正送金、会員情報が不正に書き換えられてしまったりする可能性があります。CSRFは「Webアプリケーションの脆弱性を狙うサイバー攻撃」の中でも発生率が高く、MOTEXの診断サービスでも検出回数が非常に多い攻撃の1つです。

▼MOTEXの診断で発見された「Webアプリケーションの脆弱性」検出数ランキング

CSRFの知識を身につけ、セキュリティ対策を強化したいとお考えの方は、この記事を読むとCSRFについて詳しく学ぶことができます。

また「CSRF」をはじめとする、注意すべき「Webアプリケーションの脆弱性を狙うサイバー攻撃」5つに関する考察・対策を、1冊のホワイトペーパーへまとめました。

ぜひ本記事とあわせて、ご活用ください。

クロスサイトリクエストフォージェリ（CSRF）とは？

クロスサイトリクエストフォージェリ（CSRF）とは、「Webアプリケーションのセッション管理の脆弱性」を悪用するサイバー攻撃の一つです。

攻撃者は、Webアプリケーションにログイン中のユーザーに不正なリンクを踏ませるなどして、あたかもそのユーザーが操作をしたかのように、Webアプリケーションに不正なリクエストを送信。アプリケーション側は「ログイン中のユーザーからのリクエストである」と誤認し、不正なリクエストを実行してしまいます。

CSRFに遭うと、ユーザーは「ECサイトやオンラインバンキングで身に覚えのない決済をさせられる」、あるいは「SNSや掲示板で意図しない投稿をされる」などの被害が生じてしまいます。

ログインした利用者からのリクエストが、正規のリクエストか、それとも不正なリクエストなのかを識別する仕組みを持たないWebアプリケーションは、攻撃対象になりやすくなってしまいます。

クロスサイトリクエストフォージェリ（CSRF）の具体的な攻撃イメージ

ここでは、銀行のWebアプリケーション（オンラインバンキング）を例に、CSRFの具体的な仕組みを解説します。

アプリにログインしているユーザーを「Aさん」、攻撃者を「攻撃者B」とします。

Aさんは、自身の預金残高を確認しようと銀行のWebアプリへログインし、そのままログアウトをせずサイトを離れました。その後、攻撃者Bからメールで送られてきた「罠のサイト」のURLをクリックし、アクセスしてしまいます。

この罠サイトは、「攻撃対象のWebアプリケーション（今回は銀行サイト）に不正なリクエストを送信すること」を目的として、攻撃者Bが事前に作成したものです。

Aさんが銀行のWebアプリにログインした状態でこの罠サイトにアクセスしたことで、銀行のWebアプリに不正なリクエストが自動送信され、Aさんの口座から攻撃者Bの口座へ、意図せず10万円が振り込まれてしまいました。

このようにCSRFでは、サービスにログイン中のユーザーに対し、攻撃者の意図にそったリクエストを実行させることができてしまいます。

CSRFと「クロスサイトスクリプティング（XSS）」の違いとは？

CSRFとよく比較されるサイバー攻撃に「クロスサイトスクリプティング（XSS）」があります。

両者ともWebアプリケーション・Webサイトの脆弱性に付け込むサイバー攻撃で、ユーザーに意図せぬアクションを実行させ、情報漏洩や不正送金といった被害を及ぼす点で共通しています。

「クロスサイトリクエストフォージェリ（CSRF）」と「クロスサイトスクリプティング（XSS）」の違いは、次の通りです。

	クロスサイトリクエストフォージェリ （CSRF）	クロスサイトスクリプティング （XSS）
攻撃方法	ユーザーのログインした状態を悪用し、リクエストを偽装する	ユーザーに不正なスクリプトを実行させる
狙う脆弱性	Webアプリケーションの”セッション管理”の脆弱性を狙う	動的なWebアプリケーション（Webサイト）の脆弱性を狙う
攻撃対象の例	ログインを必要とするWebアプリケーション ・オンラインバンキング ・SNS ・ECサイト　など	情報入力を行うWebサイト ・インターネットの掲示板 ・個人情報の入力フォーム ・アンケートサイト　など
被害内容	・個人情報の漏洩 ・アカウント情報の変更 ・不正な入出金や購入 ・意図しない投稿や書き込み	・個人情報の漏洩 ・Webサイトの改ざん・削除 ・不正な入出金や購入 ・意図しない投稿や書き込み

CSRFは、Webアプリケーションのセッション管理に潜む脆弱性を悪用するサイバー攻撃です。（脆弱性とは）

例えば、AmazonやSNSにログインしたままのユーザーのセッション情報を乗っ取り、ユーザーのリクエストを偽装して、あたかも本人がログインしているかのような操作（商品の購入やパスワードの変更など）を不正に行います。

セッションを悪用することで、本来ならユーザー自身がログインしなければ行えない、アカウント情報の変更や入出金などの操作が可能になってしまいます。

一方のクロスサイトスクリプティングは、「掲示板の書き込み」や「個人情報の入力画面（申し込みフォームなど）」のような、ユーザーが情報を入力する動的なWebサイトに罠をしかける攻撃です。

脆弱性のあるWebサイトに「不正なスクリプト（命令文）」を埋め込むことで、情報の入力や書き込みをしたユーザーに、意図しないスクリプトを実行させます。ユーザーは知らないうちに、入力した個人情報を盗まれたり、Webページの改ざんや削除を行ってしまいます。

両者はともに「Webアプリケーションの脆弱性」に付け込む代表的な攻撃手法であり、Webサイトやアプリを運営する組織は、積極的に対策を打つ必要があるでしょう。

クロスサイトリクエストフォージェリ（CSRF）の攻撃の流れ

IPA（情報処理推進機構）の参考画像を基に、「CSRFの攻撃の流れ」を簡単にまとめると、以下のようになります。

出典：IPA│安全なウェブサイトの作り方 – 1.6 CSRF（クロスサイト・リクエスト・フォージェリ）

1.ユーザーがWebアプリケーションに通常通りログインする

2.Webアプリケーション側が、ユーザーがログインした状態でセッションIDを発行する

3.ユーザーは、ログアウトせずWebアプリケーションを閉じる（ログイン状態を維持）。攻撃者は「あらかじめ用意した罠サイト」へ、メールやSMSなどを使って、ユーザーを誘導する
4.ユーザーが罠サイトにアクセスしてしまう

5.罠サイトでリンクのクリックなどを行うことにより、攻撃者の仕込んだ「不正なリクエスト」がWebアプリケーションに送信される

6.Webアプリケーション側は不正なリクエストを処理してしまい、ユーザーが意図しない処理（不正送金や購入など）が実行されてしまう

CSRF攻撃を受けると、どういった被害が発生する？

先述の通り、CSRFは「ユーザーのログインした状態」を悪用するサイバー攻撃です。よって、受ける被害も「”ログインが必要”なWebアプリケーションやサービス」を起点に発生します。

CSRF攻撃を受けた場合、発生しうる被害リスクは以下の通りです。

本来であれば、ログイン後のユーザーのみが利用可能なサービス・編集可能な情報を悪用されたり改ざんされたりするのが、CSRF被害の特徴です。

また、CSRFはユーザーに気づかれにくい攻撃であるため、被害に遭ってもすぐに対処できないという厄介な特性があります。

クロスサイトリクエストフォージェリ（CSRF）攻撃を受けやすい、Webサイトの特徴

CSRFの攻撃を受けやすいWebサイトの特徴として、次のようなものが挙げられます。

※Basic認証…ユーザー名（ID）とパスワードを入力し、ユーザーに閲覧権限を与える認証。ベーシックな方法である一方、情報を盗聴されやすいという懸念もある
※SSLクライアント認証…Webサイトのアクセス時、（一般的には）第三者機関の発行する「クライアント証明書」を用いて認証を行う仕組み。通常のログインよりセキュリティレベルが高い点が強み

また、ネットバンキングやECサイト、オークションサイトなど「金銭処理を行うサイト」「会員情報サイト」「管理画面を持つサイト」は、CSRFと対象となりやすい傾向にあります。

クロスサイトリクエストフォージェリ（CSRF）の被害事例

CSRFの特徴について解説してきましたが、実際にどのような被害が起こっているのでしょうか。

ここでは、CSRFによって第三者のPCが遠隔操作された事例を紹介します。

第三者のPCをCSRFで遠隔操作、殺人予告などの書き込みが行われた事件

2012年6月、CSRFによって第三者のセッションを踏み台にした攻撃者が、関東圏の市のホームページに無差別殺人予告を書き込むという事件が発生しました。

この時、CSRFによってPCを乗っ取られた4名の被害者が、無差別殺人予告を書き込んだ罪で誤認逮捕される事態となりました。誤認逮捕が次々と発生した理由は、当時の警察が「サイバー攻撃に関する詳しい知識を持たなかったため」と言われています。

攻撃者は犯行を行ったサイトにアクセスする際、暗号化によって足取りを掴めないように工作するなど狡猾な手口を使っていたため、犯人の特定にますます時間を要することとなりました。

犯人が逮捕されたのは翌年の2013年2月のことであり、事態が一旦の収拾を見せるまでに、実に半年以上もの時間がかかる事件となりました。

参考：Yahooニュース｜PC遠隔操作事件ってどんな事件？ 片山被告が無実主張（2014/3/21）

CSRFに有効なセキュリティ対策（ユーザー編）

CSRFの被害を防ぐためには

両者がそれぞれ適切な対策を、定期的に実行することが重要です。

まずは「ユーザー側」ができるCSRFのセキュリティ対策を3つ解説します。

1．オンラインサービス利用後は、こまめにログアウト

前述のように、CSRFは「ログアウトされていないサービスのリクエストを偽装する」サイバー攻撃です。そのため、オンラインサービスの利用後は、ログインしたままにせず、こまめなログアウトを徹底しましょう。

通常、すでにログアウト済みのサービスのセッションを乗っ取ることはできないため、被害を未然に回避できる可能性が高くなります。

2．不審なWebサイトやリンクへアクセスしない

覚えのない宛先からのメールに書かれているWebサイトのリンクは、安易にクリックしないことが重要です。不審なメールが送られてきたときは、開封せずに削除しましょう。

アンチウイルスソフトを活用してメールをスキャンし、悪意のある内容が含まれていないかどうか検知する対策も有効です。

また、Webサイトを訪問した際に、掲示板などに不審なURLが書き込まれているケースもあります。そのようなURLをクリックすることでもCSRFの被害に遭う可能性があるため、Webサイト上のURLは安易にクリックせず、安全性をよく確かめてからアクセスすることが求められます。

3．記憶にない送金履歴や情報発信に気づいたら、すぐサービス元へ連絡

CSRFは、ネットバンキングやECサイトなどの金銭を扱うサイトや、掲示板などの情報発信を行えるサイトで、特に被害が発生しやすいサイバー攻撃です。

そのため入出金履歴を確認して「記憶にない送金履歴」が残っていたり、「書き込んだ覚えのない投稿」が掲示板に書き込まれていたりした場合は、速やかにサービス元へ連絡することが大切です。

サービス元へ連絡せずに放置すると、同様の被害者が増えたり、自身の被害額が増加したりする可能性があるため、早急な対処が重要になります。

CSRFに有効なセキュリティ対策（サービス提供者編）

続いて、Webアプリケーションを運営する「サービス提供者側」が行うべき、CSRFのセキュリティ対策を3つ解説します。

1．セッションIDと機密情報の両方で、リクエストの可否を判断

Webアプリケーションに「セッションIDと機密情報がどちらも正しい場合のみリクエストを許可する」という仕組みを設定することで、CSRFの発生を防ぐことが可能です。

具体的には、掲示板やWebフォームの入力画面を表示する際、「hiddenパラメーター」に機密情報を持たせて、セッションIDと一緒にWebサーバーへ送信します。

※「hiddenパラメーター」とは、データを実際に画面には表示せずに保持しておくことが出来る仕組み

すると、Webサーバー側ではセッションIDと機密情報を別々に保有し、リクエストがあった際に両者が合致した場合のみ、そのリクエストを許可できるようになります。

攻撃者がユーザーのセッションIDを乗っ取り、Webサーバーへ不正なアクセスを試みたとしても、攻撃者は機密情報を持たないため、リクエストを通過することができません。結果的にCSRFの攻撃を食い止めることが可能です。

2．ワンタイムトークンなどを使い、リクエストの照合を強化する

「ワンタイムトークン」などを活用し、リクエストの照合を強化する手法も有効です。

ワンタイムトークンとは、ネットバンキングなどの金銭処理を必要とするWebアプリケーションで特によく使われている手法です。

まず、ログインのたびにランダムな文字列によるリクエストを生成してhiddenパラメーターでWebサーバーへ送信します。
次にリクエスト先のWebサーバーに保存されたトークンと、ログインしようとしているリクエストのトークンが一致するかをチェックすることで、不正アクセスを防止します。

トークンによるランダムな文字列でリクエストの固定化を回避することにより、CSRFによる悪意のあるリクエストが通過する確率を、大きく下げる効果が期待できます。

3．Refererヘッダで正しいリンク元かを確認する

Referer（リファラ）ヘッダにて、リクエスト元が正しいリンクであるかを確認し、不正なリクエストを弾く方法もあります。

Refererヘッダには「リクエストを送信したユーザーが、どのURLからリクエストを行っているのか」の情報が含まれています。仮に、Refererヘッダを見て「本来あるべき画面を遷移していない」場合、攻撃者によるCSRFの可能性が高いでしょう。

WebサーバーでRefererヘッダをチェックすることで、正しいリクエストであった場合のみリクエストを通過させることが可能。仮に不正なリクエスト元からアクセスがあったときは、サーバー側がリクエストを拒否することができます。

CSRF対策ならLANSCOPE プロフェッショナルサービスの「Webアプリケーション診断（脆弱性診断）」にお任せ

最後にCSRF対策に有効な、弊社の提供する「Webアプリケーション診断（脆弱性診断）」についてご紹介させてください。
「LANSCOPE プロフェッショナルサービス」は、12,000件以上のサービス提供実績と90％以上という高いリピート率を誇る、サイバーセキュリティに特化したサービスです。

「Webアプリケーション脆弱性診断」では、当社のセキュリティ・スペシャリストがきめ細かい診断を行い、CSRFの要因となる、WEBアプリケーションの脆弱性（課題・弱点）を洗い出し、必要な対策案を優先順位づけしてご提案します。

診断結果は詳細な「報告書」でまとめ、Webアプリケーションが抱えるリスクを「点数」で可視化することが可能です。

関連ページ:LANSCOPE プロフェッショナルサービス ｜「Webアプリケーション脆弱性診断」はこちら

また、より手ごろな価格帯で「WEBアプリケーション脆弱性診断」を受けていただける「セキュリティ診断パッケージ」も提供しております。

関連ページ：低コスト・短期で診断を行う『セキュリティ健康診断パッケージ』の詳細はこちら

まとめ

本記事では、CSRF（クロスサイトリクエストフォージェリ）について解説してきました。

この記事を参考に、皆さんのCSRFへの理解が深まり、セキュリティ対策を行うきっかけとなれば幸いです。

また「CSRF」をはじめとする、注意すべき「Webアプリケーションの脆弱性を狙ったサイバー攻撃」5つに関する考察・対策を、1冊のホワイトペーパーへまとめました（今回扱ったXSS攻撃、SQLインジェクションなどの情報がまとまっています）。

ぜひ本記事とあわせて、ご活用ください。