支付頁面安全與E-Skimming防護----淺談PCI DSS v4.0.1要求6.4.3與11.6.1的實施

關鍵詞：支付頁面安全、E-Skimming、PCI DSS v4.0.1、第三方腳本、風險管理、持卡人數據、數據安全、第三方服務提供商、TPSP、內容安全、網頁監控、惡意腳本攻擊

本文為atsec和作者技術共享類文章，旨在共同探討信息安全的相關話題。轉載請注明：atsec和作者名稱。

1 引言

2 當代環境下電商面臨的威脅和風險

2.1 電商平臺的安全隱患

2.2 腳本如何被攻破?

2.3 惡意腳本攻擊方式解析?

2.4 對行業的影響?

3 PCI DSS要求6.4.3和11.6.1介紹?

3.1 要求6.4.3：腳本的授權、完整性驗證、與清單管理?

3.2 要求11.6.1：支付頁面的變更和篡改檢測機制?

4 常見支付頁面場景及其職責劃分?

4.1 常見的支付場景?

4.2 要求6.4.3和11.6.1適用性和職責?

4.3 PCI DSS在電子商務環境中的適用范圍?

5 第三方腳本的風險與管理?

5.1 第三方腳本管理方法?

5.2 第三方腳本風險最小化的最佳實踐?

6 要求6.4.3和11.6.1的控制措施與技術手段?

6.1 內容安全策略（CSP）?

6.2 子資源完整性（SRI）?

6.3 網頁監控?

6.4 基于代理的解決方案?

6.5 表6中所涵蓋的技術手段——第三方腳本風險最小化的最佳實踐?

6.6 其他技術手段?

7 TPSP在此領域的技術幫助?

8 結論?

A 參考資料?

1 引言 ?

????????隨著電子商務的迅猛發展，支付頁面安全已成為保護消費者支付卡數據的核心防線。然而，電子竊取（E-Skimming）攻擊通過注入惡意腳本竊取支付信息的威脅日益加劇，尤其是在高度依賴動態腳本的現代電商環境中。

????????PCI DSS v4.x引入的要求6.4.3和11.6.1旨在通過管理和監控支付頁面腳本，防范此類攻擊，為機構提供明確的合規路徑。要求6.4.3聚焦于腳本的授權、完整性驗證和清單管理，要求11.6.1則強調檢測和響應未經授權的修改。

????????PCI安全標準委員會（PCI SSC：Payment Card Industry Security Standards Council）于2025年3月發布的《支付頁面安全與防止E-Skimming指導》為這些要求提供了詳細的技術實施建議。atsec作為PCI GEAR（Global Executive Assessor Roundtable）成員之一，也積極參與了該指導的提出和編寫工作。

????????atsec顧問此前編寫發布的文章《PCI DSS針對惡意腳本防范的新要求及其方案探討》也提及了這些要求的背景和通用解決方案。本文則進一步聚焦于技術實施細節，結合PCI DSS v4.0.1的最新要求和指導文件，探討機構在控制措施層面的實施和部署建議。

2 當代環境下電商面臨的威脅和風險 ?

2.1 電商平臺的安全隱患 ?

????????當代電商平臺依賴多種腳本（如JavaScript、Web Assembly）實現動態交互功能，例如表單驗證、支付處理和用戶體驗優化。然而，這種依賴性也帶來了顯著的安全隱患。支付頁面腳本可能來源于第一方服務器（由支付機構或者商戶直接控制）、第三方服務器（如服務提供商TPSP：Third-Party Service Provider提供），甚至第四方服務器或者其他機構提供（由第三方加載的額外腳本）。這些腳本在消費者瀏覽器中執行，若被篡改，可能在實體不知情的情況下泄露支付數據。

????????在某些情況下，腳本能夠與網站的敏感部分進行交互，如果這些腳本未獲授權或未受監控，可能會無意中為攻擊者創造可乘之機。例如，用于分析、營銷、使用情況跟蹤、標簽管理、表單驗證或支付處理的第三方腳本可能會被惡意行為者操縱，從而竊取支付數據。

????????特別是第三方腳本，因其不受商戶直接控制，成為攻擊者的主要目標。例如，一個廣告腳本可能通過供應鏈攻擊被注入惡意代碼，進而竊取支付表單數據。這種復雜性和不可控性顯著增加了電商平臺的安全風險。

2.2 腳本如何被攻破 ?

????????腳本可能通過以下方式被攻破：

????????●? ? 供應鏈攻擊：許多電子商務網站依賴第三方服務提供商（TPSP）提供的腳本來實現各種功能。如果攻擊者攻陷了這些第三方腳本，他們就可以在TPSP或商家沒有立即察覺的情況下插入惡意代碼。

????????●? ? 腳本注入攻擊：攻擊者將未經授權的腳本注入到支付頁面中。這些被修改的腳本會捕獲支付詳細信息，并將其傳輸到攻擊者控制的域名。

