某SRC App逻辑漏洞实战：短信轰炸、SSRF、越权与VIP无限重放

前言

记录一下之前在某个 SRC 上挖 APP 逻辑漏洞的一些思路，主要以逻辑漏洞为主。

挖掘思路

拿到一个 APP，先要把整个业务逻辑摸清楚，后面才好动手。下面按危害从低到高，把完整挖掘过程走一遍。

短信轰炸

打开 APP，第一屏就是熟悉的登录页面。

这里可以先测短信轰炸、任意用户登录等基础问题。实测发现，短信轰炸确实存在。

填入手机号后点击“获取验证码”，抓包如下：

POST /user/getCode HTTP/1.1
Host: xxx
User-Agent: SM-G9810 Android25 V1.9.0.1
Platform: android
Appversion: 1.9.0.1
Showtest: 0
Oaid: 
Vaid: 
Aaid: 
Imei: 
Androidvendors: samsung
Originalua: Mozilla/5.0 (Linux; Android 7.1.2; SM-G9810 Build/N2G48H; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/75.0.3770.143 Mobile Safari/537.36
Accept: application/vnd.edusoho.v2+json
Appbizsource: 0
Content-Type: application/x-www-form-urlencoded
Content-Length: 28
Accept-Encoding: gzip, deflate
Connection: close

phone=13555555555&codeType=1

这里直接修改 phone 参数，用上面的数据包重复发送，就能打出短信轰炸。

登录页测完之后，进入 APP 继续看其他功能。

无回显 SSRF

进入 APP 后，留意到“意见反馈”这个位置。

意见反馈里有图片上传功能，抓包看看是不是通过 URL 传图片。

对应数据包如下：

把 image 参数的 URL 先换成自己的 VPS，测试是否能请求外部地址。

VPS 上确实收到了请求。后来 SRC 给了 SSRF 测试地址，打过去之后截图保存时间，提交给审核验证了。

越权

越权评价他人订单

APP 内的服务内容，通常是用户下单后获取对应内容。这个过程中发现评价订单接口存在越权。

这里下单后先不用付款，付款当然也可以。之前这个 APP 不付款也能直接拿到评价接口。

进入订单详情，点击“去评价”，填写内容后发表，然后用 Burp 抓包。

可以看到，我们虽然点了“去评价”，但因为没付款、服务未结束，所以无法评价。不过可以注意到 orderId 的值只有六位数，很容易遍历。于是开始遍历。

遍历后可以看到，能对其他人创建的订单进行服务评价。

越权使用他人优惠券

选一个服务下单并抓包。

数据包如下：

之前我们是新用户时，系统自动赠送过一张优惠券，当时优惠券 ID 是 couponId=1085908。猜测优惠券 ID 同样可以遍历。

抓包后手动添加 couponId=1085907，然后放包。

来到订单处，可以看到已经成功使用了别人的新用户 5 折券。

信息泄露

下单服务前可以进行沟通，聊天页面如下：

Burp 中抓包如下：

数据包中直接泄露了服务者的手机号。服务内容本来是通过虚拟号码电话进行，但这里明文返回了服务者真实手机号。并且 imId 也可以遍历。即使不遍历，点开任意聊天框，传入上面的数据包，也能直接确定对应手机号。

后续

目标 APP 在被提交了上面多个漏洞后做了签名加固防篡改。假设我们不做签名绕过，还能不能继续挖到漏洞？还能挖到高危吗？

挖掘思路

答案是可以。

付费内容泄露

平台上有一些 VIP 才能使用的服务课程，如下图：

但实际上，刚进入上面的页面时，Burp 抓到的数据包里，就已经包含了 VIP 课程需要使用的 mp3 网络链接。

课程内容直接挂在阿里云服务器下，不用充值 VIP 就能直接访问使用。

无限刷取网站 VIP

APP 上有一处“邀请有礼”。

点击“邀请有礼”会获得一张邀请截图，扫码后可以得到下面的 URL：

https://test.com/cashback/investMidPage?userId=950485&sourceId=6&userRole=1

把上面的 URL 发送到微信中，点击链接会跳转到小程序。

填完账号后会提示“邀请绑定成功”。绑定成功后，Burp 数据包中会有一条下面这样的请求：

POST /applets/userRegister?sign=B43369DA38154CD9757706E3B709682C×tamp=1729442602682 HTTP/1.1
Host: xxx
Content-Length: 110
Devicetype: 0
Xweb_xhr: 1
Usertoken: 
Usepaltform: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36 MicroMessenger/7.0.20.1781(0x6700143B) NetType/WIFI MiniProgramEnv/Windows WindowsWechat/WMPF WindowsWechat(0x63090c11)XWEB/11275
Content-Type: application/json
Accept: */*
Sec-Fetch-Site: cross-site
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: xxx
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9
Connection: close

{"referrerId":"950485","code":"","mobile":"13555555555","sourceId":"6","stuInfo":"","timestamp":1729442602682}

这条数据包会在用户绑定手机号后，给该手机号用户增加 7 天会员。最关键的是，它可以无限重发，也就是可以无限刷取 VIP。

重放后都返回成功，再看一下 VIP 天数。

直接刷到了两年后。

由于签名 + 时间戳校验只防止内容被篡改，却没有校验请求内容是否可以重放，因此也间接导致了这个重放漏洞。

总结

即使测试过程中网站或 APP 已经做了签名、防篡改等加固，也不应该直接放弃。更深入地去理解业务逻辑，说不定会有意想不到的收获。类似实战思路，也可以在云栈社区一起交流。