IT & Information security Journal
ECサイトやWebサービスからの情報漏洩が相次いでおり、クレジットカード番号やセキュリティコードなど、機微な情報が漏洩する事案も散見されます。特に、クレジットカード情報は、2018年に施行された改正割賦販売法にもとづき、ECサイトやWebサービスの運営事業者では事実上、保持しないこと（非保持化）が義務付けられているなか、なぜ漏洩被害が発生してしまうのでしょうか。
本記事では、ECサイトからの漏洩事案を題材として、Webセキュリティの専門家である徳丸浩氏に「なぜクレジットカード情報の漏洩が起こってしまうのか」「ECサイト事業者はどのような対策をとるべきか」「漏洩が発生した場合、どんな流れで対応すべきか」などを伺いました。
この記事のポイント
ECサイトでクレジットカード情報の漏洩事案が発生するのは、ECサイトの利用者がクレジットカード情報を入力する決済画面から情報が窃取（Webスキミング）されるため。攻撃には、JavaScript型の決済代行を狙うものと、画面遷移型の決済代行を狙うものがあり、前者には10年以上同じ手口が使われている
クレジットカード情報の非保持化をしていても、セキュリティ対策は必須。有効な対策としては、脆弱性対応やパスワード管理、WAF導入などのWebセキュリティの基本が最優先。次いで重要なのが改ざん検知であり、導入により漏洩のリスクや被害を大幅に低減できる
クレカ情報の漏洩が発生した場合、ECサイトを一時停止することが最優先。その後、決済代行業者やフォレンジック調査業者と連携しながら対応する。事案の対外的な公表は、クレジットカード会社とECサイト事業者が協議のうえ、同時に行うことが一般的
相次ぐECサイトからのクレジットカード情報の漏洩事案について、その背景をどのように見ていますか。
ECサイトからのクレジットカード情報の漏洩状況について、個人的に手元で集計しているのですが、それによれば近年、漏洩事案の件数そのものは減っているように思われます。たとえば、2021年には72件の漏洩事案が確認されましたが、2023年には35件とほぼ半減しています。2024年も6月末時点で16件と、2023年同時期の20件と比べて減少しており、誤差の可能性を考えても、少なくとも増えていることはなさそうです。
一方で、一般社団法人日本クレジット協会（以下、日本クレジット協会）が発表しているクレジットカードの不正利用による被害額は確実に増加傾向にあります。クレジットカードの不正利用は大きく分けて、偽造クレジットカードによるものと番号盗用によるものがありますが、日本クレジット協会のデータでは、前者の被害額が減少しているのに対し、後者の被害額は2014年以降、年々増加しています。番号盗用の原因としては、フィッシングによるものや原因不明と分類されるものもありますが、日本クレジット協会が開催した過去のセミナーでは「ECサイトからの漏洩が大半」だと説明されていました。
少なくとも、事実として言えることとしては、直近でもECサイトはクレジットカード情報を漏洩するようなセキュリティ被害を受け続けており、また漏洩事案あたりのクレジットカード情報の漏洩件数も多い状況が続いています。
ECサイトを狙ったサイバー攻撃について、特に近年顕著な手口などはありますか。
ECサイトに対する攻撃の手口自体はここ数年大きく変わっていません。そもそも、ECサイト事業者におけるクレジットカード情報の取扱いに関しては、2018年に改正割賦販売法が施行されたことで、事実上、クレジットカード番号等の非保持化が義務付けられています。これにより、決済代行事業者は非保持化を実現するための決済モジュールのみを提供するようになり、ECサイトのほとんどがクレジットカード情報を保持しない仕組みになっているのです。
では、なぜECサイトでクレジットカード情報、それもセキュリティコードを含めた漏洩事案が発生してしまうのか。それは、ECサイトの利用者がクレジットカード情報を入力する決済画面から、情報が窃取されてしまうためです。こうした手口は一般にWebスキミングと呼ばれます。ECサイト事業者のデータベースにクレジットカード情報が保存されておりそれが盗まれるというわけではないのです。
ECサイトのほとんどはクレジットカード情報を保持せず、自社のサーバーも通さずに、決済代行事業者に直接送信します。そこで主流となっている攻撃手法が、JavaScript型という決済代行のシステムを狙った方法です。JavaScript型の決済代行システムは、ECサイト上に決済画面があり、そこに入力された情報を、JavaScriptを用いて決済代行業者に飛ばすという仕組みです。攻撃者はその決済画面に不正なJavaScriptのコードを追加することで、決済代行事業者だけでなく攻撃者にもクレジットカード情報が送信される仕組みにしてしまいます。このため、決済自体の挙動は通常どおりであっても、その裏で情報が漏洩し続ける構図ができあがってしまうのです。決済画面からクレジットカード情報が漏洩する事案のうち7〜8割が、こうした攻撃手法によるものです。
残りの1〜2割の攻撃手法は、画面遷移型（リダイレクト型／リンク型）による決済代行のシステムを狙う方法です。画面遷移型の決済代行システムは、ECサイトでクレジットカード決済のボタンを押すと、決済代行事業者の画面に遷移し、そこでクレジットカード情報を入力するという仕組みです。セキュリティが堅牢な決済代行事業者の画面で情報を入力するため、従来、JavaScript型よりも安全な方法といわれていました。
ところが、攻撃者はその画面遷移そのものを改ざんしてしまいます。具体的には、正規のサイトでクレジットカード決済のボタンを押すと、攻撃者が用意した偽の画面へと遷移する仕組みにしてしまい、その偽画面でクレジットカード情報を入力させるのです。さらに厄介なことに、偽画面で情報を入力・送信させると、エラー画面を表示して、正規の決済画面に遷移させます。購入者はエラーがあったのだと信じて、正規の決済画面でもう一度情報を入力するため、決済自体は正常に行われることとなり、漏洩被害にしばらく気がつくことができないのです。
JavaScript型と画面遷移型の決済代行の仕組みは、どちらも日本クレジット協会がお墨付きを与えている非保持化のための方法ですが、ここまでお話ししたとおり、どちらも破られてしまっているのが現状です。特にJavaScript型を狙った攻撃手法は、非保持化が義務付けられる前から発生しています。割賦販売法改正より5年も前の2013年に起こった国内チェーン企業での顧客情報の漏洩事件 1 以来、10年以上にもわたって同じ手口が使われています。一般的に、「クレジットカード情報を非保持化さえしていれば安全」だと思われがちですが、それが過信されて漏洩被害が続いている状況を、個人的には苦々しい思いをもって見ています。
現在の攻撃手法に対して、「非保持化」は有効な対策ではなくなってしまったということなのでしょうか。
誤解を与えないように言うと、非保持化自体はぜひやるべきことです。私が知る限り、非保持化への対応は改正割賦販売法の施行前からそれなりに進んでいたようにも思いますが、法改正を機に改めて対応したり見直したりする事業者が出てきたのはよい傾向でした。
ただし、日本クレジット協会のクレジットカード・セキュリティガイドライン（以下、ガイドライン）で、非保持化をすればPCI DSS相当の効果があると謳ってしまったのはよくなかったと思います。非保持化をしておけばそのほかのセキュリティ対策をしなくてもいいかのように受け取られてしまいましたが、それは正しくありません。
① 非保持化対策
加盟店におけるカード情報保護のための取組として「非保持化」を推進する。非保持化はPCI DSS準拠とイコールではないものの、カード情報保護という観点では同等の効果があるものと認められるため、本ガイドラインにおいては、PCI DSS準拠に並ぶ措置として整理する。
（出典：一般社団法人日本クレジット協会「クレジットカード・セキュリティガイドライン [1.0版]」（2020年3月））
ECサイト事業者はクレジットカード情報の漏洩を防ぐために、非保持化に加えてどのような対策を行えばいいのでしょうか。
何より、Webセキュリティの基本を押さえることが重要です。脆弱性があれば迅速に対応すること、パスワードの管理を徹底すること、まずはこれらをきちんと継続的に行うべきだと思います。また、WAF（Webアプリケーションファイアウォール）の導入によっても多くの攻撃を防ぐことができます。
ECサイトの脆弱性に関しては、大きく2つに分類できます。まず、オープンソースのECサイト構築パッケージとして人気の高い「EC-CUBE」について、過去のバージョンで脆弱性が存在していました。その古いバージョンがいまも多くのECサイトで使われているのです。また、「EC-CUBE」そのものの脆弱性のほか、導入方法を誤ってしまったことにより情報漏洩が発生するケースもありました。これらの脆弱性を狙った攻撃は現在では減少傾向ですが、少し前までは攻撃者のメジャーな侵入経路でした。
もう１つ、クロスサイトスクリプティング（XSS）の脆弱性も依然として深刻です。ECサイトの管理画面を例に説明します。管理画面は多くの場合、IPアドレス制限をかけているため一般からは見えません。そこで攻撃者はECサイト内にある、商品レビューや問い合わせの入力フォームから、不正なJavaScriptのコードを含んだ文章を書き込みます。管理者が管理画面からその文章を確認しようとすると、不正なJavaScriptコードが実行され、Web画面が改ざんされてしまうのです。
こうした脆弱性を突いてECサイトのシステムに侵入された結果、Webスキミングのための不正なプログラムなどを攻撃者に仕込まれてしまうわけです。
脆弱性への対策としてはどのような方法が有効ですか。
まずは、脆弱性診断の実施をおすすめします。新たに開設されたECサイトでは診断を実施しているかと思いますが、古いサイトでは行われていない可能性があります。最新のガイドラインでも、脆弱性診断をふくむECサイトの脆弱性対策を2024年度末までに必須とすることが求められる、とされており 2、すべてのサイトで脆弱性診断を行うことが強く推奨されます。
またガイドラインでは、ECサイト事業者が決済代行事業者と新規加盟店契約を締結する際には、脆弱性診断の結果を報告しなければならないとされており、決められた報告の書式が用意されています。ただし、書式は一般には非公開とされており、その点は改善が望まれるところです。書式の内容が公表され、あらかじめどのような対策が定められているのかを把握することができれば、ECサイトの作成を委託する開発会社にもその項目を共有でき、申請時に手戻りが発生するような事態を防ぐことができるのではないかと思っています。
ここまで紹介いただいたWebセキュリティの基本的な対策に加えて、実施することが望ましい対策はありますか。
もう1つ有効なのが「改ざん検知」です。これはその名のとおり、Webサイトが改ざんされるとそれを検知し、警告を発する仕組みです。ECサイトからクレジットカード情報が漏洩する攻撃手法には2種類あると言いましたが、入力画面の改ざんもしくは画面遷移の改ざんと、いずれも改ざんを伴います。改ざん検知のシステムを導入することで、攻撃者の侵入があった場合でも迅速に対応でき、たとえば数千件の情報が漏れるかもしれなかったところを数件程度に留めることができるなど、漏洩する情報の件数を大幅に抑えられる可能性があります。
しかし、改ざん検知は導入が進んでいないのが現実です。これは、改ざん検知のシステムがファイルの変更を広く検知してしまうため、ECサイトの商品情報の変更やアップデートといった正常な更新でもアラートされ、現場に大きな負担がかかってしまうことがあるためです。
ECサイトにおいて改ざん検知を実施する場合は、プログラムファイルとそのコンテンツの改ざん検知は最低限やらなければいけません。PHPやHTML、JavaScriptなどのプログラムファイルは必ず改ざん検知を行うべきです。他方、ECサイト上の画像などの情報が改ざんされる可能性も考えられますが、クレジットカード情報の漏洩のようなインシデントに直接結びつくわけではありませんので、運用リソースとの兼ね合いによっては検知対象から外してでも、改ざん検知の仕組みを導入したほうがよいと思います。
改めて、ここまでであげた対策に優先度をつけると、まず脆弱性診断とパスワード管理、WAFの導入が最優先となります。その次に重要なのが改ざん検知であり、工数がかかるものの、導入することで漏洩リスクや被害を大幅に低減できます。具体的な事例として、鹿児島県志布志市のふるさと納税サイトでは、2023年6月に公表された、クレジットカード情報を含む個人情報漏洩事案の後に改ざん検知を導入し、同様のインシデントを発生させないよう取り組んでいます。
ここ数年、決済代行事業者や、EFO（入力フォーム最適化）ツールのような外部サービスからのクレジットカード情報の漏洩事件も発生しました。こうしたサプライチェーン上のリスクについては、EC事業者としてどのような対策をとるべきでしょうか。
まず、決済代行事業者からのクレジットカード情報の漏洩というのは衝撃的な話でした。ECサイト事業者側で取り得る対策としては、安全な決済代行事業者を選択することくらいしかありませんが、安全性をどう判断するかは難しいところです。
外部サービスからの情報漏洩に関しては、少なくとも決済を行う画面には余計なツールを入れないようにしましょう。決済画面は重要な情報を扱います。手堅くシンプルな作りにすることが重要です。
もしも自社のECサイトからクレジットカード情報の漏洩が発生してしまった場合には、どのような対応を行うべきでしょうか。
クレジットカード情報の漏洩が発生した場合、まずはECサイトの一時停止（外部からのアクセス遮断）が最優先です。そして決済代行事業者に指示を仰ぎながら、適切な対応を進めることが求められます。
多くの場合、ECサイト事業者がクレジットカード情報の漏洩に気づくのは、決済代行事業者からの連絡によります。これは、クレジットカード会社が取引内容をモニタリングしており、漏洩の可能性を察知するとまず決済代行事業者に通知するためです。また近年では、警察からの通知も増えています。警察が何らかのモニタリングを行っているのか、一般市民からの通報によるものなのかは不明ですが、2024年に入ってからも、警察からの通知によって情報漏洩が発覚した事件が見られます。
ECサイトを一時停止したあとは、フォレンジック調査を専門業者に依頼します。クレジットカード情報に関するフォレンジック調査は、PCI SSC（※）に認定された業者でなければ行えないため、そうした資格を有する事業者に依頼することとなります。
（※）PCI SSC（PCI Security Standards Council）：国際カードブランド5社により設立された、PCI DSSをはじめとしたクレジットカードに関わる国際的な基準の制定・運用等を行う団体
クレジットカード情報の漏洩が発生した際の対外的な公表については、クレジットカード会社とECサイト事業者が同時に行うことが一般的です。これは主に、クレジットカード会社側での手続などが必要なためであり、ECサイト事業者側が一刻も早く発表したいという善意を持っていた場合でも、対応現場の混乱が生じないよう、基本的には協議のうえ両事業者から公表されることとなります。
しかし最近では、2024年5月に発表された「JFおさかなマルシェ ギョギョいち」のクレジットカード情報を含めた個人情報漏洩事件 3 のように、漏洩した情報の件数が不明のまま独自の判断で早期に発表されるケースも見られます。この場合、顧客が公表された情報を見ても、自分の情報が漏洩しているのか、漏洩の開始時期はいつなのかなどは不明なままです。やはり一般的な流れは、漏洩の可能性を把握したらサイトを一時停止し、フォレンジック調査を経て、その報告を受け次第、迅速に発表することが望ましいと思われます。
クレジットカード情報を守るために、EC事業者はどのような意識を持ってECサイトの運営にあたるべきでしょうか。
「クレジットカード情報は極めて危険なもの」だという認識を持っていただきたいと思います。クレジットカード情報は世界中で悪用できてしまいます。クレジットカードの不正利用による被害額は日本国内では年間約540億円ですが、米国では年間1兆円を超えるともいわれています。
最近では、Amazon PayやPayPayをはじめ、ECサイトでの決済時にクレジットカード情報を扱わずに済むID決済サービス（※）も普及しています。決済方法をID決済サービスだけに絞ることは難しいかもしれませんが、たとえばID決済サービスとクレジットカード決済を併用することで、決済手段が分散し、結果として情報漏洩が発生した際の被害金額や漏洩する情報の件数を減らせる可能性があります。
（※）ID決済：ユーザーが外部サービスで登録しているID・パスワード等の情報を用いて、決済手続を行うことができるサービス
攻撃者からすれば、どのECサイトであってもクレジットカード情報自体が持つ価値は変わりません。そのため、セキュリティ対策が弱いサイトから狙います。つまり、仮に自社のECサイトで保有する個人情報の件数が少なかったとしても、セキュリティ面に不備があれば、攻撃を受ける可能性が十分にあるということです。運営するECサイトの売上や利用者数が一定未満であり、セキュリティリスクや対策コストが上回ってしまうようであれば、ECモールやSaaS型のECサービスを利用するなど、より安全な方法を選択すべきでしょう。
そうした比較検討をしたうえで、やはり自社でECサイトを運営する場合には、「自社の事業を守る」という観点で、脆弱性対策をはじめ先述した数々の対策を必ず実施していただきたいですね。
徳丸 浩
EGセキュアソリューションズ株式会社 取締役 CTO。1985年京セラ株式会社に入社後、ソフトウェアの開発、企画に従事。1999年に携帯電話向け認証課金基盤の方式設計を担当したことをきっかけにWebアプリケーションのセキュリティに興味を持つ。2004年同分野を事業化。 2008年独立して、Webアプリケーションセキュリティを専門分野とするHASHコンサルティング株式会社（現EGセキュアソリューションズ株式会社）を設立。2015年 イー・ガーディアングループに参画。 脆弱性診断やコンサルティング業務のかたわら、ブログや勉強会などを通じてセキュリティの啓蒙活動をおこなっている。著書に、「徳丸浩のWebセキュリティ教室」（日経BP社）「体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践（ソフトバンククリエイティブ）」がある。 EGセキュアソリューションズ株式会社代表、京セラコミュニケーションシステム株式会社技術顧問、独立行政法人情報処理推進機構（IPA）非常勤研究員。技術士（情報工学部門）。 徳丸浩の日記： https://blog.tokumaru.org/ 、 X ID： @ockeghem
（取材・文：小池 晃臣、写真：岩田伸久）
この記事は会員限定です。
登録すると続きをお読みいただけます。
このサイトはreCAPTCHAによって保護されており、
Googleの
プライバシーポリシー
と
利用規約
が適用されます。
UNITISは、IT・セキュリティ担当者へ、実務家・専門家による解説や他社事例等を伝えるメディアです。セキュリティ・法律の専門家による実務解説や分析、第一線の実務家による事例・ノウハウをお届けします。
この記事をシェアする
最新情報をフォローする