????????這些類型的攻擊稱為Magecart或Formjacking。由于當代網站在很大程度上依賴腳本來實現其交互功能，攻擊者可能會利用任何在消費者瀏覽器中運行的腳本來竊取支付數據。

????????通過主動管理和監控電子商務腳本，各實體可以降低這些攻擊發生的可能性。雖然此類威脅將持續存在，但可以通過完善的控制措施（包括PCI DSS要求6.4.3和11.6.1中規定的措施）有效地應對這些威脅，這些控制措施實現了強大的腳本授權和完整性檢查。專注于主動的腳本管理使機構能夠在享受使用腳本帶來的優勢的同時，最大限度地減少其暴露于潛在安全問題的風險。

????????當Web瀏覽器遇到腳本時，它會解釋并運行該腳本中的指令。這些指令可以讀取、更改或刪除其他頁面內容，或者響應用戶輸入觸發操作。例如，當消費者點擊某個圖標時，腳本可能會顯示一個菜單，或者允許消費者在頁面上拖動元素。在支付方面，腳本可以：

?????????? ? 檢測消費者何時在支付卡字段中輸入數據。

?????????? ? 識別消費者何時完成數據輸入并移動到下一個字段。

?????????? ? 驗證輸入的支付卡數據，并在驗證失敗時向消費者提供反饋。例如，腳本可以：

? ????????? ?-? ? 更改支付卡字段的顯示方式以指示問題（例如，將輸入字段的邊框更改為紅色）。? ?

? ? ?????????-? ? 顯示一條警告消息，提示數據輸入不正確。

? ????????? ?-? ? 禁用提交按鈕，以防止提交不正確的數據。

????????這些功能可以立即發現輸入錯誤，而無需等待授權失敗。但是，如果支付頁面缺乏適當的保護，惡意腳本也可能捕獲支付賬戶數據并將其傳輸給攻擊者。由于頁面上運行的任何腳本都可能訪問和竊取支付賬戶數據，因此PCI DSS v4.0在2022年引入了兩項新的PCI DSS要求：6.4.3和11.6.1，以幫助預防和檢測未經授權的腳本。

2.3 惡意腳本攻擊方式解析 ?

????????惡意腳本攻擊通常以隱秘或欺騙的方式執行，盡管在不同類型的攻擊中都會盜取支付賬戶數據，但消費者在每種情況下的體驗卻有所不同，以下是兩種常見類型：

????????●? ??靜默攻擊（Silent Skimming）：惡意腳本在后臺運行，消費者和商戶均無察覺，在交易完成時竊取數據。由于其隱秘性，此類攻擊可能長期未被發現。例如，攻擊者可能通過鍵盤記錄腳本捕獲輸入的卡號和CVV2，并將其發送至外部服務器。

????????●? ??雙重輸入攻擊（Double-Entry Skimming）：攻擊者在合法支付表單前插入虛假表單，要求消費者輸入兩次數據，第一次輸入被竊取。此類攻擊因用戶體驗異常（如重復輸入提示），或者是商家在測試網站時發現了異常，相對容易被察覺。例如，偽造的“驗證碼”頁面可能誘導用戶輸入敏感信息。

????????這些攻擊利用了腳本的動態執行能力，如讀取DOM（Document Object Model）元素、修改頁面內容或發起未經授權的網絡請求。

2.4 對行業的影響 ?

????????腳本攻擊可能導致嚴重后果，包括支付數據泄露、監管罰款和品牌聲譽受損。主動管理和監控腳本可顯著降低此類風險。例如，供應鏈攻擊可能通過第三方腳本提供商影響多個商戶，而直接腳本注入則利用網站本身的漏洞（如未修補的XSS：Cross-Site Scripting）。

????????以下是筆者在編寫本文時所獲取的相關安全事件信息，謹供參考：

表1：近年來公開披露的重大腳本攻擊事件

3 PCI DSS要求6.4.3和11.6.1介紹 ?

3.1 要求6.4.3：腳本的授權、完整性驗證、與清單管理

????????PCI DSS要求6.4.3包含三個核心要素——授權、完整性以及包括技術或業務必要性說明的腳本清單，其目標在于從源頭防范“電子竊取”（E-Skimming）等惡意攻擊。根據PCI DSS的要求6.1.1，機構應當編制并管理與第6章相關的安全策略和操作流程，包括為滿足6.4.3而需要的各項措施。同樣地，根據 PCI DSS要求6.1.2，機構應明確執行第6章各項活動的角色和職責，也包括那些與6.4.3相關的活動。所有支付頁面腳本在消費者瀏覽器中加載和執行時，必須做到以下幾點：

????????●? ??授權（Authorization）：必須采取某種方式來確認每個腳本都經過授權。

????????6.4.3的第一個要素要求對每個腳本進行授權。標準本身沒有具體規定授權方式，機構內如何進行或由誰提供授權，該過程是人工或自動完成。

????????鑒于第三方腳本可能在機構毫不知情的情況下被篡改，標準6.4.3的指導欄中特別澄清，授權既可以在腳本新增或變更前執行，也可以在發現腳本發生變更后盡快進行審批或驗證。

