
2025年12月初頭、国内企業・団体が運営する約40の電子商取引(ECサイト)を対象とした、不正プログラムを用いた改ざん事件の発生が報じられました。現時点で、30万件以上の顧客情報漏洩の可能性が示唆されています。
本件の原因は、ECサイト(Webアプリケーション)に残存する脆弱性を攻撃者に突かれ、注文フォームなどに利用者情報を窃取するような、不正な文字列(不正なコード)を仕掛けられたことです。
既に、被害を受けた一部の企業がクロスサイトスクリプティング(XSS)の脆弱性が用いられた旨を公表しているほか、OSコマンドインジェクションやSQLインジェクションなどの、不正な入力やリクエストを通じて悪意あるコードやコマンドを実行させる手口が使用された可能性があります。
今後、企業や組織が同様の被害を防ぐためには、サイト全体の網羅的で取りこぼしの無いセキュリティリスクの洗い出しと、それに基づく最適な改善策の実施が必要不可欠です。
本記事では、ECサイトの改ざん事件から考察される被害の原因と、企業・団体が取り組むべき対策について解説します。
目 次
事件の概要:40社のECサイト改ざんで、30万件以上の顧客情報が流出
改めて、事件の概要を振り返ります。
2024年12月初頭、国内の約40の企業・団体にて、それぞれ運営する電子商取引(EC)サイトが改ざんされ、顧客のクレジットカード情報を含む、30万件以上の顧客情報漏洩が示唆される事件が報道されました。
攻撃者側はECサイトの利用者を装い、サイトの注文フォーム等に不正なプログラムを動作させる文字列を入力して「バックドア(裏口)」を設置し、サイトを改ざんしていました。後に、サイト管理者が送信された注文内容を確認すると、顧客のクレジットカード情報などが本来は保存されないサーバーに残るよう、改ざんされていたとのことです。
攻撃者はバックドアからサーバーに保存されたクレジットカード情報などを、2021年から現在まで約3年にわたり、定期的に盗んでいたことが判明しました。
※バックドア…システム内部に不正に侵入するための入口。攻撃者が仕掛けることで、認証システムやセキュリティ対策を回避し、いつでもターゲットのシステムへ侵入できる。
▼攻撃の流れ
- 1. 攻撃者がECサイトの注文フォームなどに、不正な文字列を入力
- 2. サイト管理者が、フォームから注文された情報を確認
- 3. 不正プログラムが発動し、攻撃者がサーバーに「バックドア」を仕掛ける
- 4. 攻撃者は、サーバーに仕掛けた「バックドア」を通じて顧客のカード情報がサーバーに残るようサイトを改ざん
- 5. 顧客がフォームから注文
- 6. 顧客のカード情報が、本来保存されない筈のサーバーへと勝手に保存される
- 7. 攻撃者は、サーバーに仕掛けた「バックドア」を通じて情報を窃取
組み込まれた不正な文字列に、中国の簡体字が含まれていたことから、警視庁などは海外の犯罪グループによる攻撃の可能性を見ています。
そもそも本事件の原因は、各ECサイトに対策されないまま残っていた「脆弱性」が攻撃者に狙われ、不正なプログラムを埋め込まれたことに端を発します。次章では「どういった脆弱性が狙われたのか(どのようなサイバー攻撃が仕掛けられたか)」を見ていきます。
Webアプリケーション診断で指摘される
脆弱性TOP5を解説!
Webアプリのセキュリティ対策は万全ですか?
実際に診断でよく指摘される脆弱性TOP5を
原因や対策方法も含め、分かりやすく説明します。
事件で悪用された可能性がある、脆弱性とは?
報道内容より、本件ではWebアプリケーションの脆弱性を悪用する、以下のサイバー攻撃が用いられた可能性が高いと考えられます。
- ・ クロスサイトスクリプティング(XSS)
- ・ OSコマンドインジェクション
- ・ SQLインジェクション
クロスサイトスクリプティング(XSS)
サイトの入力フォーム内容やボタンを押下した際に送信されるパラメータに、不正なスクリプト(文字列)を埋め込み、サイトを閲覧したユーザーのブラウザ上で実行させるサイバー攻撃です。
正規サイトを利用するユーザーが、攻撃者が用意した不正なスクリプトを意図せず実行させられることで、 CookieやセッションIDなどの認証情報、フォームに入力した個人情報が盗まれたり、フィッシングサイトへ誘導されたりする可能性があります。今回の事件でも、情報漏洩窃取の手段として用いられた可能性が高いでしょう。
▼クロスサイトスクリプティングの手口
クロスサイトスクリプティング(XSS)には反射型と蓄積型の2種類があり、本事件では、サイト管理者が操作した際に不正なスクリプトが実行されたことから、「蓄積型」の手口が用いられたと推測されます。
・反射型XSS…攻撃者が用意した不正なスクリプトを含むURLに、ユーザーがアクセスすると発生する攻撃。URLに不正なスクリプトが含まれるため、ユーザーが攻撃に気づく可能性がある。
・蓄積型XSS…攻撃者が不正なスクリプトをサーバー上に保存(蓄積)し、ユーザーがWebサイトを閲覧するとスクリプトが実行される攻撃。ユーザーは通常操作で不正なスクリプトが含まれる画面にアクセスするため、攻撃を受けたことに気づきにくい。
▼反射型・蓄積型の特徴
項目 | 反射型XSS | 蓄積型XSS |
---|---|---|
影響 | 脆弱性が存在する画面内のみ | 利用者サイトから運用者サイトなど、サイトをまたぐ可能性もある |
検知の難しさ | 入力に対する応答内容から脆弱性の有無を検知可能なため、容易 | サイト仕様の理解が必要なため、検知が難しい |
反射型XSSは入力に対する応答内容から脆弱性の有無を判断できるため、テストツールやWAFなどで比較的簡単に検出が可能。一方の蓄積型XSSは、簡易的な診断やツールでは検知が難しいケースがあります。
OSコマンドインジェクション
Webサーバーへのリクエストに、攻撃者が不正なOSコマンドを注入することで、Webサーバー側に意図しない不正な命令を実行させる手口。Webサイトの入力フォームなどに、不正なOSコマンドを混入して送信します。
今回の改ざん事件でも、注文フォームなどに不正な文字列が入力されていたことから、OSコマンドインジェクションの可能性が疑われます。
▼OSコマンドインジェクションの手口
出典:IPA│安全なウェブサイトの作り方 – 1.2 OSコマンド・インジェクション
SQLインジェクション
WebサイトやWebアプリケーションの脆弱性につけこみ「SQL(データベースを操作するための言語)」を用いて、不正なSQL文を「データベース」へ送り、個人情報の窃取やデータ改ざんなどを行うサイバー攻撃です。
データベースとは「Webサイトで検索や保存を行うための、データの集合体」を指し、ほとんどのWebサイトはデータベースから情報を取得・表示することで稼働・成立しています。
またSQLとは、データベースを操作するための言語であり、Webサイトでデータベースからデータを抽出・表示するには、データベースへSQLによる命令文を送る必要があります。
「SQLインジェクション」は、このSQLを悪用し、不正なSQL文をWebサイトからデータベースへ送ることで、データベースに不正な操作を行います。
▼SQLインジェクションの手口
出典:IPA│安全なウェブサイトの作り方 – 1.1 SQLインジェクション
▼蓄積型XSS / OSコマンドインジェクション / SQLインジェクションの特徴
項目 | 蓄積型XSS | OSコマンドインジェクション | SQLインジェクション |
---|---|---|---|
攻撃の方法 | 悪意あるデータをサーバーへ保存、他のユーザーに実行させる | 不正な入力を通じてOSコマンドを実行 | 不正な入力を通じてSQL文を実行 |
影響範囲 | 複数のユーザーに影響 | サーバーやシステム全体に影響 | データベースに保存されているデータ全体に影響 |
危険度 | 高い | 高い | 高い |
検知の難易度 | 難しい | 易しい | 易しい |
いずれの手口も、Webアプリケーションに対する代表的な脆弱性攻撃であり、ユーザー入力や外部からのリクエストが適切に処理・検証されていないことに起因します。
上記の攻撃を防ぐには、入力・出力の適切な検証やエスケープ処理、エラー処理の適切な実装が必要不可欠です。今回被害を受けたECサイトでは、これらの網羅的な対策が不十分であったと予想されます。
対策していながら、なぜ多くのECサイトが被害を受けたのか?
被害を受けた40社はいずれも、顧客の個人情報やクレジットカード情報を扱うECサイトという特性上、脆弱性に対策するための、何らかのセキュリティ施策が講じられていたと予想されます。
にもかかわらず何故、これほど多くのサイトが被害を受けたのでしょうか?
可能性として、以下の3点が考えられます。
- ・ 脆弱性診断ツールを用いた「簡易的な診断」のみ実施していたため、複雑な脆弱性の検出が困難だった。
- ・ 一般に公開されるユーザーサイトのみ脆弱性診断を実施しており、管理者側・業務側サイトに対して脆弱性診断が実施できていなかった。
- ・ 脆弱性の存在は把握していたが、サイトの仕様や技術的な理由、予算確保などの都合上改修が難しく放置していた。
ツールによる簡易的な脆弱性診断のみ実施、もしくは対象画面に入っていなかった
脆弱性診断には、「ツール診断」と「手動診断」の2つの手法があります。
ツールによる簡易的な診断は、手軽で診断コストが低いというメリットがある一方、サイトの仕様を考慮した精密な検査は難しく、攻撃方法が複雑な脆弱性を見逃しやすいという課題があります。
▼脆弱性診断の比較(手動/ツール)
手動診断 | ツール診断 | |
---|---|---|
診断方法 | セキュリティ専門家が、「手作業」で脆弱性を検査する方法 | 専用のソフトウェアツールを使用して、自動的に脆弱性を検査する方法 |
メリット | ・ツールでは見つけにくい「複雑な脆弱性」や「ビジネスロジックの問題を突いた攻撃」を発見しやすい ・特定のニーズや状況に応じて診断方法を柔軟に変更できる ・誤検知が少ない |
・短時間で広範囲のチェックができる ・手軽に利用でき、診断のコストが低い ・検査手法が確立された、一般に認知されている脆弱性の検出精度が高い |
デメリット | ・診断する担当者のスキルに依存する ・実施に時間がかかり、コストが高くなる場合がある |
・複雑な脆弱性、ビジネスロジックの問題を突いた攻撃等を見逃しやすい ・誤検知の可能性がある ・ツールによっては、大量の指摘事項が検知され、対応の優先度決めや脆弱性管理工数にコストがかかる ・ツールの設定に不備があり、適切な診断ができない可能性がある ・新しい脆弱性に対応できない場合がある |
ツール診断では今回のような、特殊な画面遷移を経る必要がある脆弱性、認証後の画面、特殊な入力パターンを必要とする脆弱性などは、検出の精度が下がる可能性があります。
このようにサイトごとの特性を考慮せずにコストなどを優先して、ツール診断のみに頼ることはリスクが伴います。
脆弱性診断ツールを使用する場合、日常の簡易的な検査は「ツール診断」、サービスリリース前や年に数回の厳密な調査は「手動診断」を行うなど、両者を使い分けることにより、限りあるセキュリティ対策予算で効果的な脆弱性対策が可能です。
管理者側・業務側サイトは、脆弱性診断の対象外になっていた
外部ユーザーに公開されない特性上、管理者や業務担当者が扱う内部サイトの脆弱性診断がされていなかった(ユーザー側のみ診断していた)可能性があります。
「内部関係者による不正は有り得ない」という先入観から、対策が手薄になりがちな内部システムの脆弱性は、攻撃者の格好の標的です。内部サイトを含めた定期的な脆弱性診断と、入力検証・出力エスケープ処理、権限管理の徹底などの対策が欠かせません。
また、脆弱性診断をアウトソーシングする場合は、セキュリティベンダー側に十分なサイト仕様の理解が不足しているケースも考慮する必要があります。例えば蓄積型XSSの場合、脆弱性を埋め込む画面に診断をしていても、脆弱性が発現する画面を診断していなければ脆弱性を見逃してしまう可能性があります。
サイト全体のデータフローや業務フローを考慮し、適切な箇所への脆弱性診断を依頼することで、精度の高い結果につながります。
また、適切な脆弱性診断の依頼範囲の特定が難しい場合には、見積もりから支援してくれるベンダーの選定も重要な要素となります。
脆弱性の存在は把握していたが、放置してしまっていた
脆弱性の存在は把握していたものの、ビジネス要件やシステムの設計上、脆弱性の修正が難しくリスクを放置してしまったパターンです。
短期対策としては、WAF導入などのシステムを変更しない脆弱性対策や監視強化といった代替のセキュリティ対策を実施。
長期的には脆弱性が発見された際の改修計画の立案を含む対応ルールの整備、セキュア開発の導入・強化による設計段階での脆弱性対策、といった対策を講じる必要があります。
いずれも、対策予算の確保や関係者との調整工数などが発生するため、システム担当者レベルではなく会社レベルでの検討が重要となります。
以上の理由から、被害を受けたECサイトは「何らかのセキュリティ対策を実施していたが、対象サイトに対する診断自体ができていなかったり、対策の不備により、被害を防ぎきれなかった」という可能性が示唆されます。
Webアプリケーションの脆弱性を狙った攻撃を防ぐには、脆弱性診断の専門家が知見を活かして行う、質の高い脆弱性診断サービスの利用が推奨されます。
ECサイトを含む、Webアプリケーションの脆弱性診断なら、「LANSCOPEプロフェッショナルサービス」にお任せください
貴社のWebサイト / Webアプリケーションにおける脆弱性診断・対策なら、LANSCOPE プロフェッショナルサービスにお任せください。
今回の改ざん事件で主な原因と考えられる、クロスサイトスクリプティング(XSS)攻撃や OSコマンドインジェクション、SQLインジェクションを含め、あらゆるサイバー攻撃の対象となる Web アプリケーションの脆弱性を、見逃さず検出します。
国家資格をもつ弊社のエキスパートが、手動にてサイト上の脆弱性を網羅的に洗い出し、有効な改善案をお伝えします。診断結果では、自サイトが抱えるリスクを「点数」で可視化できます。
また報告書には、経営層が自社サイトのリスクを把握するためのエグゼクティブサマリー、発見された脆弱性の再現方法、脆弱性の対策・修正提言などが含まれます。PCサイトからモバイルサイト、WebAPIなど、多様な仕様に合わせて脆弱性を明らかにし、優先度をつけて必要な対策をお伝えします。
▼脆弱性診断の報告レポート
「Webサイトを安全に運用したい」「自社サイトのインシデントで、業務停止や信頼損失を起こしたくない」という開発者様・サイト運営担当者様は、ぜひ詳細をご覧ください。
また、診断内容を重要項目に絞り、より低価格でWebアプリケーションの脆弱性診断を受けていただける「セキュリティ健康診断パッケージ」も提供しております。
まとめ
今回のECサイト改ざん事件は、多くの企業が何らかのセキュリティ対策を実施していたにも関わらず、30万件以上の顧客情報が流出するという深刻な被害を招きました。この事例から分かるのは、単に簡易的な脆弱性診断を行うだけでは不十分であり、網羅的な診断と継続的な対策が求められるという点です。
管理者や業務担当者が扱う内部サイトの脆弱性、適切な診断が実施されず検出できなかった複雑な脆弱性など、脆弱性の放置や見落としは、攻撃者にとって格好の標的となり得ます。
企業や団体が顧客からの信頼を維持するためには、セキュリティへの投資を「コスト」ではなく「事業を守るための必要不可欠な施策」と捉え、継続的な対策を講じる必要があります。脆弱性診断においてもコスト重視の自動ツールによる診断だけでなく、専門家による網羅性が高いマニュアルの診断も、検討してみてはいかがでしょうか。

Webアプリケーション診断で指摘される
脆弱性TOP5を解説!
Webアプリのセキュリティ対策は万全ですか?
実際に診断でよく指摘される脆弱性TOP5を
原因や対策方法も含め、分かりやすく説明します。
おすすめ記事