关键词：付出页面安全、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合规方法论方面的积累，为不同机构提供全面的支持，确保付出页面以及其他关键业务流程的安全性，并提供财产的安全合规。
A 参考资料
(i)Payment Card Industry Data Security Standard, v4.0.1, June 2024
(ii)Payment Page Security and Preventing E-Skimming - Guidance for PCI DSS Requirements 6.4.3 and 11.6.1 , March 2025
(iii)Mozilla Developer Network. (n.d.). Content Security Policy (CSP)
(iv)PCI SSC 的词汇表https://www.pcisecuritystandards.org/glossary
(v)Third-Party Security Assurance, v1.1, March 2016
(vi)www.atsec.com
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 | 