????????●? ??完整性（Integrity）：必須采取某種方式來確保每個腳本的完整性，避免其包含未經授權或惡意內容。

????????6.4.3的第二個要素聚焦于腳本完整性，即確保腳本中不包括未經授權或惡意的內容。實現這一點通常需要在以下兩個關鍵時刻進行檢查：

? ????????? ??? ? 當新腳本被引入時。

? ????????? ??? ??當現有腳本被更新時。

????????PCI DSS并不要求機構必須采用某種特定的技術來保證腳本完整性。在標準針對6.4.3和11.6.1的指導欄中，常見的示例方案包括內容安全策略（CSP：Content Security Policy）和子資源完整性（SRI：Sub Resource Integrity），但機構也可以選擇其他能達成相同目標的替代方案，如專門的腳本管理工具等。

????????●? ??腳本清單及必要性說明（Inventory and Justification）：必須維護一個包含所有腳本的清單，并在其中說明每個腳本存在的業務或技術理由。? ?

????????6.4.3的最后一個要素強調在支付頁面中維護一個詳細的腳本清單，并對每個腳本的存在給出業務或技術層面的合理說明。

????????只保留“已知且必需”的腳本，可以有效減少攻擊者可利用的潛在入口。PCI DSS并未規定必須采用何種形式來管理腳本清單：對于簡單環境，一份電子表格可能就足夠；而對于復雜環境，則可使用自動化工具或工作流系統來進行更全面的追蹤與管理。

????????為了滿足PCI DSS要求6.4.3中關于維護腳本清單的要求，以下提供了一個詳細的腳本清單模板。該模板旨在幫助機構記錄和管理所有在支付頁面中使用的腳本，確保每個腳本的存在都有明確的業務或技術理由，并定期進行審核和更新。

表2：腳本清單管理模板（示例）

????????上述針對PCI DSS要求6.4.3中提供的這些措施共同確保支付頁面腳本環境可控，防范E-Skimming攻擊。

????????*另外，對于采用3DS解決方案的商戶，由于在商戶的盡職調查、入駐流程以及雙方業務協議中已建立了內在的信任關系，因此3DS相關腳本無需符合PCI DSS要求6.4.3。但凡用于除3DS功能之外的任何腳本，則必須遵守PCI DSS要求6.4.3。

3.2 要求11.6.1：支付頁面的變更和篡改檢測機制 ?

????????變更和篡改檢測機制的目的是為了及時發現支付頁面中的未經授權修改，從而規避潛在的安全漏洞，并確保機構能夠通過監控HTTP頭和頁面內容的變化來評估影響。

????????●? ??告警功能：檢測到支付頁面中安全影響性HTTP頭或腳本發生未經授權的修改（包括存在被攻擊跡象、內容變更、增加或刪除）時，機制能夠及時向相關人員發出告警。

? ? ? ?????????當檢測到下面情況的時候需要做到及時告警：

? ? ????????? ?? ? 新增：當檢測到新的HTTP頭或腳本被引入時（例如，出現第二個CSP指令或新增一個JavaScript文件）。

? ????????? ? ?? ? 變更：當預期加載在支付頁面的某個HTTP頭或腳本發生了改動，或其行為與之前授權的狀態不一致時。

? ???????? ? ?? ? 刪除：當某個關鍵的HTTP頭（如CSP指令）或防御性腳本被移除時。

????????這些要求旨在預防或盡量減少支付數據被竊取的風險。如果檢測機制僅用于告警而不自動阻斷變更，機構應制定快速響應計劃，確保在收到告警后能夠及時采取糾正措施，從而為機構和客戶提供最佳保護。

????????●? ??評估功能：該機制應配置為對接收到的HTTP頭信息和支付頁面內容進行評估，并與預定基線狀態進行比對。

? ? ? ????????篡改檢測機制必須同時對安全影響性HTTP頭和支付頁面的腳本內容進行評估。可以采用單一機制或多個機制組合的方式，確保整體滿足要求。

????????●? ??檢測頻率：機制的檢測操作應至少每周進行一次，或者根據機構目標風險分析（TRA，參照PCI DSS要求12.3.1中規定的所有要素）定義一個可接受的檢測頻率。

????????PCI DSS要求11.6.1規定，該機制的功能至少每周執行一次。或者，機構可以依據目標風險分析（TRA，參見PCI DSS要求12.3.1）確定一個符合自身風險承受能力的替代檢測頻率。無論機構選擇每周檢測還是其他頻率，都需要注意，在檢測間隔期間，惡意修改可能會在未被發現的情況下持續存在，因此建議在條件允許的情況下，采用更頻繁甚至實時的監控方式。

????????PCI DSS 11.6.1要求認識到未經授權的變更是可能發生的，因此該控制措施并非要求完全杜絕所有未經授權的變更，而是確保一旦發生此類變更，能夠被及時發現并發出警報，以便迅速采取糾正措施。一般情況下，未經授權的變更往往會觸發對要求6.4.3中所涉及的控制措施（授權、完整性、清單及必要性說明）的復查。

