“攻撃者の格好の標的”から外す!中小企業のサイバーセキュリティ-中小企業が狙われるサプライチェーン攻撃とサイバーセキュリティ強化術-

Share

Security NEWS TOPに戻る
バックナンバー TOPに戻る

中小企業はサイバー攻撃者の格好の標的とされることも多く、特にサプライチェーン攻撃で狙われるリスクが高まっています。そこで、自組織におけるリスクの可視化やセキュリティ対策の定期的な見直しをすることが重要です。本記事では中小企業のサイバーセキュリティの現状やそれによって起こり得る影響、サプライチェーン攻撃の事例を踏まえ、効果的なセキュリティ対策と見直しのポイントを解説します。

ペネトレーションテストの有効性やシナリオ解説をまとめたホワイトペーパーを公開中!以下のリンクから無料でダウンロードいただけます。
記事はこちら

中小企業のサイバーセキュリティの現状

昨今、中小企業のサイバーセキュリティ対策に注目が集まっています。中でも、大手企業が取引先に求める安全性が、サプライチェーン全体へと波及し、サプライチェーン攻撃が大きな問題となっています。その要因には、日本の企業の約9割が中小企業であり*2、大企業の関連会社、取引先企業を含め多くを中小企業が占めているという点が挙げられます。

認識と実態のギャップ

日本商工会議所の調査では、「十分に対策している」「ある程度対策している」と回答した企業は86%と高い水準で、回答した企業のほとんどが「自社は対策している」と考えているようです。しかし、実際に行われているセキュリティ対策の内訳をみると、「ウイルス対策ソフト」(90.1%)、「ソフトウェアの定期的なアップデート」(72.6%)が中心で、「社内教育」、「セキュリティ診断」、「訓練」などといった専門的な対策については、いずれも30%以下にとどまっています。本来であれば十分な対策をしていると言えるのは、専門的な対策まで実施して言えるものです。この認識と実態のギャップが、サプライチェーン全体の脆弱性を生み、取引先への被害連鎖を招くリスクを高めています。

認識と実態のギャップ
出典:日本商工会議所「サイバー安全保障分野での対応能力の向上に向けた有識者会議」ヒアリング資料(資料3)

ここまで中小企業のサイバーセキュリティの現状と対策の実施状況についてご紹介しました。では、サイバー攻撃の標的となった場合、中小企業に与える影響とはどのようなことがあるのでしょうか。

サイバー攻撃が中小企業に与える影響

中小企業のサイバーセキュリティ対策が不十分だと、自社だけでなくサプライチェーン全体に深刻な影響が及びます。IPA(独立行政法人情報処理推進機構)「2024年度中小企業等実態調査結果」(速報版/2025年2月公開)によれば、調査対象の中小企業の約70%が「自社のサイバーインシデントが取引先事業に影響を与えた」と回答しています。自社だけでなくサプライチェーン全体を見据えた取り組みをしないと、連鎖的に被害が拡大し、取引先企業の業務停止や企業の信用失墜、最悪の場合は損害賠償請求にまで発展するケースも少なくありません。

サプライチェーンで狙われる中小企業

セキュリティ対策が手薄な関連企業や取引先企業を経由して、標的とする企業へ不正侵入をする「サプライチェーン攻撃」が急増しています。IPA「情報セキュリティ10大脅威 2025(組織編)」でも「サプライチェーンや委託先を狙った攻撃」が2位にランクインしています。

サプライチェーン上には攻撃者にとって魅了的な、機密情報、知的財産、顧客データなどが流れ、中小企業が格好の標的になりがちです。中小企業が狙われる要因として、攻撃者の最終的なターゲットとなりうる大手企業とつながりがあることや、予算や人材不足などの制約によってセキュリティ対策が不十分になりがちなことなどが挙げられます。

サプライチェーン管理で陥りがちな落とし穴

サプライチェーンでは、以下のような課題が連鎖的な脆弱性を生み出します。

  • リモートワーク環境下などで委託先のセキュリティ状況が可視化できず、実態が把握できない
  • セキュリティ基準や管理体制が統一されず、企業間で対策レベルに大きな格差が発生
  • 人材や予算が限られる中小企業では、セキュリティ対策が後回しになりがち

