本稿では、PCI DSS v4.0.1要件6.4.3、11.6.1でも言及されているWebページ上のスクリプトに関する現状の脅威や管理の課題について解説する。
また、PCI SSC 2025 Europe Community Meetingでも多くのベンダが本テーマを取り扱い、業界注目度も高いといえる。
＜表：PCI DSS v4.0.1の引用 上：6.4.3 下：11.6.1＞
|
消費者のブラウザに読み込まれ実行されるすべての決済ページスクリプトは、以下のように管理される。 ・各スクリプトが認可されていることを確認するための方法が実装されている。 ・各スクリプトの整合性を保証するための方法が実装されている。 ・すべてのスクリプトのインベントリが、それぞれのスクリプトが必要な理由としてビジネス上または技術上の正当性を示した文書とともに維持される。 |
|
変更・改ざん検知のメカニズムは、以下のように展開されている。 ・消費者ブラウザが受信したセキュリティに影響を与えるHTTPヘッダーと決済ページのスクリプトコンテンツに対する不正な変更(侵害の指標、変更、追加、および削除を含む)を担当者に警告すること。 |
参考：
PCI SSC 2025 Europe Community Meeting 参加レポート｜決済システムに対する新たな脅威とコンプライアンス運用課題
近年の決済情報に対する脅威｜Magecart攻撃と具体的被害例
近年の決済情報に関するアタックサーフェスのシフト、攻撃方法のトレンド被害事例等を下記に示す。
アタックサーフェスのシフト
EMVチップ付きクレジットカードの普及により、実店舗や券売機などの物理的な決済端末起点でのカード会員データの盗聴が難しくなり、オンラインでの決済情報の盗聴のみで攻撃が完結するECサイトを起点とした攻撃にシフトしている。
攻撃概要
- オンラインでの決済情報の窃取型攻撃を「Magecart攻撃」といい、ECサイトに不正に窃盗用のスクリプトを挿入し、攻撃を実現する。
- カードブランドの調査でクレジットカード詐欺の7割がMagecart関連という統計となっている。[i]
- 攻撃は組織規模に関わらず、中小企業でも多く確認されている。
被害事例
- 初めてこの攻撃が観測された被害事例は2016年初頭で、MagentoというECプラットフォームが被害を受けた。[i]
- 有名な被害事例としては2018年にBritish AirwaysのECサイトが「Magecart攻撃」の被害を受けた。この事件は、英国のGDPRの適用を受けた初めての大規模な事例であり、同規則に基づく罰金処分（Fines）が科された。これはGDPR対応としての先例となり、ECやオンラインサービスにおけるセキュリティ対策の強化が急務であることを社会に広く認識させた。[i]
（当初、British Airwaysには当初の1億8300万ポンド（約230億円）という高額罰金が課せられたが、企業側の迅速な対応と技術的な対策だけでは完全に防ぐことが難しい状況【※2項参照】により、最終的に約1830万ポンド（約26.3億円、2600万ドル相当）まで引き下げられた。） - 2025年前半（上半期）に380,000,000件（3億8千万件）の攻撃が検出。[ii]
防ぎづらい課題｜対策の難しさとPCI DSS対応の問題点
前章にて共有した脅威に対して「技術的対策」、「PCI DSSコンプライアンス観点」、「小規模な加盟店のケイパビリティ」などの課題を下記に示す。
技術的対策の課題
技術的対策のパターンとそれぞれの課題は下記となる。
＜表：技術的対策のパターンと課題まとめ＞
|
No |
|
設定場所 |
不正JavaScript埋め込み時の挙動 |
課題 |
|
【1】 |
CSP（Content Security Policy）の利用
|
HTTPレスポンスヘッダー（推奨）、またはHTMLの<meta>タグ
|
CSPはJavaScriptを読み込むドメインのホワイトリストを設定できる。JavaScriptがホワイトリストにない外部URLから読み込まれようとした場合、ブラウザが読み込みをブロックする。 ※インラインスクリプトも禁止可能。 |
|
|
【２】 |
SRI（Subresource Integrity）の利用
|
HTMLの<script>または<link>タグのintegrity属性 |
SRIは読み込むJavaScriptファイルなどに対してハッシュ値（SHA-256等）を指定できる。ブラウザが実際にロードしたスクリプトのハッシュと照合し、合わなければ読み込み・実行を拒否する。 |
|
|
【３】 |
専用のクライアントサイドエージェントの作成(管理用の専用JavaScript作成) |
HTMLの <head> セクション内に <script> タグとして記述 |
専用のクライアントサイドエージェント次第。一般的にはDOM変更の検知（遮断はできない）が限度となる。 ※技術的には遮断まで可能。ただし、自作のハードルは高く、事実上サードパーティ製のセキュリティスクリプトの利用が必然となる。 |
|
＜図：上記対策パターン【1】～【3】の設定場所のイメージ＞
技術仕様上、利用ができないケース
また上記対策でリスクを防げない例を下記に示す。
具体例①（定義したCSPが意味をなさないケース）：
Polyfill.ioが中国の脅威アクターに買収され、7％のインターネットトラフィックが悪意あるコードを読み込んだ事案がある。CSP設計時には害のないスクリプトだった場合、本仕組みの中では防ぎようがない。予防を考えると、各スクリプトに紐づいたドメインの信頼性を定点的に評価し、評価結果に基づいてCSPを見直す運用が必要となるが、実際攻撃事例が発生してからではなく、脅威アクターとなりえそうな企業に買収されていないかという観点で全てのスクリプトを定点的に監視するのは、中小企業のリソースではハードルが高い。
＜図：具体例①の侵害イメージ＞
具体例②（SRIが利用できないケース）：
スクリプトの中には下記のように正規であってもハッシュ値が変わるものも存在するため、SRIがフォルスポジティブを引き起こすケースがある。
＜表：ハッシュ値が変わるスクリプトの例＞
|
・動的生成されるスクリプト 多数のJavaScript断片（スニペット）が頻繁に動的生成・差し替えられていることがある。） |
＜図：具体例②のフォルスポジティブを引き起こし利用できないケース＞
技術的課題を踏まえた運用の課題
【1】～【3】を有効な予防策として実施するためには下記を実施する膨大な運用コストが必要となる点が課題となる。
【1】CSPや【2】SRIについて
下記を考慮した対応が必要になる運用コストが膨らむ。
- 自社のサードパーティスクリプトを常に一覧化
- サードパーティスクリプトを考慮したCSP・SRIを常に最新化（SRIに関しては利用できる範囲とできない範囲の精査も必要となる）
- CSP登録ドメインの信頼性の定点評価（買収によるドメイン所有者の変更やスクリプトベンダ側のコンテンツ侵害の声明の収集等も含む）
【3】専用のクライアントサイドエージェントを作成について
DOM変更トリガの検知までが限度で、自動遮断の仕組みまで自前で作成する場合は下記を網羅できるような、膨大な脅威パターンの検知やリアルタイムでの対応ロジックの作成が必要なため実質不可能。
- ページ内スクリプトの動作を精密に監視・分析
- 通信APIのフックや不正スクリプトの実行制御を高度に実施
- 必要に応じてページ全体の振る舞いも制御
PCI DSSコンプライアンス観点での課題
PCI DSS v4.0.1においてはCDE（Cardholder Data Environment：カード会員データ環境）の範囲としてそもそも決済ページ以外は対象としないため、前述したアタックサーフェスとなるECサイト内の決済ページではない関連ページに関して評価観点外となる。したがってPCI DSS準拠プログラムの中で対策を講じていても本テーマに対する有効なリスク低減が実装できているとは言い切れず、脆弱な攻撃経路が残る可能性がある。
小規模な加盟店のケイパビリティの課題
・ECサイトの規模に関わらず、決済の処理と承認を目的として消費者からアカウントデータを取得するWebインターフェースを加盟店として持つ場合は、本記事で挙げたスクリプトの対策を実施することが求められる。（例えば決済処理を依拠するためのPSPから提供されたスクリプトを載せている加盟店管理のWebページ等。)
・加盟店のWebページ上でiframeを利用し、決済処理をPSPに依拠する場合も、加盟店が管理するWebページに本記事で挙げたスクリプトの対策が必要と“推察される“が、下記の通りPCI DSS公式ドキュメントの中でどちらともとれる記載があり、断定はできない。
< iframeを利用し決済処理をPSPに依拠した場合の加盟店のWebページ上のスクリプト管理が必須なのかの検討要素>
|
実施すべきと解釈できる要素 |
実施不要と解釈できる要素 |
|
■1つ以上のiframeを含むWeb ページを持つ加盟店はPCI DSS要件6.4.3および11.6.1に記載されているような脅威の保護が求められる。[ⅲ] ■PSPの支払いページ/フォームを埋め込みにより、加盟店の埋め込みページ(親ページ)が要件準拠範囲から完全に削除されるわけではなく、要件6.4.3および11.6.1が適用されなくなるわけでは無い。[ⅳ]
■要件6.4.3および11.6.1の「適用範囲と責任」表にて、iframeを載せる加盟店のWebページ(Non-payment page)上のスクリプトは加盟店の責任と定義されている。
|
■Non-payment pageの定義は「このドキュメントのコンテキストでは、支払いフォームとフォームフィールドを埋め 込むその他のページ。たとえば、iframeを表示するページ。」とあり、iframeを載せる加盟店のWebページはNon-payment pageと定義される。PCI DSS要件6.4.3および11.6.1はPayment pageを主語にした要件であり、iframeを載せる加盟店のWebページは準拠対象外のように見える。[ⅳ] |
・SAQ A（加盟店のWebページ上でiframeを利用し、決済処理をPSPに依拠する構成の場合が多い）構成の場合でも準拠必須なのかどうかにかかわらず、日本においてはJavaScriptでPSPからスクリプトを提供されることも多くこれらは適用対象となるため、小規模な加盟店のECサイトに対するスクリプト対策の実装ハードルは高さが課題となる。上記FAQ[ⅲ]は25年2月、ガイドライン[ⅳ]は25年4月に出ており、これらの指標とした小規模な加盟店のPCIDSS審査の母数が増えていくにつれ、前述した課題が浮き彫りとなり、今後の物議の対象となると著者は予想している。
世の中の実態：ECサイトの技術構造と市場規模
また、下記実態よりまだまだ被害規模は大きくなっていくと推察される。
ECサイトに利用されている外部委託スクリプト数、割合
- ページあたり平均18個、自社マネージドではないスクリプト(主にJavaScript)が利用されている。[i]
- サイト全体で利用されているスクリプトの約82%が外部委託という整理となる。
- 過去2年で50%増加にある。[i]
ECサイト上の決済/それ以外のページのスクリプトの割合
- 2024年の調査では主要7000サイトで支払いページ上のスクリプトは40％で、他は支払いページ外に存在している[i]
市場規模
- EC利用者はグローバルに年間合計20億ページビュー、450億ドルの取引があるとされており、巨大市場となる。[i]
今後の業界動向｜コンプライアンスの進化と対策のアウトソース
前述した内容を踏まえて、今後のセキュリティ業界へ下記影響があると推察する。
- [業界標準全体への影響]本テーマであるクライアントサイドに起因した攻撃は決済情報に関わらず、全てのECサイト利用者が入力する情報全てに流用できてしまうため、他セキュリティフレームや法令準拠(個人情報保護法、HIPPA、GDPR等)においても顧客向けアプリケーション開発要件として本観点での管理ができているかがリスクを考えるうえでの論点として挙がる。
- [PCI DSSの影響]本テーマであるスクリプト管理をどこまで完璧な対策を実施するかについては技術的に防ぎようがない事象やそれらを運用でカバーする際の膨大の運用コストの観点から、明確な指標が出ていない段階。特にiframeを使って決済処理を依拠した小規模な加盟店管理のWebページについて、対応必須かどうか曖昧のため、今後の物議の対象となると予想される。
- [PCI DSSの影響]実態として決済情報への攻撃のアタックサーフェスとなっているためPCI DSS準拠上での確認範囲が決済ページではなく、ほか関連したページ全てに拡大する可能性はある。（コンプライアンス準拠のためではなくリスク対策としては既に実施することが推奨される）
- [セキュリティソリューション市場への影響]対策のための運用コストが課題としてあるため、スクリプト管理をアウトソースできるベンダ、サービスの利用率の増加が予想される。
[i] PCI SSC 2025 Europe Community MeetingのSource Defense社のセクションより引用
[ii] PCI SSC 2025 Europe Community Meetingのc/side 社のセクションより引用
[ⅲ]PCI SSC FAQ 1588：より要約https://www.pcisecuritystandards.org/faq/articles/Frequently_Asked_Question/how-does-an-e-commerce-merchant-meet-the-saq-a-eligibility-criteria-for-scripts/
[ⅳ]「PCI DSS 要件 6.4.3 および 11.6.1 のガイダンス」の「用語」、「電子商取引環境における PCI DSS の適用範囲」、「要件 6.4.3 および 11.6.1 – 適用範囲と責任」より要約
https://docs-prv.pcisecuritystandards.org/PCI%20DSS/Supporting%20Document/Guidance-for-PCI-DSS-Requirements-6_4_3-and-11_6_1-r1-JA.pdf