????????此外，機構還應明確制定執行PCI DSS要求11（參見要求11.1.2）的各項活動的角色和職責，包括滿足要求11.6.1所需的相關工作。值得注意的是，要求11.6.1本身并未明確規定相應的政策和流程，因此本節特別引用了要求11.1.1，用于指導相關政策和流程的文檔編制。

4 常見支付頁面場景及其職責劃分 ?

4.1 常見的支付場景 ?

????????支付頁面場景的不同直接影響6.4.3和11.6.1的實施責任。下面列出以下場景及職責劃分：

????????商戶托管支付表單：

????????當支付表單由商戶托管時，所有支付數據輸入字段均位于商戶的服務器上。這些字段不位于支付處理方或第三方服務提供商（TPSP）的站點。支付數據可通過多種方式傳輸至支付處理方，但支付表單本身始終由商戶環境加載并控制。下面表格描述了商戶托管支付的常見架構：

表3：常見的商戶托管支付架構

????????嵌入式支付表單（iframe）：

????????通過使用iframe，可以將支付表單嵌入到商戶網站（即父頁面）中。該支付表單可以由TPSP/支付處理方提供，也可以由商戶直接管理，并可通過iframe標簽或JavaScript加載。當使用腳本來創建iframe時，PCI DSS要求6.4.3和11.6.1同樣適用于這些腳本。

? ? ????????? ?? ? 單一文檔或實例（無iframe的支付頁面）

? ????????? ? ?? ? 跨域iframe中的文檔

? ? ? ?????????? ? 分別置于多個iframe中的文檔

????????以下表格展示了三種常見的iframe使用場景，幫助理解支付表單在不同模式下的實現方式：

表4：iframe 示例

????????重定向機制：

????????重定向機制是指將消費者從商戶網站轉移到由支付處理方/TPSP擁有的獨立網站或托管支付頁面。消費者根據商戶網站的設置，跳轉到新的URL、新的瀏覽器窗口或彈出窗口。

????????重定向可通過服務器端配置（例如HTTP 30x重定向）、HTML標簽或JavaScript來實現。當重定向機制中涉及到腳本時，PCI DSS要求6.4.3和11.6.1將適用于這些腳本。

????????完全外包網站：

????????在完全外包的支付場景中，所有支付數據的采集和處理均由支付處理方/TPSP負責。商戶環境不再處理或托管任何支付表單或處理支付數據的腳本。常見的示例包括：商戶向消費者提供支付處理方/TPSP的“支付鏈接”，消費者通過該鏈接直接跳轉到支付處理方/TPSP的網站完成支付。

4.2 要求6.4.3和11.6.1適用性和職責 ?

????????PCI DSS要求6.4.3與11.6.1針對不同的支付解決方案實施方式，對各機構的適用性有所不同。利用“常見支付頁面場景”中描述的各類情形，本節重點闡明了這兩項要求在不同電商場景下的適用情況，并明確了商戶與TPSP在支付頁面腳本安全管理方面的職責劃分。

????????以下表格總結了各類支付頁面場景中商戶和TPSP的職責范圍，幫助機構明確各自的安全管理義務：

表5：PCI DSS 要求6.4.3和11.6.1 - 適用性和職責

????????PCI DSS 要求6.4.3與11.6.1均包含在以下自評問卷（SAQ：Self-Assessment Questionnaire）中：SAQ A-EP、商戶版本的SAQ D以及服務提供商版本的SAQ D，同時這兩項要求也體現在PCI DSS合規報告ROC（Report on Compliance）模板中。

????????需要注意的是，SAQ A不涵蓋要求6.4.3或 1.6.1，但其仍包含針對電商商戶的“資格標準”，即“商戶已確認其網站不易受到可能影響其電商系統的腳本攻擊”。關于SAQ A商戶如何證明其滿足此資格標準，請參閱《小商戶最佳實踐》中的相關說明。

????????同時，即使商戶符合完成自評問卷的條件，適用哪種SAQ也會因電商環境的具體實現方式、商戶在電商環境實施與管理中的參與程度、以及為哪些服務采用了TPSP而有所不同。

????????最終，機構是采用SAQ報告PCI DSS評估結果，還是必須使用QSA提交ROC報告評估結果，由管理合規計劃的相關機構（如收單行、支付品牌或其他相關機構）決定。各機構應與這些機構密切合作，明確自身在合規驗證和報告中的責任與義務。? ?

4.3 PCI DSS在電子商務環境中的適用范圍 ?

????????根據PCI DSS v4.0.1第4章“PCI DSS要求的適用范圍”規定，其范圍包括：

????????●? ??持卡人數據環境CDE（Cardholder Data Environment）包括以下部分：

? ? ????????? ?? ? 存儲、處理或傳輸持卡人數據CHD及/或敏感認證數據SAD（Sensitive Authentication Data）的系統組件、人員和流程；

