【网络安全 | 漏洞挖掘】某教学平台支付逻辑漏洞

未经许可，不得转载。

文章目录

• • 正文

正文

今天要讲述的这一漏洞的主要思路是干扰企业运营的重要环节。其中一项操作便是通过支付规避漏洞，并特别地指的是采用"低价购"策略。

我们的目标应用旨在提供一个在线教育平台，在教师端和学生端两大模块下展开功能布局。在学生端部分中,用户能够按需选择并购买所需课程,随后通过预定的时间段参与相应的学习会议或学习课程内容。该平台涵盖数学、科学、语言艺术设计等多个领域,为用户提供全面的学习资源服务

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

• Skyflowapis（用于加密信用卡信息）
• Payrails（用于启动支付流程）

我们对整个支付流程进行了深入探讨。在流程的起始阶段，在用户输入信用卡信息时（即当用户输入信用卡信息时），系统会向 Skyflowapis 发送一个请求（即系统会向 Skyflowapis 提交一个请求），以加密用户提交的信用卡数据（从而加密用户的信用卡数据）。

随后转向Payrails平台后发现其流程设计异常复杂。随后我们又想知道它又是如何与我们的目标应用进行交互的呢？

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

该查询负责生成一个订单。仅基于教师ID和所需课程数量进行操作。随后，该系统将生成包含订单ID以及金额的一份完整订单记录。

启动初始化PayrailsClient查询，在此之后，目标程序将调用 Payrails，并随后将利用该调用来生成一个用于完成整个支付流程的 JWT token。

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

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

随后我们将该JWT充当Authorization header（授权头），并将剩余的数据字段作为POST数据发送。

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

• 支付比实际请求价格更低的金额，
• 使用负金额，
• 或者执行其他恶意操作。

但是这些尝试均未成功。目标系统持续返回错误提示信息，并拒绝了所有的操作请求：

这一操作中，在修改 payrails POST 数据时，在提交的数据中增加价格字段后，在后端系统中将该价格与 JWT 标识符中的价格值进行对比。

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

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

该系统仅接受参数包括 leadId（老师的 ID）以及课程数量。总价经由后端系统计算得出，在线支付时将展示最终金额。例如，在假设每节课费用为25美元的情况下，则4节课的费用总计100美元。

在完成支付后, 后端系统将对包含在OrderId中的课程数量进行核查, 并确认交易是否成功. 这构成了突破的关键点.

现在调用 initialisedPayrailsClient 为这个 OrderId（包含以下信息：1节课、价格25美元的订单 ID）生成一个 payrails JWT。

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

阻止处理中进行的请求，并在Repeater组件中发起对该操作的请求，并将课程数量设置为4；例如，在当前处理阶段切换到下一个阶段时。

目前我们拥有了一个功能完善的 payrails JWT 中文版, 其中金额是25美元, 而 OrderId 包含4门课程.

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

如图：

看到这里，你就能明白漏洞点的所在之处了：

系统仅校验JWT中的付款金额与请求包内的付款额是否相符，在两者相等时完成交易。
当交易完成时，在确认了订单ID的基础上查询参与课程的数量。即使交易成功，在未核对的情况下也会认为参与课程的数量等于实际选课的数量。

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

该方案具有显著的效果。
该方案通过拆分复杂的逻辑和工作流程来实现支付金额的显著降低。
该方案不仅提升了系统的效率，还减少了资源消耗。
该方案还可以为企业优化财务流程提供参考。