こうした課題が積み重なると、委託先の一つの企業で発生したインシデントが再委託先まであっという間に波及し、大企業を含むサプライチェーン全体が火だるまとなり得ます。そのため、中小企業のサイバーセキュリティ対策には、関係先を含めた統一ルールと継続的な情報共有が不可欠です。

サプライチェーン攻撃の事例

2023年11月27日、メッセージアプリ提供会社が、自社サーバへの不正アクセスでメッセージアプリに関するユーザ情報・取引先情報、従業者情報等が漏洩したことを公表しました。

発端は、同社と関係会社が共用する委託先業者の従業員PCがマルウェアに感染し、共通認証基盤を経由してメインシステムに侵入されたことです。共通の認証基盤で管理されているシステムへネットワーク接続を許可していたことから、同社のシステムに不正アクセスされました。(下図参照)

この事例から関係会社との認証基盤の共有や、ネットワークアクセス管理、委託先業者の安全管理など、セキュリティ対策、見直しを行うべきポイントが浮き彫りになり、中小企業でも委託先の安全管理の甘さが同様の被害を招く可能性が示されました。委託先業者の安全管理は委託先業者の責任とせずに、自社のセキュリティの一角と認識して対応することが重要です。

中小企業のサイバーセキュリティ対策

中小企業のサイバーセキュリティ強化には、自社だけでなくサプライチェーン全体での取り組みが不可欠です。

サプライチェーン全体への取り組み

サプライチェーン全体では、次の3点を定期的に確認しましょう。

  • サプライチェーン上の各企業におけるセキュリティ状況の把握(アンケート調査等の実施)
  • サプライチェーン上にセキュリティ水準の異なる企業があるか確認
  • サプライチェーン上の企業間における重要情報の定義と取り扱い方法の取り決め実施

ポイントは、常に自社/自組織が当事者であるという姿勢です。以下のような基本的な対応がとられているか、今一度ご確認いただくことをおすすめします。

自社・自組織での基本的な取り組み

  • 自社/自組織のセキュリティ状況の把握と対策
  • 取引先/委託先のセキュリティ対策状況の監査
  • 使用しているソフトウェアに関する脆弱性情報のキャッチアップ 等

また、以下のガイドラインもあわせて参照することを推奨します。
経済産業省 商務情報政策局 サイバーセキュリティ課
ソフトウェア管理に向けたSBOM(Software Bill of Materials)の導入に関する手引Ver.1.0
OSS の利活⽤及びそのセキュリティ確保に向けた 管理⼿法に関する事例集

「SBOM (Software Bill of Materials)」について、SQAT.jpでは以下の記事でご紹介しています。こちらもあわせてご覧ください。
脆弱性管理とIT資産管理-サイバー攻撃から組織を守る取り組み-

まとめ:今すぐ自組織のセキュリティ対策の見直しを!

中小企業のサイバーセキュリティ強化は、自社だけでなく取引先や委託先を含むサプライチェーン全体での取り組みが欠かせません。まずは以下のステップを実践して被害のリスクを最小化しましょう。

  1. 現状把握:年1回以上の脆弱性診断やペネトレーションテストで、自社システムのリスクを可視化
  2. サプライチェーン調査:アンケートや監査で取引先のセキュリティ水準を確認・格差を是正
  3. 自社・自組織のルールの策定:重要情報の定義と取り扱い方法を取引先と合意・文書化
  4. 外部の専門家活用:ガイドラインを参照し、第三者レビューで対策の網羅性を担保
  5. 継続的な見直し:四半期ごとに状況を更新し、セキュリティ運用を見直す

サプライチェーン関連記事はSQAT.jpで公開中!こちらからご覧ください。
サプライチェーンとは-サプライチェーン攻撃の脅威と対策1-
事例から学ぶサプライチェーン攻撃-サプライチェーン攻撃の脅威と対策2-
サプライチェーン攻撃への対策 -サプライチェーン攻撃の脅威と対策3-

過去のウェビナー再配信に関するお問い合わせはこちら

セキュリティ対策は専門家に相談を