? ? ????????? ?? ? 雖然不直接存儲、處理或傳輸CHD/SAD，但與存儲、處理或傳輸CHD/SAD的系統組件之間具有無限制連接的其他系統組件。

????????●? ??可能影響持卡人數據及/或敏感認證數據安全性的系統組件、人員和流程。

????????這其中也包括電子商務支付頁面以及嵌入iframe（無論是第三方iframe還是由商戶管理的iframe）的父頁面。

????????許多電商商戶試圖通過不在商戶網頁上存儲、處理或傳輸任何支付賬戶數據來縮小PCI DSS的適用范圍，而是依賴第三方服務提供商（TPSP），通過嵌入TPSP的支付頁面或通過重定向至TPSP頁面來實現支付功能。需要注意的是，PCI DSS要求6.4.3和11.6.1不適用于通過HTTP 30x重定向、meta標簽或JavaScript重定向到TPSP頁面的商戶網站。

????????盡管將TPSP的支付頁面嵌入商戶網頁可能會減少適用于這些網頁的PCI DSS要求，但嵌入第三方支付頁面或表單并不能完全將商戶嵌入頁面（父頁面）排除在評估范圍之外，也不意味著要求6.4.3和11.6.1不適用。關于PCI DSS要求6.4.3和11.6.1在不同自評問卷以及合規報告模板中的適用性和職責劃分，請參見“要求6.4.3和11.6.1——適用性與職責”。

????????多頁應用（Multi-page Applications）

????????傳統的電子商務網站通常采用多頁應用模式：用戶在流程中每個步驟都導航到一個新的URL，每個新頁面均為“全新”加載。此方式會重建瀏覽器環境，從而有效清除前一頁面加載的腳本。在這種多頁設置下，通常只有嵌入了TPSP支付頁面的父頁面需要納入商戶在要求6.4.3和11.6.1中的評估范圍。

????????單頁應用（SPA：Single-page Applications）

????????單頁應用近年來越來越受歡迎，并已占據現代電商網站的較大比例。在SPA中，當用戶進行頁面導航時，瀏覽器不會完全重新加載頁面，而是通過JavaScript動態添加或移除內容。由此，用戶會話期間加載的所有腳本一直駐留在內存中并持續運行。? ?

????????在這種情形下，從瀏覽器的角度看，整個SPA就像是一個連續的“頁面”，包括其中嵌入的支付表單。由于所有腳本都處于同一運行環境中，因此要求6.4.3和11.6.1將適用于單頁應用中的所有頁面（或“視圖”），這也可能影響到嵌入式支付表單的安全管理。

5 第三方腳本的風險與管理 ?

5.1 第三方腳本管理方法 ?

????????第三方腳本的管理具有獨特挑戰，因為這些腳本往往不受使用它們的機構（例如商戶或服務提供商）的直接控制。然而，歷史上這些腳本與竊取支付數據的攻擊（Skimming attacks）密切相關，因此，機構必須充分了解并有效管理這些腳本。

????????如果某個腳本供應商不被視為TPSP，機構就必須建立相應流程來管理這些第三方腳本，包括明確這些腳本的來源、將它們納入機構的管理范圍，并確保按照機構既定的流程來滿足PCI DSS要求6.4.3和11.6.1。

????????機構需要建立一種機制，該機制既能評估HTTP頭信息，也能對腳本內容進行檢測。具體來說，該機制應將當前的HTTP頭和腳本內容與之前已知的版本進行比對，從而發現異常變化。此機制可以僅僅發出告警而不自動阻斷變更，從而為人工迅速介入提供靈活性；或者，如果機制不能實時阻斷變更，機構則應制定快速響應方案，及時處理告警信息。

????????根據機構的技術能力和資源狀況，管理第三方腳本可以采用不同的方法，常見方法包括：

?????????? ? 內部自研工具：利用定制化解決方案來管理第三方腳本，涵蓋腳本白名單、完整性驗證（例如使用哈希比對）以及其他安全控制措施。

?????????? ? 商業與開源解決方案：借助現有技術實現第三方腳本的監控、控制和安全措施的執行。

?????????? ? 混合方法：結合內部工具和外部掃描工具或服務，共同檢測和響應異常情況。

????????這些方法各有優勢，機構可根據實際情況選擇或組合應用，以實現對第三方腳本的全面有效管理。

????????*另外：如果第三方腳本提供商僅提供與支付處理無關、且這些腳本不會影響持卡人數據及/或敏感認證數據安全性的腳本，則該提供商不視為PCI DSS要求12.8和12.9中的第三方服務提供商（TPSP）。

5.2 第三方腳本風險最小化的最佳實踐 ?

????????通過安全控制措施與技術手段，可以構建一個全面的機制來滿足PCI DSS要求6.4.3和11.6.1。雖然PCI DSS主要關注對腳本的管理與監控，以防止未經授權的變更，但本節所述的控制措施可多種方式部署，以應對電子竊取（E-Skimming）及其他針對電子商務網站的威脅。

