PCI合规性和Ajax

Question

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

那么,让我们设置场景.A公司符合PCI标准,并且在https上有一个Web服务,在支付处理方面暴露了一些功能.B公司不合规,但他们的网站是安全的.

以下是该方案的步骤.

1. B的网站通过服务器端代码联系A的网络服务.此服务发回加密的验证令牌.
2. B将此令牌注入包含用于接受信用卡信息的表单的页面中.
3. 用户在B的网站上输入他们的信用卡信息.
4. 表单信息以及令牌通过ajax调用发送到A的Web服务.
5. A的Web服务处理数据并吐出状态(已批准/拒绝/等)

问题是,由于javascript直接从用户的机器转移到公司A的兼容服务器,它是否符合PCI标准？我很想知道这个领域的专家是怎么想的.

Answer 1

关于PCI DSS所有PCI标准的小册子

PCI DSS(支付卡行业数据安全标准)具有"范围界定"的概念 - 确定哪些系统属于PCI保护伞.

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

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

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

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

支付应用程序数据安全标准(PA-DSS)如果您将sw出售给商家,那么它可能属于PA-DSS标准的范围.见标准.

PCI是政治性的,而非技术性的,请记住,PCI范围取决于您.如果您是一个足够大的商家,那么您还需要与QSA(合格安全评估员)合作,他们将审核并确定您的PCI合规性和范围界定计划.

QSA当然可以说,因为你控制你的网页,它需要在PCI下,因为它可能被某人破坏.但这将是一个有力的论点.毕竟,你可以说任何互联网商家的每个网页都需要在PCI之下,因为任何网页都可能被破坏,要求人们提供PAN,然后做一些不好的事情.另一方面,这正是Visa用于增加企业特许经营者PCI范围的论点.文章.

PCI认证不是借口还请注意,如果您有闯入,卡协会保留将您解雇的权利 - 即使您符合PCI标准.因此,您希望确定自己比目标中的其他任何人都更加强硬.

补充:有关范围的更多信息从上面可以看出,一个关键问题是哪些系统进出PCI Scope.在PCI委员会现在有一个特别兴趣小组(SIG)检查的这整个问题是什么,什么是出PCI范围.而我的猜测是,他们希望信封能够增长,而不是缩小.

补充:这是您和您的律师之间您的方案已经开始在客户的浏览器上完成PAN处理.PAN永远不会到达您的系统,即使是瞬间.所以我的解释是你没有Merchant PCI DSS范围.但您是签署PCI合规声明的人,这是您与收购方之间的合同.因此,您和您的律师需要解释PCI DSS标准,而不是我.

底线您永远不应该在系统上存储PAN数据.你甚至不应该让它通过你的系统.Authorize.Net和Braintree的新支付网关协议支持非传输技术.根据您的信用卡交易量,PCI合规性从自我管理的清单到大型项目不等.

有关更多PCI战争故事,请查看StorefrontBacktalk博客及其PCI覆盖范围.

Answer 2

Larry K的答案很好.它主要是政治/层面的事情.

似乎使用iframe从B发布到A是一个公认的解决方案,而使用Ajax - 使用CORS或JSONP - 有点更值得怀疑,但至少对于一些大玩家来说,仍然可以接受.

该补充信息:PCI DSS电子商务准则 V2接缝地说,这个解决方案(直接邮寄API)是确定的,但你要小心安全码(虽然PCI DSS并没有规定任何具体的,你需要做的) -请参阅3.4.3.1带有Direct Post的第三方嵌入式API和相关的3.4.3.4共享管理电子商务实现的安全注意事项,其内容如下:

直接后API方法:使用直接后API方法,商家仍然负责呈现给消费者的网页,并且商家托管接收数据的支付页面上的字段 - 仅持卡人数据是直接从消费者发布到服务提供商.由于支付页面由商家托管,因此支付页面仅与商家的网站一样安全,并且商家系统的折衷可能导致支付卡数据的损害....具体而言,对于上述所有情况,商家应监控系统已发生变化的任何证据,并在检测到未经授权的更改时快速响应将系统恢复到受信任状态.采用这些共享管理外包模型以最小化适用的PCI DSS要求的商家应该意识到这些类型的系统架构所固有的潜在风险.为了最大限度地减少这些情况下的攻击机会,商家应该进行额外的尽职调查,以确保Web应用程序的安全开发并经过彻底的渗透测试.

例如,Stripe支付网关自2012年起使用直接发布JSONP而不是之前使用过的iframe方法.

另一方面,WePay还提供直接后API,但建议iframe完全摆脱PCI要求[WP](声称使用直接后API" [..]你仍然需要遵守支付卡行业数据安全标准(PCI-DSS)和支付应用程序数据安全标准(PA-DSS),只要适用. "(未指明"适用时"的确切含义).

[WP] WePay链接: https://www.wepay.com/developer/tutorial/tokenization