EDUSRC支付逻辑漏洞挖掘：思路复盘与实战案例解析

前言

文章旨在分享在EDUSRC平台进行支付类逻辑漏洞挖掘的经验与思路。所有涉及的敏感信息（如目标单位、个人数据、具体URL）均已做多层打码处理。请注意，文章内容仅用于技术研究与学习交流，未经授权的任何攻击行为均属违法。

支付漏洞的成因分析

支付类漏洞本质上是业务逻辑缺陷，在EDUSRC平台通常被评定为中危或高危漏洞，其Rank值也相对可观。这类漏洞的产生主要源于以下几个方面：

1. 参数验证不充分：支付金额、商品数量等关键参数在传输过程中未加密，或加密方式过于简单，后端未与数据库中的记录进行严格比对，导致攻击者可以轻易篡改数据包。
2. 接口安全设计缺陷：支付接口可能暴露订单号、价格等敏感信息，且在传输过程中未加密，使得中间人攻击或参数篡改成为可能。
3. 权限控制与流程逻辑不严：可能存在普通用户越权修改他人订单或支付状态的漏洞。此外，支付流程（如“提交订单→生成订单→支付”的链条）各环节间缺乏有效的关联性验证，攻击者可篡改中间环节数据。系统对异常订单（如支付失败、金额异常）的处理不当，也可能被利用。

在EDUSRC提交此类漏洞报告时，必须提供支付成功并生成有效订单的凭证。

通用挖掘思路与技巧

核心修改点：在抓包测试时，应重点关注并尝试修改以下参数。

• 直接修改类：价格、运费、小费、积分、优惠券金额、商品编号、币种、订单号、支付状态。
• 数值操作类：商品数量（改为负数或小数）、在价格中前移或添加小数点、利用整数溢出或四舍五入规则、并发请求（如同时发起多笔优惠或退款）。
• 越权类：尝试使用他人的支付账户、ID卡或积分完成支付。

实战技巧：

1. 流程全覆盖：不要只测试生成订单的请求，务必跟进整个支付流程。有时前面的请求包仅用于验证，真正的支付金额参数在最后的支付接口中才被处理，且可能缺乏校验。
2. 敢于猜测参数：仔细审查数据包，敢于猜测“补贴金额”、“减免金额”、“优惠金额”等可能存在的参数名，并进行修改测试。
3. 接口替换与重放：
   • 替代支付：生成两个不同价格商品的订单A和B。在支付订单A的请求中，尝试替换为订单B的订单号等关键参数，观察最终支付金额是否变为B的价格。
   • 重放攻击：对支付成功的请求包进行重放，观察是否会生成新订单或造成重复扣款/充值。在支付确认环节，尝试使用Burp Suite的 Turbo Intruder 等工具进行多线程并发请求，测试条件竞争漏洞。
4. 利用数值处理规则：尝试利用系统对小数位的四舍五入逻辑。例如，支付0.009元，系统可能入为0.01元并扣款成功。
5. 优惠策略滥用：测试优惠券ID是否可以重复使用，或特价商品ID是否可绕过限购规则多次下单。
6. 修改支付方式：尝试Fuzz paytype、payway 等表示支付类型的参数，将其修改为不存在的值或代表“免费”、“测试”的枚举值，可能直接绕过支付流程。

实战案例复盘

以下案例均来自近半年的实战挖掘，证明了此类漏洞的持续存在性，关键在于测试者的耐心与细致。

案例一：某高校文创商城-商品数量参数篡改

在提交商品订单时拦截请求，发现存在 prodCount （商品数量）参数。尝试将其修改为负数（如-9999）或0，然后放行。

修改后的请求体JSON结构大致如下：

{
  "dvyType": 1,
  "stationId": "",
  "addrId": 21,
  "orderItem": {
    "prodId": 302,
    "skuId": 840,
    "prodCount": -9999,
    "shopId": 1,
    "distributionCardNo": ""
  },
  "couponIds": [],
  "userChangeCoupon": 0,
  "isScorePay": 0,
  "userUseScore": 0
}

