某教学平台支付逻辑漏洞

漏洞细节

我们的目标应用程序是一个在线教学平台，分为两个主体：教师和学生。学生可以向特定的老师购买课程，然后通过会议/课程的形式使用所购买的内容。教学主题多样，包括数学、科学、语言、设计等各种内容。

该应用程序使用了两个第三方服务来处理支付：

• Skyflowapis（用于加密信用卡信息）

• Payrails（用于启动支付流程）

接下来我们讨论一下整个支付流程。在流程的开始阶段，当用户输入信用卡信息时，会向 Skyflowapis 发送一个请求，以加密用户提交的信用卡数据：

接着来到Payrails，这里的流程设计得非常复杂，那么它是如何与我们的目标应用交互的呢？

首先，流程从以下调用开始：CreateOrUpdateOrder 查询。

这个 CreateOrUpdateOrder 查询会为我们创建一个订单，它只需要教师的 ID 和我们需要的课程数量。然后，它会生成一个带有 orderId 和金额的订单。

接下来，进入initialisePayrailsClient 查询，目标程序会使用刚刚生成的 OrderId 调用 Payrails，并通过以下调用生成一个用于完成支付流程的 JWT token：

这个 JWT（JSON Web Token）在响应中包含以下信息：

它包含了一些数据，特别是金额（amount）。

然后我们将这个 JWT 用作 Authorization header（授权头），并将剩余的数据作为 POST 数据发送。

我在这里尝试了很多种操作，比如：

• 支付比实际请求价格更低的金额

• 使用负金额

• 执行其他恶意操作

但是这些尝试都失败了。目标系统不断返回错误提示，拒绝了我的所有操作：

这说明，当我修改 payrails POST 数据 中的价格时，后端会将提交的 POST 数据中的金额与 JWT 中的金额进行比较。

那还有什么方法能够让金额更低，并同时让我获得更多的课程呢？

回到第一个请求 CreateOrUpdateOrder：生成的 OrderId 接收了什么输入？

它只接收了 leadId（老师的 ID）+ 课程数量。最终价格是在后端计算出来的，如果老师每节课价格是 25 美元，那么 4 节课的价格就是 100 美元。

支付完成后，后端会检查 OrderId 中包含的课程数量，并验证是否支付成功。这就是突破点。

现在使用 initialisePayrailsClient 为这个 OrderId（包含 1 节课、价格 25 美元的订单 ID）生成一个 payrails JWT。

这个 payrails JWT 的值中只包含 25 美元。因为它依赖于 OrderId 的数据。

现在拦截并暂停正在处理的请求，然后在 Repeater 中调用CreateOrUpdateOrder，并将课程数量更新为4，例如：

完成 payrails 支付后，我们将获得 4 门课程，而不仅仅是 1 门。

如图：

看到这里，你就能明白漏洞点了：

• 系统只验证JWT的金额与请求包中的金额是否一致，一致则通过交易。

• 在支付成功后，后端会根据订单 ID 查询课程数量，如果支付成功，系统会认为订单中包含的课程数量是实际购买的课程数量。

我提交了报告，回复和奖励的时间有些晚，但在 2 到 3 天内修复了。