????????降低腳本數量 ? ?

????????如前所述，要求6.4.3和11.6.1關注支付頁面以及嵌入或影響支付頁面的非支付頁面（或父頁面）。因此，縮小評估范圍的最簡單方法之一是僅保留嚴格必要的腳本。其他補充措施包括：

????????●? ??將腳本移至獨立的iframe：通過使用跨域或沙箱化的iframe，開發者可以將腳本限制在一個與電子商務支付頁面或父頁面相互隔離的受控環境中。經過適當沙箱化的iframe可以限制腳本的功能，防止其與主頁面上的敏感支付元素發生不必要的交互。

????????●? ??限制腳本來源：限制腳本加載的URL是降低風險的另一有效方法。常見做法是采用內容安全策略（CSP），利用如script-src指令來定義允許執行JavaScript的可信來源。或者，也可以采用基于代理的解決方案或基于代理的網頁監控工具，檢測、攔截或管理來自未經授權來源的腳本。

????????●? ??了解并建立腳本行為基線：在隔離環境中測試腳本，觀察其標準行為及輸出，進而限制或密切監控非必要功能。例如，可以使用沙箱環境運行腳本，記錄其網絡請求和DOM操作，建立行為基線。若腳本行為偏離預期（如發起未經授權的請求），則觸發告警或限制其執行。

????????●? ??技術安全評估：定期或持續對第三方腳本進行安全評估，旨在識別潛在漏洞和異常情況。這些評估可以包括靜態代碼審查、行為分析以及運行時監控等手段，以確保腳本始終符合安全要求。

6 要求6.4.3和11.6.1的控制措施與技術手段 ?

????????本節探討一些控制措施與技術手段，它們可以組合使用以滿足要求6.4.3和11.6.1的各個要素（授權、清單、完整性和告警）。這些措施和技術還可用于檢測安全影響性HTTP頭以及支付頁面與非支付頁面腳本中的變更、新增、刪除或可疑行為（例如被攻擊的跡象）。

????????以下表格總結了有助于滿足PCI DSS要求6.4.3和11.6.1的控制措施與技術手段，列出了針對腳本授權、完整性驗證、變更檢測等方面的具體方法，以及與內容：

表6：有助于滿足要求6.4.3 和 11.6.1的控制措施與技術手段

????????表6所述控制措施的詳細說明 ? ?

????????本節的下面介紹了一些安全控制措施，它們可以檢測并在某些情況下預防未經授權的腳本活動，同時向相關利益方發出告警。這些控制措施通過保護支付數據環境來支持PCI DSS要求6.4.3和11.6.1的實施。

6.1 內容安全策略（CSP） ?

????????CSP是瀏覽器自帶的功能，允許網頁應用設置加載和執行內容的策略。雖然CSP在腳本授權以及一定程度上的腳本完整性方面十分有效，但機構仍需配合其他流程，才能全面滿足PCI DSS要求6.4.3和11.6.1的各項要求。

?????????? ? 實施方式：CSP指令可以通過HTTP響應頭（例如Content-Security-Policy）或meta標簽傳遞。通過CSP可以限制腳本加載的來源（script-src指令）以及規定允許加載iframe的來源（frame-src指令）。同時，通過基于哈希值或nonce（一次性令牌）的方式，可以進一步保證頁面上允許執行的腳本的完整性。

?????????? ? 報告功能：CSP可結合HTTP Reporting API（例如report-to、report-uri）使用，以捕捉和報告未經授權的腳本被攔截或違反策略的事件。

????????優點：

?????????? ? 基于瀏覽器原生功能，廣泛支持。

?????????? ? 有助于構建腳本清單、進行完整性檢查，并能部分檢測到未經授權的新增或修改。

?????????? ? 提供了一套違規報告的框架。

????????局限性：

????????機構需要額外實施授權、告警、HTTP頭變更追蹤等流程；例如，僅靠CSP無法生成未經授權腳本的清單或對安全相關HTTP頭的變更發出告警。

?????????? ? CSP不能維護正常活動的基線，其靜態配置無法跨會話追蹤歷史或預期狀態。

?????????? ? 在動態環境中，維護一套健全的CSP（尤其是包含哈希值的配置）具有一定難度。

?????????? ? 除非同時與不允許的域進行通信，否則CSP無法檢測到安全影響性HTTP頭的刪除，也無法確認惡意腳本是否改變了其內部功能。

6.2 子資源完整性（SRI） ?

????????SRI通過將HTML標簽中的哈希值與瀏覽器加載的資源進行比對，幫助確認加載的資源（如腳本）未被篡改。如果比對結果不匹配，則該資源將被阻止執行。

????????優點：

?????????? ? 對靜態腳本配置簡單直接。

?????????? ? 有助于確保第一方腳本以及某些第三方腳本（前提是更新可預測且不頻繁）的完整性。

????????局限性：

?????????? ? 對于頻繁變化或不可預測的動態第三方腳本來說，SRI并不實用。

