PCI SAQ A 是不是足以用于具有自定义支付页面的电子商务网站?
Posted
技术标签:
【中文标题】PCI SAQ A 是不是足以用于具有自定义支付页面的电子商务网站?【英文标题】:Is PCI SAQ A sufficient for an eCommerce website with a custom payment page?PCI SAQ A 是否足以用于具有自定义支付页面的电子商务网站? 【发布时间】:2014-02-24 10:07:29 【问题描述】:问题 - 我们的付款流程如下:
1 - 客户将商品添加到购物篮。
2 - 查看购物篮时,客户可以看到产品,还可以选择输入送货地址和帐单地址,但不能输入敏感的卡详细信息。
3 - 客户进入我们网站上托管的新页面。客户在此处输入敏感卡详细信息。
4 - 至关重要的是,在按下“订单”时,卡详细信息会直接发布到我们的支付处理器。它们不会先发送到我们的服务器。
我正试图与我的商业银行争论我们属于 SAQ A - 是这样吗?
我的推理:
1) 我们的专用服务器由第三方 PCI 兼容主机管理。
2) 我们从不存储卡的详细信息。
3) 当客户在我们自己托管的网页上输入他们的卡数据时,这是动态生成的,因此仅存在于客户浏览器中。提交订单后,详细信息将直接发布到我们的支付处理器。因此,这些细节永远不会触及我们的服务器,并且 A) 不会作为会话存储在服务器硬盘或数据库中,或者 B) 甚至不会暂时保存在服务器 RAM 中
4) 我们已经通过了来自不同机构的多项 PCI 扫描,以确保我们合规并为服务器提供 SSL、TFA 等
5) 据我所知,这里的两个主要攻击媒介是受感染的客户计算机(不在我们的管辖范围内),或者如果有人设法控制了我们的服务器并改变了结账的工作方式。但这肯定会影响任何电子商务网站,甚至是那些将输入卡片详细信息的页面外包出去的网站(具有服务器访问权限的恶意攻击者可能会重定向到一个假的集合......这几乎是游戏结束了)
但是,SAQ A 的资格标准有点模棱两可(无论如何在我看来)。它指出:
商户不会在商户系统或场所存储、处理或传输持卡人数据,而是完全依赖第三方服务提供商来处理这些功能 *对我来说,“商家系统”可以包括整个结帐的更广泛的元系统。在这种情况下,我们的结帐确实会传输卡的详细信息,尽管我认为这是一种安全的方式。但是,如果“商户系统”是指硬件,那么我们没有任何 POS 系统或服务器来传输详细信息。
我无法从我的合规联络员那里得到直接的答案。有时他们建议我填写 D,然后说它不适合我,所以说填写 SAQ C,然后说这是专门针对“支付应用程序”,例如连接到互联网的物理终端。
我认为我们论证的关键在于,即使我们托管支付页面,卡数据也永远不会到达我们的服务器。
任何帮助将不胜感激。我会提供赏金,但它不会让我自动取款:(
非常感谢您!
【问题讨论】:
问这个@@security.stackexchange.com你可能会更幸运。我的论点是它的用户浏览器将卡的详细信息传输到 PSP,而不是您的系统。您使用的网关 API 是由第三方提供的吗?如果是这样,您可以询问他们的其他客户在合规方面做了什么。 谢谢 Alex K - 我会这样做的。非常感谢。 【参考方案1】:我认为您是对的,您应该能够使用 SAQ A。但是,这是怎么回事 "3 - 客户进入我们网站上托管的新页面。客户在此处输入敏感卡详细信息." 实施了吗?它是完全重定向、iFrame 还是其他?交接会影响事情。请记住,这是您和您的银行之间的事情,如果他们希望您进行 SAQ D,您可能必须进行 SAQ D。
干杯, 内特
【讨论】:
【参考方案2】:很抱歉让您失望了,但您是 A-EP。
对于 SAQ A:贵公司无法直接控制持卡人数据的获取、处理、传输或存储方式 对于 SAQ A-EP:您的电子商务网站不会接收持卡人数据,但会控制如何将消费者或其持卡人数据重定向到经 PCI DSS 验证的第三方支付处理器。“在 Direct Post 实施中,商家网站生成用于接受支付数据的网页,然后将其直接传递给第三方支付处理器。”
https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/Why-is-SAQ-A-EP-used-for-Direct-Post-while-SAQ-A-is-used-for-iFrame-or-URL-redirect
【讨论】:
【参考方案3】:我是新来的,不能评论,
如果我使用第 3 方提供商,我正在尝试自己确定使用 A 或 A-EP 的 SAQ。
所以发现了以下内容: SAQ A:您的页面并非源自您的服务器。您可能有一个购物车和付款按钮,可将客户重定向到托管付款表格的处理器。示例:贝宝快递。
SAQ A-EP:您的页面源自您的服务器,您在其中填写数据并通过邮寄方式提交给第 3 方。只要您的服务器未捕获数据并且 POST 有效负载通过普通表单提交或 JS ajax 直接飞到您的处理器 - 它就是 A-EP。
SAQ-D:您将数据提交到您的服务器。他们可能担心您会记录敏感数据,或将其转发到其他地方等。
恕我直言,SAQ D 对于不存储数据的小型企业来说过于复杂了。
【讨论】:
以上是关于PCI SAQ A 是不是足以用于具有自定义支付页面的电子商务网站?的主要内容,如果未能解决你的问题,请参考以下文章
如果我使用移动支付网关,Cordova 移动应用程序是不是需要 PCI 合规性?
通过不同的 URL 将一些 WL.Client 适配器调用流量重新路由/转移到 WL 服务器(用于 PCI 支付和安全要求)?