javascript - PCI合规性和Ajax

Question

我有这个主意，但是我不确定它是否符合PCI。我是PCI合规领域的新手，很想知道这种情况是否违反PCI。

因此，让我们来设置场景。公司A符合PCI标准，并且在https上具有Web服务，从而公开了围绕付款处理的功能。 B公司不符合规定，但其网站是安全的。

这是该场景的步骤。

B的网站通过服务器端代码与A的Web服务联系。该服务发回加密的认证 token 。

B将此 token 注入(inject)到包含用于接受信用卡信息的表单的页面中。

用户在B的网站上输入他们的信用卡信息。

表单信息和 token 通过ajax调用发送到A的Web服务。

A的网络服务处理数据并返回状态(已批准/已拒绝/等)

问题是，由于javascript直接从用户的计算机转到公司A的兼容服务器，因此它是否兼容PCI？我很想知道这个领域的专家怎么想。

Answer 1

Pamphlet on PCI DSS所有的PCI Standards

PCI DSS(支付卡行业数据安全标准)具有“作用域”的概念-确定哪些系统属于PCI范畴。

您是商人还是软件供应商？
如果PAN(主帐号)(长信用卡号)从未发送到您的网站，则您的网站通常不在PCI范围内。 -假设您是商人。如果您是软件供应商，则您的软件可能属于PA-DSS的范围(请参见下文)。

PAN正在迁移服务器
以前的想法是将PAN发送到您的网站(通过浏览器表单提交)，然后您的网站会转过来并将其发送到付款网关(例如Authorize.Net)。在这种情况下，PAN永远不会存储在您的服务器上，但是会传输您的服务器。过去，这意味着您的商家系统不会存储在PAN中，因此不会在PCI DSS范围内。但是那些日子很快就要过去了，或者已经消失了。 (这取决于您的收单方/商户帐户供应商对PCI的积极程度。)

控制网页由于网页不将任何PAN传输到服务器，因此您不在PCI范围内。但是，您怎么知道有人没有更改您的网页以将PAN发送回您的服务器(或使用JSONP技术的其他地方)呢？答案是，您需要确保自己没有人会篡改您的付款表单页面。

您如何确保自己取决于您自己。您可以使用PCI技术或其他技术。这是内部计算机安全和审核的问题。

付款应用程序数据安全标准(PA-DSS)如果您将SW销售给商家，则可能在PA-DSS标准范围之内。参见standard。

PCI是政治性的，而不是技术性的请记住，PCI作用域取决于您。如果您足够大，那么您还需要与QSA(合格的安全评估员)合作，后者将审核并确定您的PCI合规性和范围界定计划。

QSA可能会说，由于您控制网页，因此它必须在PCI下，因为它可能被某人破坏。但这将是一个棘手的论点。毕竟，您可以说任何互联网商人的每个网页都必须在PCI下，因为任何网页都可能被损坏，要求人们提供PAN，然后对其进行不良处理。另一方面，这恰恰是Visa用于增加公司特许人的PCI范围的一种论点。 Article。

PCI认证不是借口另外请注意，即使您有闯入行为，即使您符合PCI规范，卡协会也保留将您踢出市场的权利。因此，您要确保自己比目标上的其他任何人都坚强得多。

已添加:有关作用域的更多信息从上面可以看出，一个关键问题是哪些系统在PCI范围之内或之外。 PCI委员会现在有一个特殊利益小组(SIG)，负责研究PCI范围内和范围之外的整个问题。我的猜测是，他们希望信封增加而不是缩小。

已添加:它在您和律师之间您的方案已开始在客户的浏览器上完成PAN处理。 PAN永远不会到达您的系统，甚至一瞬间也不会到达您的系统。因此，我的解释是您不在Merchant PCI DSS范围内。但是，您是签署PCI合规性声明的人，这是您与收单方之间的一项契约(Contract)。因此，由您和您的律师来解释PCI DSS标准，而不是我。

底线永远不要在系统上存储PAN数据。您甚至都不应该让它传输系统。 Authorize.Net和Braintree推出的新的Payment Gateway协议(protocol)启用了非传输技术。根据您的信用卡交易量，PCI合规性从自我管理的 list 到庞大的项目不等。

有关更多PCI war 的故事，请查看StorefrontBacktalk博客及其PCI coverage。