?????????? ? SRI檢測失敗時不會發出告警，缺乏原生的通知機制。

?????????? ? 不支持違規報告。

6.3 網頁監控 ?

????????網頁監控指的是對支付頁面在消費者瀏覽器（或合成環境）中呈現時進行檢測，以發現惡意或異常的腳本活動。這種監控主要針對客戶端運行的網頁應用，觀察各個腳本與頁面組件及其他瀏覽器資源（如 cookies、local storage等）的交互情況。常見的監控模式有兩種：

?????????? ? 基于代理的監控：在頁面中注入監控腳本，跟蹤DOM變化、資源請求及行為模式。

?????????? ? 無代理監控：采用例如無頭瀏覽器等方式，定期模擬用戶操作，觀察加載的腳本、HTTP頭以及行為，而無需在真實用戶會話中注入額外腳本。

????????優點：? ?

?????????? ? 能夠實時或近實時地洞察實際腳本行為。

?????????? ? 可檢測到意外的表單覆蓋攻擊、可疑的數據外泄等情況。

????????局限性：

?????????? ? 基于代理的解決方案需要集成到每個頁面中，不當的實現可能影響頁面性能或與其他腳本沖突。

?????????? ? 無代理的方案可能在處理驗證碼、登錄或狀態驅動流程時遇到困難，并且依賴于預定的檢查頻率而非持續監控。

6.4 基于代理的解決方案 ?

????????基于代理的解決方案通過在反向代理或內容分發網絡（CDN：Content Delivery Network）邊緣攔截流量，從而在HTML與腳本到達消費者瀏覽器之前對其進行修改或分析。這類方案可以同時監控靜態與動態的腳本引用，強制執行CSP等策略，并能實時攔截未經授權的內容。

????????優點：

?????????? ? 部署時對應用修改要求較低，可作為無代理方案使用。

?????????? ? 通過監控腳本加載情況，可提供完整的腳本清單。

????????局限性：

?????????? ? 配置可能較為復雜，若未優化好可能引入延遲。

?????????? ? 效果取決于檢測算法，可能會產生誤報。

6.5 表6中所涵蓋的技術手段——第三方腳本風險最小化的最佳實踐 ?

????????上面的表6中所列出的幾種技術手段，這些手段可與上述安全控制措施配合使用，幫助機構滿足 PCI DSS 要求6.4.3和11.6.1。常見的技術手段包括：

????????文件哈希：計算腳本的加密哈希值，并驗證腳本內容未發生變化。對于靜態腳本適用，但對于頻繁變動或針對每個用戶定制的腳本則不適用。

????????URL來源限制：利用CSP及其他控制措施對特定域名實施白名單策略，若檢測到可疑的域名使用則發出告警。? ?

????????Nonce（一次性令牌）：CSP可通過nonce授權腳本，即在腳本標簽和CSP頭中插入唯一令牌，若令牌不匹配則阻止腳本執行。nonce能檢測未經授權的腳本，但無法監控授權腳本內部的變更；對于第三方托管的腳本，使用nonce則較為困難。

????????將腳本清單集成到開發流程中：機構可通過自動化持續集成/持續交付（CI/CD：continuous integration/continuous delivery）流水線來維護腳本清單，自動跟蹤和更新授權腳本列表。此過程可以包括對第一方和第三方腳本的驗證檢查，確保僅部署經過批準的腳本，并在腳本上線前進行安全評估，檢測未經授權的變更。

????????手動流程：部分要求（例如維護腳本清單和驗證腳本授權）可通過人工審查、簽字確認或定期網站內容分析來完成，通常作為自動化控制的補充。

????????行為監控：不僅關注腳本的靜態簽名，還監控腳本在實際運行中的行為，例如是否捕捉鍵盤輸入、修改或訪問支付字段、或向未知URL發送數據；當腳本行為偏離授權的正常模式時，系統可觸發告警或直接阻斷。

????????靜態分析腳本監控：定期對從網站或代理處收集的腳本進行掃描，檢測已知的竊取或惡意代碼模式。靜態分析雖然適用，但可能會產生誤報或漏檢經過復雜混淆處理的代碼。

????????防篡改腳本：利用編譯工具對腳本進行轉換或嵌入監測機制，從而檢測或預防惡意修改。不論是在運行前或運行期間，一旦檢測到篡改，腳本可以選擇拒絕執行或觸發告警。

????????以上這些控制措施與技術手段，可以協同作用，幫助機構更好地滿足PCI DSS要求6.4.3和11.6.1的安全控制目標，確保支付數據環境的安全性。

6.6 其他技術手段 ?

????????除了CSP和SRI等技術手段外，還可以引入其他防護技術來增強支付頁面的安全性，本節重點探討一下WAF的應用。

????????WAF在支付安全中的作用

????????WAF（Web Application Firewall）是一種保護Web應用程序安全的設備或服務，部署在應用程序與用戶之間，通過實時分析HTTP流量并阻斷潛在威脅，為支付頁面提供安全屏障。它主要防止攻擊者注入惡意腳本，保護用戶支付數據（如信用卡信息）不被竊取，同時支持合規性要求（如PCI DSS）。

