對於許多開發者來說，結帳頁面（Checkout Page）只要串接好金流廠商的 SDK 或 iframe，應該就是安全的。但實際上，現代的網頁前端極其複雜，除了支付邏輯，頁面上往往跑著數十個第三方腳本，例如 Google Analytics 追蹤碼、Tag Manager 標記管理工具、客服聊天視窗（Support Widget）等。這些腳本在瀏覽器端擁有極高的權限，而這正是駭客利用的漏洞。
Web Skimming 與供應鏈攻擊的威脅
所謂的 Web Skimming（網頁側錄），是指攻擊者在支付頁面植入惡意程式碼，在使用者輸入信用卡號、有效期與 CVV 的瞬間，將這些敏感資訊偷偷傳送到駭客的伺服器。最危險的是，這種攻擊通常採取供應鏈攻擊（Supply Chain Attack）模式。駭客並不直接攻擊你的網站，而是攻破你信任的第三方套件供應商。
當供應商的腳本被篡改後，你的網站會像往常一樣載入該腳本，對伺服器端來說，請求的來源與路徑都沒有改變，但腳本的行為卻變成了竊取資料。這類攻擊最著名的案例是 Magecart 組織，他們曾導致包括英國航空在內的大量企業遭受巨額損失。
PCI DSS v4.0.1 的新合規要求
為了應對這種新型威脅，支付卡產業資料安全標準（PCI DSS）在 v4.0.1 版本中強化了對前端腳本的管控，重點在於兩個核心要求：
第一是要求 6.4.3。這項規範要求企業必須對支付頁面上運行的所有 JavaScript 腳本建立清單（Inventory），明確定義哪些腳本是被授權的，並且必須能證明這些腳本的完整性（Integrity），確保其未被篡改。
第二是要求 11.6.1。這項規範要求企業必須具備偵測能力，能即時發現瀏覽器接收到的頁面內容或 HTTP 標頭（HTTP Headers）是否被非法竄改。
這對工程團隊來說是一個巨大的挑戰。因為第三方腳本更新頻繁，如果僅僅依賴檔案雜湊值（Hash）比對，只要供應商更新一個小版本，雜湊值就會改變，導致大量的誤報。實務數據顯示，約有 30% 的支付頁面腳本在兩週內會發生變動，手動管理完全不具備可擴展性。
關於 SAQ A 與 iframe 的誤區
許多使用 SAQ A（一種針對將所有支付功能外包給第三方處理商的簡化自我評估問卷）的商家認為自己不需要擔心這些規範。但這裡有一個關鍵的技術陷阱：如果你使用的是嵌入式 iframe 支付框，雖然信用卡資料是在安全框架內輸入，但父頁面（Parent Page）上的惡意腳本仍然可以透過監聽 DOM 事件或劫持輸入流程，在資料進入安全框架之前就將其截獲。
因此，除非你的網站是完全跳轉（Full Redirect）到金流處理商的域名，否則即使使用 iframe，你依然必須證明你的頁面不會受到腳本攻擊，否則仍需符合 6.4.3 與 11.6.1 的管控要求。
實務上的防禦方向
要達成這些合規要求，單純的靜態檢查是不夠的，需要從行為監控（Behavioral Monitoring）著手。有效的防禦機制應該能監控腳本在執行時的行為，例如：這個腳本是否突然嘗試將資料傳送到一個未知的外部域名？它是否在嘗試讀取信用卡輸入欄位的內容？
透過 agentless（無需安裝代理程式）的監控方案，可以在不更動現有程式碼的情況下，即時追蹤所有載入腳本的行為，並在發生異常時立即觸發警報，這才是應對現代 Web Skimming 攻擊且符合 PCI DSS 規範的工程實踐路徑。
來源：thehackernews.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。