サイバー攻撃手法は日々更新されており、どんなにセキュリティ対策を実施していても自組織のみではインシデントの発生を防ぎきれないのが実情です。自システムのリスク状況の把握には、脆弱性診断の実施がおすすめです。また、サイバー攻撃への備えとして、セキュリティ対策の有効性の確認には信頼できる第三者機関の活用をおすすめします。

脆弱性診断

脆弱性診断のより詳しい診断手法や実践ポイントをまとめたホワイトペーパーを公開中!以下のリンクから無料でダウンロードいただけます。
記事はこちら

脆弱性とは…
・外部からアクセスできる箇所に攻撃の起点として悪用され得る脆弱性や設定の不備が存在しないかどうかを確認することも重要。その際に有効なのが「脆弱性診断」
・攻撃者はシステムの脆弱性を突いて侵入を試みるため、診断によって脆弱な領域を洗い出し、優先度に応じた対策を講じる。診断は、定期的に実施するだけでなく、システム更改時にも必ず実施することが推奨される。
【参考記事】
拡大・高度化する標的型攻撃に有効な対策とは―2020年夏版
「侵入」「侵入後」の対策の確認方法

Webアプリケーション脆弱性診断バナー

ペネトレーションテスト

ペネトレーションテストの有効性やシナリオ解説をまとめたホワイトペーパーを公開中!以下のリンクから無料でダウンロードいただけます。
記事はこちら

ペネトレーションテストとは…
・ペネトレーションテストとは、脆弱性診断の結果、見つかった脆弱性を悪用して、システム・ネットワークへの不正侵入や攻撃が本当に成功するのかを検証することができるテスト手法のひとつ
・重要インフラ15分野では、内部監査と並んで情報セキュリティ確保のための取り組みとして例示されている。

Security NEWS TOPに戻る
バックナンバー TOPに戻る

