LASSIC Media らしくメディア
CSRFとは｜意図しない操作をさせる攻撃と対策
Webシステムのセキュリティに関する話題で、「CSRF（クロスサイトリクエストフォージェリ）の対策はできていますか」「脆弱性診断でCSRFトークンの指摘がありました」といった言葉を耳にしたことはないでしょうか。CSRFは、SQLインジェクションやXSSと並んで、Webサイトを狙う代表的な攻撃手法の一つに数えられます。IT事業部でシステムの発注や運用に関わる立場であれば、名前は聞いたことがあっても、それが具体的に何を突く攻撃で、なぜ危ないのか、どう防ぐのかまでは説明しにくいかもしれません。とはいえ、その大まかな仕組みを理解しておくと、ベンダーの提案や脆弱性診断の報告を受けたときに、対策が妥当かどうかを判断する助けになるでしょう。本記事では、攻撃コードの書き方といった実践的な手順ではなく、CSRFとはそもそも何を突く攻撃なのか、なぜ起こり、どんな被害につながり、どう防ぐのかを、発注・運用の視点から順に整理します。専門的な用語をすべて覚える必要はありませんが、「ログイン状態が、本人の知らないところで悪用される」という勘所をつかんでおくと、セキュリティの会話が理解しやすくなるはずです。
CSRFとは何か
CSRF（Cross-Site Request Forgery、クロスサイトリクエストフォージェリ）とは、あるサイトにログインしている利用者を、本人が意図しないリクエスト（操作の要求）を正規のサイトへ送るように仕向ける攻撃です。「フォージェリ（forgery）」は「偽造」を意味し、本人になりかわって偽の要求を送りつける、というイメージからこの名前が付いています。読み方は「シーサーフ」と呼ばれることもあります。
もう少しかみ砕いてみましょう。多くのWebサイトは、一度ログインすると、その後のアクセスを「ログイン済みの本人からのもの」と見なして処理する作りです。この「本人だと見なす」仕組みが、ブラウザに保存されたログイン情報（Cookie）に頼っている場合、攻撃者は、利用者がログインしたままの状態を悪用できます。具体的には、攻撃者が用意した罠のページを利用者が開くと、そのページに仕込まれた指示によって、利用者のブラウザが、本人のログイン情報を付けたまま、正規のサイトへ勝手にリクエストを送ってしまうのです。正規のサイトから見れば、それは「ログイン済みの本人からの正当な要求」に見えるため、そのまま処理されてしまいます。
たとえるなら、本人がサインイン済みの窓口に、第三者が本人の名前でこっそり書類を提出し、窓口がそれを本人の依頼として受け付けてしまうようなものです。本人は、自分がその操作を行ったつもりはまったくありません。CSRFが厄介なのは、利用者が「ただ別のページを開いただけ」で被害に遭いうる点にあります。
身近な流れで想像してみましょう。ある利用者が、あるサービスにログインしたまま、別のタブでたまたま届いたメールのリンクを開いたとします。そのリンク先が攻撃者の用意した罠のページで、開いた瞬間に、利用者のブラウザから元のサービスへ「登録メールアドレスを変更する」といった要求が、本人のログイン情報を付けて送られてしまう——。利用者は何も入力していないのに、サービス側では設定が書き換わってしまう、という具合です。こうした被害は、とりわけ送金や設定変更のように「状態を書き換える操作」で問題になります。
なぜ起こるのか（攻撃の仕組み）
CSRFが成立してしまう根っこには、「そのリクエストが、本当に正規の画面から、本人の意思で送られたものか」をサイト側が確認していない、という問題があります。
ブラウザには、一度あるサイトにログインすると、そのサイト宛てのリクエストには自動的にログイン情報（Cookie）を添える、という性質があります。これは本来、利用者がいちいちログインし直さずに済むようにするための便利な仕組みです。ところが、この「自動で付く」性質があるために、リクエストがどのページを起点に送られたものであっても、Cookieは付いてしまいます。サイト側が、Cookieが付いていることだけをもって「本人からの要求だ」と判断していると、罠サイトを起点とした要求まで、本人のものとして受け付けてしまうのです。次の図は、この流れを単純化して示したものです。
ここで大切なのは、CSRFは「本人のログイン情報を盗む」攻撃ではない、という点です。ログイン情報そのものは盗まれておらず、あくまで「ログイン済みという状態」が、本人の知らないうちに使われてしまうのです。だからこそ、対策の中心も「情報を守る」ことより、「そのリクエストが本当に正規の画面から送られたのかを見分ける」ことに置かれます。この考え方が、後述する対策の土台になります。
この記事のポイント
- CSRFは、ログイン中の利用者に、本人が意図しないリクエストを正規サイトへ送らせる攻撃です。
- 原因は、リクエストが正規の画面から本人の意思で送られたかをサイト側が確認していないことにあります。
- トークンの照合やSameSite Cookieなどで、正規の画面からの要求かを見分けることが対策の中心です。
XSSとの違い
CSRFは、同じくWebを狙うXSS（クロスサイトスクリプティング）と混同されがちですが、狙いどころが異なります。両者の違いを整理しておくと、報告を受けたときに理解しやすくなります。
| 観点 | CSRF | XSS |
|---|---|---|
| 何を悪用するか | ログイン状態（自動で付くCookie） | 出力処理の不備（入力がそのまま表示される） |
| 起こること | 本人の意図しない操作が実行される | 利用者のブラウザで悪意あるスクリプトが動く |
| 対策の中心 | 正規の画面からの要求かの確認（トークン等） | 出力時のエスケープ（無害化） |
ざっくり言えば、XSSが「サイトに悪意あるプログラムを紛れ込ませる」攻撃であるのに対し、CSRFは「本人のログイン状態を借りて、正規の操作を勝手に実行させる」攻撃です。両者は独立した脅威であり、片方を防いだからもう片方も防げる、という関係ではありません。そのため、どちらもあわせて対策しておくことが求められます。なお、XSSの弱点があるとCSRF対策をすり抜けられる場合もあり、両者は無関係ではない点も知っておくとよいでしょう。
どんな被害につながるのか
CSRFが成立すると、攻撃者は、利用者本人にしか行えないはずの操作を、本人になりかわって実行させられます。代表的な被害を挙げておきましょう。
一つ目は意図しない情報の変更です。登録されているメールアドレスやパスワードを勝手に書き換えられ、そこからアカウントを奪われるおそれがあります。二つ目は意図しない操作の実行です。送金や注文、退会、投稿の削除といった、本人しかできない操作が、知らないうちに行われることがあります。三つ目は設定の改ざんです。通知先や連絡先などの設定を書き換えられ、後々の不正利用の足がかりにされる場合があります。
共通しているのは、いずれも「本人が行ったように見える操作」である点です。記録の上では本人の操作として残るため、被害に気づくのが遅れたり、原因の特定が難しくなったりします。CSRFが軽視できないのは、攻撃の起点が「利用者が何気なく開いたページ」でありながら、本人になりかわって重要な操作まで実行されうるという、その影響の大きさにあるといえるでしょう。
基本の対策と発注・運用の観点
CSRFにも、有効性が広く知られた対策があります。中心になる考え方と、発注・運用で押さえておきたい観点を整理しておきましょう。
| 対策 | 考え方 |
|---|---|
| CSRFトークン | 最も基本の対策。正規の画面を表示する際に、推測しにくい合言葉（トークン）を埋め込み、送信時にそれが一致するかを確認します。罠サイトはこの合言葉を知らないため、要求が弾かれます。 |
| SameSite属性のCookie | Cookieに、別サイト起点のリクエストには付けない設定を加える方法。ブラウザ側の仕組みで、罠サイト経由の要求にログイン情報が付くのを抑えます。 |
| 重要操作での再確認 | 送金やパスワード変更など影響の大きい操作で、パスワードの再入力や確認画面をはさむ方法。万一の際の歯止めになります。 |
中心になるのは、CSRFトークンによって「正規の画面から送られた要求か」を見分けるという考え方です。SameSite属性のCookieや重要操作での再確認は、それを補う多層的な守りと位置づけると整理しやすくなります。多くの開発フレームワークには、こうしたトークンの仕組みが標準で用意されており、これを正しく使うことが対策の基本になります。
発注・運用の立場では、いくつかの観点を押さえておくとよいでしょう。第一に挙げられるのが、対策方針の確認になります。開発を委託する際に、CSRFを含む代表的な脆弱性への対策方針を、提案や仕様の中で確認しておくと後がスムーズです。第二に、脆弱性診断の活用です。リリース前や定期的なタイミングで診断を受けると、作り込みの不備を早い段階で見つけられます。第三に、既存システムの棚卸しです。古くから稼働しているシステムほど対策が手薄になりがちなため、一度確認しておくと思わぬリスクの早期発見につながります。なお本記事は攻撃手法の実践的な手順ではなく、CSRFという脅威の考え方と、発注・運用で押さえたい観点に焦点を当てているものです。個別の対策の実装や診断は、実績のあるベンダーや専門機関への相談が別途必要になります。
まとめ
- CSRFは、ログイン中の利用者に、本人が意図しないリクエストを正規サイトへ送らせる代表的な攻撃です。
- ログイン情報を盗む攻撃ではなく、「ログイン済みという状態」が本人の知らないうちに悪用される点が特徴です。
- 原因は、リクエストが正規の画面から本人の意思で送られたかをサイト側が確認していないことにあります。
- XSSとは狙いどころが異なり、両者は独立した脅威のため、どちらもあわせて対策する必要があります。
- 被害は、情報の変更・意図しない操作の実行・設定の改ざんなど、本人になりかわって行われます。
- 対策の中心はCSRFトークンで、SameSite Cookieや重要操作での再確認を多層で重ねます。
- 本記事は攻撃手法の手順ではなく、脅威の考え方と発注・運用の観点の整理を狙いとしています。
よくある質問
CSRFとXSSはどう違うのですか。
狙いどころが異なります。XSSは、サイトの出力処理の不備を突いて、利用者のブラウザで悪意あるスクリプトを実行させる攻撃です。一方CSRFは、利用者のログイン状態（自動で付くCookie）を悪用し、本人が意図しない操作を正規サイトへ実行させる攻撃です。XSSがプログラムを紛れ込ませるのに対し、CSRFは本人のログイン状態を借りて正規の操作を勝手に行わせる、という違いがあります。両者は独立した脅威であり、片方の対策だけでもう片方も防げるわけではないため、あわせて備えることが求められます。
CSRFトークンとは何ですか。
CSRFトークンとは、正規の画面を表示する際にそのページへ埋め込む、推測しにくい合言葉のような値です。利用者がその画面から操作を送信すると、埋め込まれたトークンも一緒に送られ、サイト側はそれが正しいかを確認する仕組みです。罠サイトはこの合言葉を知り得ないため、罠サイト経由の要求はトークンが一致せず弾かれます。これにより「正規の画面から送られた要求かどうか」を見分けられるのです。多くの開発フレームワークに標準の仕組みとして備わっており、これを正しく使うことがCSRF対策の基本になります。
CSRFはログイン情報が盗まれる攻撃ですか。
いいえ、ログイン情報そのものを盗む攻撃ではありません。CSRFで悪用されるのは「ログイン済みという状態」であり、パスワードやCookieの中身が攻撃者の手に渡るわけではないのです。攻撃者は、利用者がログインしたままの状態を利用して、本人になりかわって操作を実行させるわけです。情報が盗まれていないぶん、記録上は本人の操作として残り、被害に気づきにくいという厄介さがあります。だからこそ、情報を守ることに加えて、要求が正規の画面から送られたかを見分ける対策が重要になります。
SameSite CookieがあればCSRFトークンは不要ですか。
どちらか一方だけに頼り切るのは避けるのが無難です。SameSite属性のCookieは、別サイト起点のリクエストにログイン情報が付くのを抑える有効な仕組みで、近年はブラウザ側の初期設定も強化されています。ただし、対応状況や設定の細かな条件によっては、単独では守り切れない場合もあります。CSRFトークンという根本的な確認の仕組みを土台に据え、SameSite Cookieを重ねて多層で守るのが堅実です。守りは一つの手段に頼らず、組み合わせることが大切です。
著者：テレリモ総研編集部 鈴木 亮佑
LASSICでは、国内ニアショア開発体制を活かし、CSRFやXSSをはじめとする脆弱性を作り込まないための設計・実装から、CSRFトークンやSameSite Cookieを踏まえた作り込み、既存システムの対策状況の確認、脆弱性診断を踏まえた改修までを一貫して支援する体制です。診断で指摘を受けたが対応の優先順位に迷う、古いシステムのリスクが気になるといった課題の見直しについてもご相談いただけます。要件定義の段階から実装、テスト、リリース後の運用・保守まで、工程を分けずに任せられる点も強みでしょう。セキュリティの作り込みに不安がある段階からでも、ご相談ください。
ご不明な点はお問い合わせフォームからもご連絡いただけます。
