ARTICLE · 1301928
从接口文档到支付逻辑:AI 如何分析业务?
01 编者语
一份API文档，能告诉我们系统有哪些接口，却不一定能告诉我们这些接口之间存在什么关系。
领取优惠券、提交订单、计算优惠金额、完成支付。
这些操作看起来各自独立，实际上共同组成了一条完整的业务流程。
如果只检查单个接口，很难判断整个流程是否存在问题。
这次整理了两份新的漏洞报告。
第一份是Swagger API文档未授权访问，第二份是优惠券与订单支付逻辑异常。
一个提供了系统接口结构，另一个涉及真实的交易业务。
这次我们想从这两个案例出发，讨论一个更具体的问题：
「面对一个陌生的业务系统，如何从接口信息入手，逐步还原业务流程，并找到其中不符合预期的逻辑？」
02 从API文档开始
第一份漏洞报告发现，系统的Swagger API文档接口存在未授权访问问题。
访问对应地址后，可以直接获取 API 文档内容。
文档中包含了大量接口路径。
从接口命名和分组，可以初步识别出用户、教育、直播等业务模块。
对于安全测试来说，这类信息很有价值。
正常情况下，我们需要通过页面交互、前端JS、请求抓包等方式，逐步整理系统提供的接口。
而Swagger文档直接提供了接口路径、请求方法以及部分参数定义。
这相当于多了一份系统功能清单。
不过，接口文档暴露不代表所有接口都可以未授权调用。
我们还需要进一步检查接口的认证要求、请求参数和实际响应。
「API文档解决的是接口发现问题，真正的业务分析还需要继续往下走。」
03 不要只整理URL，还要理解接口关系
拿到一份API文档后，如果只是把所有URL导出成 Excel，其实并没有完成多少业务分析。
真正有价值的是识别接口之间的关系。
例如，一个商城可能存在以下接口：
这些接口单独看，只是系统提供的不同功能。
但放在一起，就能逐步还原出商城的业务流程。
这里有一个值得注意的地方：
接口之间的关联不能只依赖名称判断。
还需要结合请求参数、返回字段、页面操作和实际业务数据。
例如，领取优惠券接口返回的标识，是否会出现在用户优惠券列表中？订单提交接口是否使用了对应的优惠券参数？
这些关系都需要通过实际请求和响应确认。
AI可以怎样参与这一步？
可以先让AI对API文档进行结构化整理。
输出内容不应该只有URL，还应该包括：
接口路径和请求方法； 请求参数及参数类型； 认证要求； 可能所属的业务模块； 与其他接口可能存在的关联； 尚未确认的业务关系。
例如，AI发现多个接口都涉及 coupon，就可以将它们归入优惠券相关功能，再结合参数和响应，寻找领取、查询、使用之间的关系。
但需要注意，接口名称相似不代表它们一定属于同一条业务流程。
AI 可以提出关联假设，最终还要通过真实请求和页面操作确认。
04 还原优惠券业务流程
第二份报告的问题涉及优惠券领取和订单提交。
我们先不急着看漏洞，先把正常业务流程梳理清楚。
用户进入商城后，可以选择商品，也可以领取优惠券。
领取成功后，系统会生成对应的优惠券记录。
接下来选择商品，进入订单确认页面。
最后提交订单，系统根据商品信息和优惠规则生成订单金额。
整个流程可以整理成：
这张图看起来很简单，但它包含了几个需要重点检查的业务关系：
优惠券属于哪个用户？ 优惠券能否用于当前商品？ 优惠券是否已经使用？ 订单金额是否经过服务端重新计算？ 最终应付金额是否符合优惠规则？
这些问题才是业务逻辑测试需要关注的内容。
05 从业务规则中寻找问题
优惠券相关参数与订单提交过程中的异常金额。
商品原价为148元，实际支付17.90元。
为什么会出现这样的金额变化？
这就需要回到优惠券业务本身。
优惠券不是一个简单的参数。
它实际上代表了一项有归属、有使用条件、有有效期的用户权益。
服务端至少需要正确处理以下规则。
1. 优惠券归属
提交订单时，服务端应该确认优惠券是否属于当前用户。
不能只根据客户端传过来的优惠券 ID，就认定用户有权使用。
2. 优惠券有效性
需要检查优惠券是否过期、是否已经使用，以及是否满足商品和活动的使用条件。
3. 优惠金额计算
优惠金额应该由服务端根据商品真实价格和优惠规则重新计算。
不能直接信任客户端提交的价格或折扣金额。
4. 订单与支付状态
订单金额、优惠金额和最终应付金额应该保持一致。
支付成功也必须以可信的支付结果为准，不能只看客户端页面显示。
这几个规则可以作为AI分析业务时的检查清单。
当接口参数、页面操作和业务状态出现不一致时，就可以进一步形成测试假设。
不过，报告中的金额变化只能证明出现了异常订单金额，不能单独证明上述每一项规则都存在缺陷。
06 AI 如何参与业务逻辑分析？
回到本期的主题。
传统接口扫描更多关注单个接口的技术特征。
但业务逻辑漏洞往往藏在不同操作之间。
例如，单独检查订单提交接口，可能只能看到商品 ID、数量和优惠券参数。
如果把它与优惠券领取、用户信息和支付流程关联起来，就能提出更多值得验证的问题。
AI在这类测试中可以承担四项工作。
这里需要强调，AI提出的测试假设不等于漏洞成立。
真正的漏洞仍然需要通过请求、响应、订单记录和业务状态进行验证。
一套可以复用的业务分析方法
面对一个陌生的商城系统，可以按照以下思路开展分析：
获取 API 文档和前端资源
↓
整理接口路径与请求参数
↓
结合页面操作识别业务功能
↓
关联不同接口之间的关系
↓
还原完整业务流程
↓
提取业务规则和约束
↓
生成异常测试假设
↓
人工验证
这套方法不局限于优惠券。
以后遇到积分兑换、会员折扣、余额扣减、订单退款、库存管理等业务，也可以沿用。
例如，分析退款业务时，可以重点关注订单状态、退款次数、退款金额和实际支付金额之间的关系。
分析积分兑换时，可以关注积分归属、扣减记录、兑换数量和重复提交等问题。
业务不同，但分析思路是相通的。
07 本期总结
这次想分享的，不只是两个漏洞。
而是一个测试思路。
面对陌生系统，从API文档和前端资源了解系统有哪些功能。
再结合页面操作和实际请求，整理不同接口之间的关系。
最后根据业务规则，判断系统是否正确处理了用户身份、数据归属、使用条件和金额计算。
AI 可以帮助我们完成大量接口整理和关系分析工作，也可以辅助生成测试假设。
但业务规则是否理解正确，漏洞是否真正成立，仍然需要通过真实业务数据和测试结果来验证。
「从接口中找到入口，从业务流程中理解关系，再从业务规则中寻找异常。」
这可能是 AI 辅助业务逻辑漏洞挖掘中，值得继续研究的方向。
