使用浏览器XMLHttpRequest启动与处理器的信用卡交易？

Question

我有一个网站，人们可以在那里购买。

整个网站都配有https。

在第一页上，我接受用户配置文件数据，并为我的客户端生成一个随机ID，并将其存储在我的数据库中。

然后，我将用户ID传递到我的第二个页面，在那里我接受用户信用卡数据。当用户在此页面上提交他们的信息时，我会将XMLHttpRequest发送到我控制的服务器API，发送信用卡数据和用户ID。

然后，该服务器API使用用户ID查询我的数据库，如果找到匹配，则继续将信用卡信息发送到我的支付处理器。实际上，我使用的是用户ID作为API密钥。

信用卡信息永远不会击中我的服务器。由于无法存储API密钥客户端，所以我将生成一次用户ID来验证API调用。我需要更新我的数据库，以便不能再次调用相同的用户ID来验证我的API。

这里安全吗？我在这里的限制是我使用Weebly，我不认为它允许服务器端代码。因此，相反，我想出另一种方法来验证API调用。

这个问题是基于相似问题的

我想先发制人地处理顶部答案中的一些攻击向量：

1)泄露的凭据

这似乎是客户端API调用的主要漏洞。但是，我正在创建一个1次用户ID，这个ID是经过验证的，本质上是一个1次API密钥。因此没有泄漏凭据，因为所有凭据只能使用一次。

2)更改顺序数据

用户数据(例如帐单金额)将根据我的服务器端数据库进行验证。他们唯一能控制的就是他们的信用卡号码和用户ID。

3)被劫持的呼叫

我想没有CSRF可以在这里完成。

4)开放API

我想任何人都可以向我的API发送请求。我可以将我的API白名单到一个特定的IP (尽管网站共享IP)和设置节流。

Answer 1

这可能是一种合理的方法，但它附带的一些条件可能使您无法使用它。

在我开始之前，我想值得一提的是，我在一个PCI ASV/QSA组织工作了多年，并在此期间进行了相当多的PCI评估。我在最新的标准上有点生疏，但我不认为我在这里提到的任何东西都有很大的变化，因为我上次在这方面的工作。然而，我只是一个随机的家伙在互联网上，你应该与您的PCI QSA和付款供应商直接(这可能是您的银行)，以确保适当遵守要求。遵守PCI DSS通常是与您的支付提供者或银行的一项合同义务，如果不采取必要步骤来遵守，可能会导致您违约(或者更糟的是，您的管辖区的数据保护监察员对您进行了调查)。

发布了一个名为确保电子商务安全的最佳做法的文档，我建议您阅读它，因为它是一个非常有用的文档。它概述了最好的选择，为商人谁想有支付设施在他们的网站上，但不想要通过麻烦的PCI DSS认证。

文档调用您提议的"JavaScript表单处理“(参见第2.4节)的方法，它认为它在安全性上大致等同于直接表单POST流程，其中客户将他们的支付信息输入到您的网站上的表单中，并将内容发布到支付提供者。

该文件提供了一个关于如何实现这一点的参考示例。但是，必须指出，它们还声明如下：

使用JavaScript电子商务实现的商家可能有资格获得PCI，前提是他们符合该SAQ的资格标准。商家应与其收购者(商业银行)或付款品牌直接协商，以确定是否需要验证其PCI DSS的遵守情况，以及应使用何种报告方法。SAQ为PCI DSS v3.2目前包括191项要求.

他们的意思是，如果您满足某些要求，您只需通过PCI QSA (合格的安全评估人员)认证为PCI SAQ A-EP投诉，而不是像支付提供商那样对整个PCI DSS进行认证。要求有效地声明，如果您没有触及卡的详细信息，永远不保留任何卡的详细信息，使用符合PCI的支付提供商，并且只控制在直接发送给支付提供商(无论是邮寄还是XMLHttpRequest)之前输入卡详细信息的网页，那么您“只”必须通过PCI获得对较不全面的PCI标准的认证。

最终，这意味着，如果使用直接表单POST或JavaScript表单方法，仍然需要按照SAQ标准进行评估。标准要求概述如下：

• 需求1:安装和维护防火墙配置以保护数据
• 要求2:不要对系统密码和其他安全参数使用供应商提供的默认值。
• 要求3:保护持卡人资料
• 要求4:加密持卡人数据在开放的公共网络中的传输
• 要求5:定期更新防病毒软件
• 需求6:开发和维护安全的系统和应用程序
• 要求7:按业务需要限制对持卡人数据的访问
• 要求8:识别和验证对系统的访问
• 要求9:限制对持卡人数据的实际访问
• 要求10:跟踪和监测对网络资源和持卡人数据的所有访问
• 需求11:定期测试安全系统和流程
• 要求12:维护一项针对所有人员的信息安全的策略

完整的标准详细说明了什么构成了对这些要求的满意遵守。

如果这一切听起来太复杂和昂贵，别担心，因为有其他的选择。如果您查看我链接的最佳实践文档，在第2.2节中，它们描述了一种iFrame方法。在这种方法中，您将支付提供者的支付页面放置在iframe中，从而将支付信息(卡详细信息)输入到一个页面中，该页面的安全来源由于相同的原产地策略(SOP)而无法被运行在页面上的脚本所篡改。这带来了一套大大减少的遵约要求：

使用iFrame电子商务实现的商家可能有资格获得PCI，前提是他们符合该SAQ的资格标准。商家应与其收购者(商业银行)或付款品牌直接协商，以确定是否需要验证其PCI DSS的遵守情况，以及应使用何种报告方法。用于PCI DSS v3.2的PCI SAQ A目前只包含22项要求。

正如您所看到的，您将从191项需求降至22项，这要简单得多，而且成本更低。这也减少了您必须在围栏一侧进行的开发，因为一切都是由支付提供商通过框架处理的。