????????核心功能與應用 ? ?

????????●? ??實時防護：檢測并阻斷異常HTTP請求，如包含惡意JavaScript的攻擊，防止其到達應用程序。?

????????●? ??靈活配置：支持自定義規則，例如攔截可疑IP或特定腳本流量，并通過虛擬補丁臨時修復漏洞。?

????????●? ??應用場景：攔截腳本注入、保護敏感數據傳輸、生成合規性日志，幫助滿足PCI DSS 6.4.3和11.6.1要求。

????????配置與優缺點

????????●? ??配置要點：設置規則攔截異常請求、定期更新威脅規則、啟用實時監控和告警。?

????????●? ??優勢：提供實時保護、配置靈活、部署簡便。?

????????●? ??局限性：可能誤報或引入延遲，需結合CSP、SRI等技術優化防護效果。

7 TPSP在此領域的技術幫助 ?

????????提供電商或支付服務的第三方服務提供商（TPSP）可以通過以下方式協助商戶滿足要求6.4.3和11.6.1：

????????●? ??托管支付頁面：將支付頁面內所有代碼的安全控制責任轉移給TPSP。

????????●? ??提供安全SDK：在商戶實現中直接嵌入防護措施，并利用抗篡改腳本提供監控或攔截功能。

????????●? ??提供監控服務：為商戶集成的支付流程跟蹤電商竊取（E-Skimming）指標，及時發現異常行為。

????????●? ??推薦最佳實踐：借助技術專長指導商戶安全嵌入支付表單。

????????商戶應確認TPSP的哪些服務已在其PCI DSS評估范圍內，這通常應在TPSP的PCI合規性聲明（AOC）中有所體現。

????????TPSP需滿足PCI DSS要求12.9.1，即向客戶提供書面協議，并明確承認TPSP對賬戶數據安全負有責任；同時也需滿足要求12.9.2，向客戶提供有關其PCI DSS合規狀態的信息，說明哪些PCI DSS要求由TPSP負責，哪些由客戶負責，以及雙方共同承擔責任的要求。這些責任分工應以清晰的格式呈現，并說明各方如何或是否需要針對要求6.4.3和11.6.1采取相應措施。

????????需要注意的是，提供電商或支付服務的TPSP無法完全解決商戶網站上的竊取風險，因為他們并不完全控制商戶網站。商戶應積極實施完善的機制，評估和管控允許在商戶網頁上執行的腳本。

????????以下簡要提及一下針對不同規模商戶在與TPSP合作時應考慮的最佳實踐：

????????●? ??對TPSP進行評估，確保其具備足夠的技術和控制措施，保障其提供的支付處理服務的安全。

????????●? ??商戶應與TPSP合作，共同確定如何管理和啟動TPSP的支付頁面，從而縮小PCI DSS電商腳本要求的適用范圍。

????????●? ??同時，商戶應與TPSP溝通，獲取關于如何安全實施其解決方案的指導建議。

????????針對小商戶的最佳實踐

????????●? ??選擇提供嵌入式支付頁面或表單（例如一個或多個iframe）的TPSP或支付處理方，并確認按照其說明實施后，其解決方案具備防范腳本攻擊的技術手段。? ?

????????●? ??另外，小型商戶也可以選擇自行實施PCI DSS要求6.4.3和11.6.1中詳細描述的防范措施，以保護其網頁不被針對賬戶數據的惡意腳本攻擊；這些措施可以由商戶自行部署，也可由第三方協助完成。

????????針對中大型商戶的最佳實踐

????????●? ??考察所使用的腳本管理技術，明確如何設計網頁以最大程度降低基于腳本的支付攻擊風險。

????????●? ??實施機制對網頁上執行的腳本進行評估和控制，確保所有腳本符合安全要求，并及時發現異常行為。

????????通過以上措施，商戶在與第三方服務提供商合作時能夠更好地滿足PCI DSS要求，提升整體支付數據環境的安全性。

8 結論 ?

????????PCI DSS v4.0.1的要求6.4.3和11.6.1為電商支付安全提供了系統性的框架。通過授權和驗證腳本、維護動態清單以及監控和響應未經授權的修改，機構可以有效地防范電子竊取（E-Skimming）等威脅。指導文件的技術建議為具體實施提供了清晰的路徑，而針對不同支付場景的職責劃分和最佳實踐則確保了措施的實用性和靈活性。對于所有處理支付卡數據的商戶而言，理解并有效實施這些要求是至關重要的，不僅能夠保護持卡人的敏感信息，避免數據泄露造成的經濟損失和聲譽損害，也是滿足PCI DSS合規要求的必要步驟。

????????atsec期待結合多年來在PCI DSS合規方法論方面的積累，為不同機構提供全面的支持，確保支付頁面以及其他關鍵業務流程的安全性，并提供產業的安全合規。