提交后，系统生成了订单。在订单详情页，商品“十年陈天然沉香”的单价为298.00元，但购买数量显示为“-9999件”。系统计算出的商品总额变为一个巨大的负数“-2979702.00元”，加上运费10.00元和少量优惠后，最终订单总额仅为0.01元（推测为系统设置的最小支付值）。此漏洞成功利用，最终被评为中危。在安全/渗透/逆向领域，此类对业务参数进行边界测试的方法非常典型。

案例二：某大学证书系统（一）-直接修改支付金额

在证书项目缴费的支付环节抓包，发现请求体中直接明文传递了 money 参数。将金额从1980.00元修改为0.01元后放包。

PUT /api/payment HTTP/1.1
Host: xxx
Token: 7b45f...
Content-Type: application/json

{"id":"55","infoId":2233,"money":"0.01"}

支付成功后，在“缴费记录”中可查看到对应项目（如“2***化管理第一期”）的支付状态为“未支付”，金额显示为0.01元。该系统因支付金额可被任意修改，最终评定为中危漏洞。

案例三：某大学证书系统（二）-篡改补贴与优惠参数

该系统为在线充值平台，在支付请求的URL参数中发现了两个关键参数：totalSubsidy（总补贴）和 charge（费用/优惠）。

正常的充值10元请求如下：

GET https://example.com/api?walletId=15&totalAmount=500&totalSubsidy=500&charge=-400&return_url=... 

• totalSubsidy：顾名思义为“补贴金额”，将其修改为正数（如500），相当于平台额外赠送对应金额。
• charge：理解为“优惠金额”，将其修改为更大的负数（如-400），则直接从支付金额中减免。

通过修改这两个参数，实现了“支付1元，实际到账10元（本金5元+补贴5元）”的效果。支付成功后，界面显示“支付成功”，商品信息为“用***充值5.00元”。此漏洞被评为高危。

案例四：某高校水电缴费系统-最终支付环节绕过

该系统支付流程较长，产生了多个请求包。初步测试发现，前面所有请求包中的金额参数均有校验或加密，无法修改。但在流程最后，弹出了一个独立的支付确认页面（通常由第三方支付网关或封装页面产生）。

拦截该页面的请求，发现其携带已生成的订单号，但其中的 price 参数仍然明文存在且未经验证。

POST /final-pay HTTP/1.1
...
price=0.01&openId=oq2Gc5neCoROdue...&useragent=we_n

将 price 从10元修改为0.01元后提交，支付成功。后台记录显示，充值金额为10元，但实际支付仅为0.01元，利用的是最终支付环节的校验缺失。此漏洞具有通用性，在多个类似系统中发现，被评为中危。

案例五：某学院缴费系统-Base64编码参数解码篡改

在测试一个固定金额的缴费项目时，发现请求包中的一个参数 details 的值是一串明显的Base64编码字符串。

{
  "c_billType": "z-",
  "c_hide_cx_je": "",
  "redirect": null,
  "plat": "003",
  "type": 1,
  "sno": "34082******4",
  "payway": "OC",
  "paytype": "C",
  "remark": "",
  "details": "W3s1bW9uZ********Vjdg5hbwU1"
}

对该字符串进行Base64解码后，发现其中包含金额等敏感信息。修改解码后的数据中的金额，重新进行Base64编码，再替换回原 details 参数的值，发送请求即可实现任意金额支付。此案例提示我们，对于经过编码的参数，不要轻易放弃，尝试分析其编码方式可能带来突破。

结语

支付逻辑漏洞的利用技术本身并不复杂，其危害在于对业务和资产的直接损害。在运维 & 测试视角下，完善的金额前后端校验、安全的接口设计以及严谨的支付状态机是防御的关键。在EDUSRC场景中，虽然目标业务系统可能相对简单，但只要耐心跟进完整支付流程，大胆猜测和测试参数，仍有机会发现此类安全隐患。希望这些实战思路能为安全测试人员提供有益的参考。

参考资料

[1] EDUSRC-支付类漏洞思路合集（包括证书，小通杀等实例）, 微信公众号：mp.weixin.qq.com/s/iADJW5VlR1oWh5oaP9XaNQ

版权声明：本文由 云栈社区 整理发布，版权归原作者所有。