ウェビナー開催のお知らせ

  • 2025年6月18日(水)14:00~15:00
    侵入が防げない時代に選ぶべき脆弱性診断サービスとは?~実績・サポート・診断基準で比較する、最適な脆弱性診断の選び方~
  • 2025年6月25日(水)13:00~14:00
    リモートワークの落とし穴を塞ぐ!セキュリティ情報の効率的な収集法&対策のポイント
  • 2025年7月16日(水)14:00~15:00
    進化するランサムウェア攻撃-国内最新事例から学ぶ!被害を防ぐ実践ポイント10項目を解説-
  • 最新情報はこちら


    資料ダウンロードボタン
    年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
    お問い合わせボタン
    サービスに関する疑問や質問はこちらからお気軽にお問合せください。

    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像

    脆弱性管理とIT資産管理
    -サイバー攻撃から組織を守る取り組み-

    Share

    Security NEWS TOPに戻る
    バックナンバー TOPに戻る

    日々報告される脆弱性に対してサイバー攻撃から自組織を守るために、「脆弱性管理」と「IT資産管理」を適切に実施することが重要です。本記事では、その脆弱性管理とIT資産の目的や必要性またどのように取り組んでいくのかについて解説します。

    増え続ける脆弱性

    脆弱性は、攻撃者によって利用され、システム侵害の足掛かりとされる可能性がありますので、これに対処することは組織のセキュリティ強化に不可欠です。

    システムやソフトウェアに存在するセキュリティ上の弱点である脆弱性は、日々新しく発見・公表されており、その数は増える一方です(下グラフ参照)。脆弱性が報告される製品は、OS、ミドルウェア、アプリケーション、プログラム言語、ライブラリなど多岐にわたり、商用かオープンソースかを問いません。

    増え続ける脆弱性画像
    NVD(米NIST:NATIONAL VULNERABILITY DATABASE)Static Resultsより2010~2023年の登録脆弱性件数

    また、新たな脆弱性ばかりでなく、VPN機器のような広く利用されている製品がアップデートされないまま放置されている、という実情に目をつけられて、古い脆弱性を悪用した攻撃活動による被害が報告される、といったことも少なくありません。

    脆弱性管理とその目的

    情報資産を守るためには、サイバー攻撃からシステムやソフトウェアを保護する必要があります。そのために重要となるのが脆弱性管理です。脆弱性管理とは、システムやソフトウェアに存在する脆弱性を継続的に把握し、適切な対策を講じることで、セキュリティ上のリスクを低減するための取り組みです。

    脆弱性が放置されたままであれば、それを悪用したサイバー攻撃による情報漏洩や改竄、システム停止といった被害が発生し、企業・組織の信用失墜や業務中断による損失、取引先や顧客からの損害賠償請求、個人情報保護法等による罰則などの事態を招きかねません。脆弱性管理は、これらのリスクに適切に対処するための重要な手段となります。

    脆弱性管理の必要性

    しかしながら、脆弱性対策の予算・人員・時間などのリソースは有限であり、やみくもにすべての脆弱性に対処する、というのは現実的ではありません。無秩序に脆弱性対策をしていては、不必要なコストがかかるばかりでなく、十分な対策を講じられない恐れがあるでしょう。

    脆弱性対策は、限られたリソースで的確かつ効率的に行わなければなりません。自組織に存在する脆弱性を的確に把握し、実態に即したリスクごとに優先度をつけて対応する必要があるのです。「脆弱性管理」は、こうした適切な脆弱性対策を実現するための一連のプロセスと言えます。

    脆弱性管理のライフサイクル

    脆弱性管理の標準的な流れは以下の4つのプロセスになります。

    脆弱性管理のライフサイクル画像

    各プロセスの概要とポイント

    プロセス 概要 ポイント・留意点
    資産の把握・管理 IPアドレス、OS/ソフトウェアとバージョン、稼働中のサービスとその状況などを漏れなく記録。 ・機器・ソフトウェア単体だけでなく、製品に含まれるOSS、プラグインなど、相互の依存関係にも注意。
    ・常にアップデートできていること、管理外の資産(シャドーIT)がないこと。
    脆弱性情報の収集 資産管理情報をもとに、自組織に関係する脆弱性情報を収集。 ・必要に応じて適切なタイミングで実施。
    ・政府機関や製品ベンダといった信頼できるソースから収集。
    脆弱性のリスク評価 脆弱性の危険度を確認した上で、自組織への影響を分析し、対応の難易度やコストも勘案して、対応要否・優先度を決定。 ・まずはCVEなどの脆弱性に関する標準的な指標で各脆弱性の危険度を確認。
    ・自組織に即した評価としては、①攻撃を受けやすい状況か、②攻撃された場合はどの程度影響があるか、③脆弱性解消に要するリソースはどれくらいか、といった要素をなるべく定量的に分析・評価。
    解消策の実行 実行計画を策定し、検証環境に適用して問題がなければ、本番環境に適用。 ・必要な期間の確保、環境の整備、関係者との調整、事業状況の加味などにより、安全・確実に実行できるよう計画。
    ・適用にあたって発生したトラブルなども含め、作業内容は必ず記録。

    脆弱性管理におけるIT資産管理

    脆弱性管理プロセスは、資産の把握と管理から始まりますが、ここで、IT資産管理について考えてみましょう。IT資産管理の主な目的は、ライセンス管理やデータ保護によるコンプライアンスの遵守、資産を正確に把握・追跡することによるセキュリティ事故の防止、資産の効率的な使用を管理することによるコスト削減などとなります。

    IT資産管理では、組織が所有するすべてのIT資産について、以下のような項目を可視化して管理する取り組みです。

    ・ハードウェア : PC、サーバ、ネットワーク機器 等
    ・ソフトウェア : OS、ミドルウェア、アプリケーション 等
    ・ライセンス情報、購入・保守情報、廃棄情報
    ・利用者(利用部門)、利用状況

    IT資産の把握は、システム担当者より資産情報を取得するというのが一般的でしょう。また、システム構築を委託している場合は委託先に資産情報を確認する必要があります。

    方法としては、IT資産管理ツールによって自動化するのがよいでしょう。アプリケーションやクラウドサービスなど、様々なIT資産管理ツールがリリースされていますので、予算や機能に応じて自組織に合うものを選択してください。

    脆弱性管理とIT資産管理の連携

    IT資産管理を整備・強化すると、先に挙げた脆弱性管理の管理プロセスにおいて、以下のようにIT資産管理を有効に連携させることができるでしょう。

    脆弱性管理とIT資産管理の連携画像

    両者を連携することで、セキュリティの確保がより確実に行えるようになることがわかります。

    適切な脆弱性管理のためのポイント

    前段まで脆弱性管理の目的や必要性、プロセス、そしてIT資産管理との連携について確認してきましたが、ここで、適切な脆弱性管理を実現するために必要なポイントについてまとめます。

    漏れなく適時に一元管理 実態に即した評価と対応 プロセスの標準化と見直し
    脆弱性管理を統括する部門に情報が集約されていること
    資産管理、脆弱性情報に漏れがないこと
    資産管理、脆弱性、対応状況といった各情報が常にアップデートされていること 等
    脆弱性情報とその解消策が信頼できる内容であること
    自組織への影響評価と解消策の要否・優先度の決定が適正に行われること
    解消策の実施が安全・確実な方法で行われること 等
    脆弱性管理の各プロセスに一貫性があり、組織内で標準化されていること
    各プロセスでのトラブル発生時には適宜協議できる状態であること
    定期的、あるいは必要に応じて適宜手順の見直しを行うこと 等

    “漏れなく”管理するには

    ここからは、上記で挙げたポイントのうち、「漏れなく」に焦点を当てていきます。資産情報や脆弱性情報に漏れがあると、どんなにリスク評価や解消策の実施体制を整えていても、結局は非効率かつ不十分な対応結果になりかねません。そのため、IT資産を漏れなく管理することは、脆弱性管理のベースとなる重要なポイントと考えられます。脆弱性管理のライフサイクルでいうと、「資産の把握・管理」プロセスで漏れなく資産情報が収集できているか、「脆弱性情報の収集」プロセスでも漏れなく関連する脆弱性情報が収集できているか、といった点です。

    資産の把握・管理:ソフトウェアコンポーネントの管理

    見落としがちな資産として、様々な製品に組み込まれているコンポーネントがあります。

    ■組み込みソフトウェアに起因する脆弱性が問題となった例:

    2021年12月  Javaのログ出力ライブラリApache Log4jにおける脆弱性「Log4Shell」公開された*3
    悪用されるとリモートコード実行の恐れがあるとして、注意喚起された。
    Apache Log4jは国内でも広く利用されているが、様々な製品に組み込まれていることから、国内大手電機メーカーのOT/IoT製品でも影響があることが確認される*2など、脆弱性の影響を受けるシステムの特定が困難だった。
    2023年12月 Sierra Wireless社の「AirLink」にバンドルされているALEOSや一部のオープンソースコンポーネントについて計21件の脆弱性が特定された*3
    リモートコード実行、クロスサイトスクリプティング、DoS、認証バイパスなど深刻度の高い脆弱性が含まれているとのこと。
    世界中の政府やインフラなど、ミッションクリティカルな産業で多く利用されているOT/IoTルータであるため、対応不備による影響が懸念される。

    OT/IoT機器には、ファームウェア等のソフトウェアコンポーネントが含まれます。これらの機器の脆弱性管理には「ソフトウェア部品表(SBOM)」の活用が有効です。

    SBOM (Software Bill of Materials)
    特定の製品に含まれるソフトウェアコンポーネントや相互の依存関係の情報などを機械処理できるリストとして一覧化したもの。導入することで、脆弱性対応期間の短縮、ライセンス管理にかかるコストの低減や開発生産性向上などのメリットがある。
    参考情報:https://www.meti.go.jp/press/2023/07/20230728004/20230728004.html

    SBOMの導入にあたっては、経済産業省より「ソフトウェア管理に向けたSBOM(Software Bill of Materials)の導入に関する手引 Ver. 1.0」(令和5年7月28日)が発行されていますので、参考にしていただくとよいでしょう。

    資産の把握・管理:シャドーITの撲滅

    先ほど述べた「”漏れなく”管理する」を実現するためには、管理外の資産、すなわち「シャドーIT」がないようにすることが重要です。

    組織が認識していないサーバやアプリケーションが稼働していると、その製品自体が組織のセキュリティポリシーの対象外である可能性があり、パッチ適用などのセキュリティ対応が行き届かず、サイバー攻撃の足掛かりとされる恐れが高まります。そもそもその存在を認識していないため、対策の取りようがない、というところが脅威につながります。

    ■シャドーITに起因する脆弱性が問題となった例:

    2024年 2月 著名ブランドや組織のサブドメインを乗っ取る大規模な攻撃キャンペーン「SubdoMailing」が報告*4された。
    8,000以上の正規ドメインと13,000以上のサブドメインを使用して、一日あたり最大500万件のスパムメールが送信され、詐欺やマルバタイジングによる攻撃者の収益源に。
    根本的な原因は、自組織で管理すべきCNAMEレコード(ドメインの別名を定義する情報)が、放棄されたドメインを指定したまま放置されていたこと。

    シャドーITを発見するには、ASM(Attack Surface Management)が有効です(下イメージ)。インターネット上に意図せず公開されている資産がないか確認する手段として活用できます。

    一般的なASMの特徴とイメージ

    一般的なASMの特徴とイメージ画像
    出典:経済産業省「『ASM(Attack Surface Management)導入ガイダンス~外部から把握出来る情報を用いて自組織のIT資産を発見し管理する~』を取りまとめました」(2023年5月29日)

    インターネットから直接アクセス可能なIT資産の調査—アタックサーフェス調査を実施するには、各種ASMツールもリリースされていますし、専門家によるサービスも提供されているので、自組織に合った方法でシャドーITの存在有無を検査できる方法を検討することをおすすめします。

    脆弱性情報の収集:脆弱性診断で補完

    資産の把握・管理が漏れなく適切に実施できたとしても、関連する脆弱性情報の収集に漏れがあっては意味がありません。シャドーITの場合と同様、そもそもそこに脆弱性が存在することを認識できていなかった、ということがないようにする必要があります。とはいえ、脆弱性診断にはそれなりのリソースがかかるため、サイバー攻撃を受けた場合の影響が特に大きいと考えられるシステム(下記例)に関しては、脆弱性管理プロセスの一環として脆弱性診断を実施することを推奨します。

    ・外部に公開されているネットワークセグメント
    ・個人情報の取り扱いや決済機能といった重要な処理に係るシステム
    ・主力業務に直結するミッションクリティカルなシステム 等

    ASMや脆弱性診断の実施頻度

    漏れのない脆弱性管理を行い、サイバー攻撃から組織を守るためには、ASMや脆弱性診断をできるだけ高頻度で実施するのが理想です。しかし、負荷やコストがかかるため、自組織のセキュリティポリシーやサイバー攻撃の流行、システムの状況などに応じて決めることがおすすめです。業務への支障とリスク低減効果を考慮した上で、自組織にとって現実的な実施頻度を検討しましょう。

    BBSecでは

    BBSecでは以下のようなご支援が可能です。 お客様のご状況に合わせて最適なご提案をいたします。

    アタックサーフェス調査サービス

    インターネット上で「攻撃者にとって対象組織はどう見えているか」調査・報告するサービスです。攻撃者と同じ観点に立ち、企業ドメイン情報をはじめとする、公開情報(OSINT)を利用して攻撃可能なポイントの有無を、弊社セキュリティエンジニアが調査いたします。

    詳細・お見積りについてのご相談は、お問い合わせフォームからお気軽にお問い合わせください。お問い合わせはこちら。後ほど、担当者よりご連絡いたします。

    SQAT脆弱性診断サービス

    自ステムの状態を知る

    サイバー攻撃に対する備えとして、BBSecが提供する、SQAT脆弱性診断サービスでは、攻撃者の侵入を許す脆弱性の存在が見逃されていないかどうかを定期的に確認することができます。自組織の状態を知り、適切な脆弱性対策をすることが重要です。

    ウェビナー開催のお知らせ

    最新情報はこちら

    Security NEWS TOPに戻る
    バックナンバー TOPに戻る


    資料ダウンロードボタン
    年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。

    お問い合わせボタン
    サービスに関する疑問や質問はこちらからお気軽にお問合せください。


    Security Serviceへのリンクバナー画像

    BBsecコーポレートサイトへのリンクバナー画像

    セキュリティ緊急対応のバナー画像

    セキュリティトピックス動画申し込みページリンクへのバナー画像

    クロスサイトリクエストフォージェリ(CSRF/XSRF)とは?狙われやすいWebアプリケーションの脆弱性対策

    Share

    Security NEWS TOPに戻る
    バックナンバー TOPに戻る

    今回は、クロスサイトスクリプティング(XSS)のような「大物の脆弱性」と比較すると、一見地味に見えてしまう「CSRF」の意外な危険性について取り上げます。CSRFの脆弱性リスクやXSSとの違い、さらに実際の診断の現場での検出頻度や、見つかった際に行うべき対応、予防策についてもご紹介します。安全なWebサイト運用のために必読です。

    クロスサイトリクエストフォージェリとは

    クロスサイトリクエストフォージェリ(Cross Site Request Forgery)は、Webアプリケーションの脆弱性の一つで、略称「CSRF」とも呼ばれます。読み方は「シーサーフ」です。英語で「Cross」は「X」と表記することがあるため、CSRFを「XSRF」と表記することもあります。

    「クロスサイト」は「Webサイトをまたぐ」という意味で、「リクエスト」はユーザがWebアプリケーションなどに処理を要求すること、「フォージェリ」には「偽造品」などの意味があります。CSRFの脆弱性を悪用することで、ユーザが意図していないリクエストを強制的に行わせることが可能になります。攻撃者は罠として用意した偽造サイトを用いてユーザーに意図しないリクエストを強制的に送信させます。結果として、ユーザーの認証情報を利用した不正な操作や、個人情報の流出が引き起こされる可能性があります。

    クロスサイトリクエストフォージェリとクロスサイトスクリプティングの違い

    クロスサイトリクエストフォージェリと似た名前の脆弱性に「クロスサイトスクリプティング(XSS:Cross Site Scripting)」があります。クロスサイトリクエストフォージェリとクロスサイトスクリプティングは、どちらもサイトを横断(Cross Site)してサイバー攻撃が行われる点が共通していますが、発見される頻度や攻撃による影響、対策方法は異なります。

    • XSS:Webサイトに悪意のあるスクリプトを埋め込む
    • CSRF:ユーザの意図しないリクエストを強制的に実行させる

    脆弱性診断の現場にみるCSRFの実態

    あなたがいまご覧になっているサイト「SQAT.jp」を運営する株式会社ブロードバンドセキュリティでは、日々、さまざまなお客様のシステムに対して脆弱性診断を行っています。

    ブロードバンドセキュリティが2024年上半期に総数3,536のシステムに対して行った脆弱性診断の結果、CSRFを含む「セッション管理関連の脆弱性」は15%のシステムで検出され、その中にCSRFは44%含まれていました。つまりCSRFの脆弱性が存在したシステムは全体の6%になります。ここの数字をどうとらえたらよいのか、このあと、CSRFの攻撃例やリスクを紹介しながら考えていきます。

    CSRFによる攻撃と被害例

    CSRFの脆弱性を悪用した攻撃事例としては、掲示板等に本人が全く意図していない書き込みをさせた例(「遠隔操作ウイルス事件」や「はまちちゃん事件」が有名)があります。

    もしCSRFが脆弱性診断で見つかったら、すぐに対応が必要な場合もあります。特に、個人情報の登録や変更などに関わるログイン後のページで発見された場合は、すぐに修正を行わなければなりません。

    意図しない掲示板の書き込み以外にも、CSRFの脆弱性を悪用すれば、たとえば「サイトAにログインして会員登録を行っているつもりが、実際には攻撃者が罠として用意したサイトBにログインしており、そこで個人情報を抜き取られる」ような攻撃が行われる危険性もあります。もしそうなれば、サイト運営者としての責任が厳しく問われることは間違いありません。

    対策を怠ると他サイトへの遷移ができなくなる可能性も

    また、主要なWebブラウザは、XSSやCSRFなどからの保護のために、脆弱性のあるWebサイトをブラウザに表示させない仕様を整えつつあります。たとえばGoogle Chromeは、Chrome 80以降、サイトを越えてCookie情報をやり取りするためのSameSite属性に対して制限を加え、CSRFを防御可能な設定値のみを許容する方向へと段階的に進んでいます*5 。CSRFを防御可能な設定値については他の主要ブラウザも同様の方向に進んでおり、Webアプリケーション開発においてCSRF対策は(他の対策とともに)取らないわけにはいかないものの一つとなりつつあります。

    セキュリティ企業が見るCSRFのリスクとは

    なお、わたしたちセキュリティ診断サービス会社にとってCSRFとは、一定頻度で検出されるものの、CSRF単体ではそれほどリスクは大きくない脆弱性です。事実、CSRFだけを使った攻撃事例はあまり多くないのです。

    CSRFで注意すべきは、他のサイバー攻撃手法と組み合わされることでリスクや被害が大きくなることです。

    たとえば「セッションフィクセーション」と呼ばれるセッションIDを強制・固定化する攻撃と、CSRFの脆弱性を悪用した攻撃を組み合わせることで、「セッションハイジャック」と呼ばれるサイバー攻撃が成立すれば、セッションの乗っ取りが行われ、オンラインバンキングでの不正送金などにつながる可能性があります。

    CSRFのリスクは低い? 高い?

    CSRFだけを考えてしまうとリスクはそれほど高くないため、対応は後回しにされがちです。しかし実際のサイバー攻撃はそう単純ではなく、いくつもの方法が複合されて行われます。「見つかったらすぐに対応が必要な脆弱性のひとつ」とわたしたちが考える理由がそこにあります。

    CSRFは、単体では攻撃者にとってそれほど使い勝手の良い脆弱性ではありません。しかし、CSRFはいわば、自身では主役は張れないものの、サイバー攻撃の主役を引き立てるために機能する、名脇役のような脆弱性と言えるかもしれません。

    CSRF脆弱性への対策

    最も効果的な対策は「トークン」呼ばれる推測困難な文字列の使用です。

    • ユニークな推測困難な文字列を生成
    • リクエスト時に追加検証
    • PHP、Java、ASP.NETの主要フレームワークで実装可能

    CSRFの脆弱性を悪用した攻撃で最も警戒すべきはログインしたユーザをターゲットとした攻撃になります。この場合、ログインしたユーザからの正しいリクエストであることを証明するために、「トークン」を使って確認を行うことや再度の認証を行うこと*2などで攻撃を防ぐことができます。

    事実、PHP、Java、ASP.NET等の開発言語で提供されている、Webアプリケーションフレームワーク(Laravel、Spring等)は、CSRFの脆弱性を悪用した攻撃を防ぐために、ユニークなトークンを発行する仕組みを持つようになっています。しかし、それでもなおCSRFの脆弱性が見つかることがあるのです。これはどうしてでしょう。

    注意!トークン実装の落とし穴

    フレームワークに機能があっても、実際のコーディング時に1行追加することを忘れがちです。「機能がある=安全」ではありません。

    開発フレームワークがトークンを発行する機能を持っているのにWebアプリケーションでCSRFの脆弱性が発見される理由は、単純そのもので「そもそもトークンを発行するための1行がかかれていない」*3から、ということが多いのです。「機能があるから大丈夫だろう」という思い込みが思わぬリスクを招きます。

    前半で、ブロードバンドセキュリティが行った脆弱性診断の結果、約6%でCSRFの脆弱性が検出されたとお伝えしましたが、リスクを知り、適切な対策を確実に実装することで、この数字をもっと少なくすることができるでしょう。

    まとめ:CSRFは名脇役、されど油断大敵

    • CSRFとは、「シーサーフ」と呼ばれる、攻撃者が罠として用意したサイトを用いて、ユーザが意図しないリクエストを強制的に行わせることを可能にする脆弱性です。
    • CSRFは単独では大きな脅威ではありませんが、他の攻撃手法と組み合わさることで深刻なセキュリティリスクになり得ます。
    • CSRFとXSSは、どちらもサイトを横断してサイバー攻撃を行う点だけは共通していますが、発見頻度やリスク、対策方法は異なります。
    • 定期的な脆弱性診断と、最新のセキュリティ対策が何より重要です。

    Security NEWS TOPに戻る
    バックナンバー TOPに戻る


    資料ダウンロードボタン
    年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
    お問い合わせボタン
    サービスに関する疑問や質問はこちらからお気軽にお問合せください。

    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像