Javascript PCI遵从性和Ajax

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

那么，让我们来设置场景。公司A是PCI兼容的，在https上有一个web服务，公开了支付处理的一些功能。B公司不符合要求，但其网站是安全的

下面是场景的步骤

B的网站通过服务器端代码与A的Web服务联系。此服务发回加密的身份验证令牌

B将此令牌注入包含接受信用卡信息表单的页面

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

表单信息以及令牌通过ajax调用发送到A的webservice

A的Web服务处理数据并返回状态（已批准/已拒绝等）

问题是，既然javascript直接从用户的机器传输到A公司的兼容服务器，它是否兼容PCI？我很想知道这个领域的专家们是怎么想的。

以下是答案

基本上，如果您可能看到卡号或任何有关该卡的识别信息，则需要遵守pci要求。我不确定它们是否一定是“尚未”的法律文件，但如果发现您违反了规定，您处理或参与交易过程的能力可能会被撤销。此外，作为一名商人，你签署了一份关于你的责任的协议，并选择了信用卡公司可以对你罚款的流程。所有这些都是为了获得接受信用卡的特权

为了好玩，这里有一个38页的（pdf）链接。

无论它“技术上”是否符合PCI标准（或不符合），我都不会信任这种做法

如果表单位于B主机名内的页面上，B可以完全访问表单字段中的内容。（如果用户愿意，B的服务器可以向用户发送恶意JavaScript。）

最安全的方法（就保护信用卡号而言）是将表单完全放在支付处理服务的主机名中，而不是放在不受信任的主机名上。

所有

PCI DSS（支付卡行业数据安全标准）具有“范围”的概念，即确定哪些系统属于PCI范畴

您是商家还是软件供应商？ 如果PAN（主帐户号码），即长信用卡号码，从未发送到您的网站，则您的网站通常不在PCI范围内。-假设你是商人。如果您是软件供应商，那么您的软件可能在PA-DSS的范围内（见下文）

平移传输您的服务器 旧的想法是，PAN将被发送到您的网站（通过浏览器表单提交），然后您的网站将转向并将其发送到支付网关（例如Authorize.Net）。在这种情况下，PAN从未存储在您的服务器上，而是传输到您的服务器上。这意味着您的商户系统将不在PCI DSS范围内，因为它们从未存储PAN。但那些日子很快就要结束了，或者已经过去了。（这取决于收单机构/商户账户供应商对PCI的积极程度。）

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

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

支付应用程序数据安全标准（PA-DSS）如果您将软件出售给商家，那么它可能在PA-DSS标准的范围内。看

PCI是政治性的，而不是技术性的请记住，PCI范围取决于您。如果您是一个足够大的商家，那么您还需要与QSA（合格的安全评估员）合作，他们将审查并确定您的PCI合规性和范围规划

当然，QSA可能会说，既然你控制了你的网页，它就需要在PCI下，因为它可能被人破坏。但这将是一个咄咄逼人的论点。毕竟，你可以说，任何互联网商家的每个网页都需要接受PCI，因为任何网页都可能被破坏，要求人们提供一个PAN，然后对它做一些不好的事情。另一方面，这正是Visa用来扩大公司特许人PCI范围的论点

PCI认证不是借口还要注意的是，如果您闯入，卡协会保留将您驱逐的权利，即使您符合PCI标准。所以你要确定你是一个比你所在街区的任何人都更难对付的目标

新增：更多关于范围界定的信息从上面可以看出，一个关键问题是哪些系统在PCI范围之内或之外。PCI委员会现在有一个特别利益小组（SIG）来研究PCI范围内和范围外的整个问题。我猜他们会希望信封变大，而不是变小

添加：这是您和您的律师之间的事您的场景已经开始在客户的浏览器上进行PAN处理。锅永远不会到达你的系统，哪怕是一瞬间。因此，我的解释是，您不在Merchant PCI DSS范围内。但你是签署PCI合规声明的人，该声明是你和收单机构之间的合同。因此，由你和你的律师来解释PCI DSS标准，而不是我

底线永远不要将PAN数据存储在计算机上