本稿では、PCI DSS v4.0.1要件6.4.3、11.6.1でも言及されているWebページ上のスクリプトに関する現状の脅威や管理の課題について解説する。
また、PCI SSC 2025 Europe Community Meetingでも多くのベンダが本テーマを取り扱い、業界注目度も高いといえる。
|
消費者のブラウザに読み込まれ実行されるすべての決済ページスクリプトは、以下のように管理される。 ・各スクリプトが認可されていることを確認するための方法が実装されている。 ・各スクリプトの整合性を保証するための方法が実装されている。 ・すべてのスクリプトのインベントリが、それぞれのスクリプトが必要な理由としてビジネス上または技術上の正当性を示した文書とともに維持される。 |
|
変更・改ざん検知のメカニズムは、以下のように展開されている。 ・消費者ブラウザが受信したセキュリティに影響を与えるHTTPヘッダーと決済ページのスクリプトコンテンツに対する不正な変更(侵害の指標、変更、追加、および削除を含む)を担当者に警告すること。 |
参考：
PCI SSC 2025 Europe Community Meeting 参加レポート｜決済システムに対する新たな脅威とコンプライアンス運用課題
近年の決済情報に関するアタックサーフェスのシフト、攻撃方法のトレンド被害事例等を下記に示す。
EMVチップ付きクレジットカードの普及により、実店舗や券売機などの物理的な決済端末起点でのカード会員データの盗聴が難しくなり、オンラインでの決済情報の盗聴のみで攻撃が完結するECサイトを起点とした攻撃にシフトしている。
前章にて共有した脅威に対して「技術的対策」、「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変更の検知（遮断はできない）が限度となる。 ※技術的には遮断まで可能。ただし、自作のハードルは高く、事実上サードパーティ製のセキュリティスクリプトの利用が必然となる。 |
|
また上記対策でリスクを防げない例を下記に示す。
Polyfill.ioが中国の脅威アクターに買収され、7％のインターネットトラフィックが悪意あるコードを読み込んだ事案がある。CSP設計時には害のないスクリプトだった場合、本仕組みの中では防ぎようがない。予防を考えると、各スクリプトに紐づいたドメインの信頼性を定点的に評価し、評価結果に基づいてCSPを見直す運用が必要となるが、実際攻撃事例が発生してからではなく、脅威アクターとなりえそうな企業に買収されていないかという観点で全てのスクリプトを定点的に監視するのは、中小企業のリソースではハードルが高い。
スクリプトの中には下記のように正規であってもハッシュ値が変わるものも存在するため、SRIがフォルスポジティブを引き起こすケースがある。
|
・動的生成されるスクリプト 多数のJavaScript断片（スニペット）が頻繁に動的生成・差し替えられていることがある。） |
【1】～【3】を有効な予防策として実施するためには下記を実施する膨大な運用コストが必要となる点が課題となる。
下記を考慮した対応が必要になる運用コストが膨らむ。
DOM変更トリガの検知までが限度で、自動遮断の仕組みまで自前で作成する場合は下記を網羅できるような、膨大な脅威パターンの検知やリアルタイムでの対応ロジックの作成が必要なため実質不可能。
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審査の母数が増えていくにつれ、前述した課題が浮き彫りとなり、今後の物議の対象となると著者は予想している。
また、下記実態よりまだまだ被害規模は大きくなっていくと推察される。
前述した内容を踏まえて、今後のセキュリティ業界へ下記影響があると推察する。
[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