夜雨聆风📝 编者语
很多漏洞并不来自“高深技术”，而是来自一次认真测试。本次分享的两个 APP 漏洞案例，均整理自学员实战过程，希望能给刚接触移动安全的同学一些启发。
1
案例一：一次“负分评价”导致的APP DOS漏洞
漏洞背景
某APP中存在用户评分功能，正常情况下，用户可以对目标对象进行打分评价。
学员在测试过程中发现：
客户端虽然限制了评分范围，但服务端似乎并没有进行严格校验。
于是，一个经典问题出现了：
“如果我传个负数会怎样？”
然后，事情开始变得有意思了。
测试环境
为了方便分析，建议搭建了如下抓包环境：
工具
用途
Postern
手机代理转发
Charles
HTTPS 抓包
BurpSuite
请求修改与重放
第一步：定位功能点
打开APP后，可以看到存在“用户评分”功能。
于是目标明确：
找到评分请求。
第二步：抓取数据包
在 BurpSuite 开启抓包后，点击“提交评分”，成功捕获到如下请求：
POST /xx/xxByApp?ve=1&source=&token=xx&client=2&clientVersion=627 HTTP/1.1
Host: xx.xx.com
Charset: UTF-8
Content-Type: application/json
User-Agent: okhttp/3.10.0
{
"AccountID":"H547",
"Score":5,
"ScoreLabel":"8778|8779|8780|8781|8782|8783",
"EvaluateContent":"",
"IsAnonymity":1
}
【图片：BurpSuite 抓到评分请求的数据包截图】
到这里，一个经典测试点已经非常明显：
Score 是否只允许固定范围？
服务端是否真正做了校验？
客户端限制是否可以绕过？
进行了一个朴实无华的操作：
"Score": -10
没错。
直接改成负数。
漏洞触发结果
请求发送后，接口返回正常。
表面上看，好像什么都没发生。
但当再次进入对应用户评价页面时，异常出现了：
用户评价无法正常显示
页面出现异常
功能访问异常
简单来说：
目标用户的评价模块被“打坏了”。
漏洞核心原因分析
这个问题的根源非常典型：
问题点
说明
仅客户端限制
前端限制评分范围
服务端缺少校验
未验证 Score 合法性
异常数据入库
负数成功进入业务逻辑
页面渲染异常
导致后续展示失败
很多 APP 在开发过程中，会默认：
“客户端不会传奇怪数据。”
但安全测试的核心思路恰恰是：
“我就想传点奇怪数据试试。”
于是漏洞就出现了。
2
案例二：APP 组件暴露导致的本地拒绝服务漏洞
漏洞背景
Android 四大组件暴露问题，一直都是移动安全里非常经典的一类问题。
很多开发同学在配置 AndroidManifest.xml 时：
export 默认开了
Activity 未做权限限制
调试组件忘记关闭
第三方 SDK 组件直接暴露
然后攻击面就悄悄出现了。
本次案例中，通过drozer对目标APP进行安全测试时，发现存在可被外部启动的Activity。
最终成功造成APP DOS。
测试工具
本次案例使用到的工具如下：
工具
用途
drozer
Android 安全测试框架
adb
调试与组件调用
Android 测试机
漏洞验证
第一步：获取 APP 基本信息
安装目标APP后，首先使用drozer获取应用信息：
run app.package.info -a cn.xx.android
随后继续分析攻击面：
run app.package.attacksurface cn.xx.android
第二步：分析组件暴露情况
接着，进一步查看 Activity 信息：
run app.activity.info -a cn.xx.android
这里发现存在可导出的 Activity：
cn.xx.android.wxapi.WXPayEntryActivity
看到这里，安全测试人员的DNA基本已经动了。
因为：
很多支付、登录、回调类组件，往往最容易因为配置问题出现风险。
第三步：尝试直接启动 Activity
直接使用 drozer 启动该组件：
run app.activity.start --component cn.xx.android cn.xx.android.wxapi.WXPayEntryActivity
结果：
APP 出现异常。
DOS 成功。
第四步：使用 adb 验证
为了进一步验证漏洞稳定性，继续通过 adb 执行组件调用：
adb shell am start -n cn.xx.android/cn.xx.android.wxapi.WXPayEntryActivity
再次触发异常。
漏洞验证完成。
漏洞成因分析
该问题本质上属于：
Activity 组件暴露 + 异常逻辑缺失
其核心问题通常包括：
风险点
说明
风险点
说明
Activity exported
外部应用可直接调用
未校验调用来源
任意 APP 可启动
参数状态异常
组件缺少上下文校验
异常处理不足
导致 APP 崩溃或异常
3
分析总结
两个案例的共同特点
虽然这两个案例类型不同：
一个偏业务逻辑
一个偏 Android 组件安全
但它们有一个非常明显的共同点：
都不复杂
没有高深逆向。
没有复杂加密。
没有 Native 层利用。
更多是：
基础测试思维
对异常场景的敏感度
对攻击面的耐心排查
很多时候，APP 安全测试真正的门槛并不是“技术太难”。
而是：
大部分人没有真正系统地去练。
给刚开始学 APP 安全同学的一些建议
1、先把抓包练熟
很多漏洞的起点，其实就是：
“先看到请求。”
推荐优先熟悉：
BurpSuite
Charles
HttpCanary
Postern
2、重点练参数测试
尤其是：
测试类型
示例
边界值 -1 / 0 / 超长
类型异常 null / 数组 / 对象
权限测试 越权 ID
状态异常 重放请求
很多业务漏洞，都是这样挖出来的。
3、多关注 Android 组件安全
重点关注：
exported
intent
deeplink
WebView
ContentProvider
FileProvider
这些地方，经常能出现不错的问题。
4、别总想着“一步到位”
很多同学一开始就想：
Hook 全场
秒杀加固
Native 层 RCE
结果最后连抓包都还没配通。
其实安全学习很像健身。
大部分时候：
基础动作重复练，反而提升最快。
结语
这次分享的两个案例，本质上都属于 APP 安全测试中的“经典基础问题”。
但也正因为经典，所以它们一直真实存在。
很多漏洞，并不是因为攻击者技术多么夸张。
而是因为：
有人认真测了。
而这，也是很多测试人员在真正进入实战学习后最大的变化：
开始学会：
如何观察攻击面
如何分析业务逻辑
如何验证异常场景
如何把“感觉不对劲”变成“漏洞成立”
这其实就是安全能力真正开始形成的过程。
🎁 文末福利
联系客服获取《常见低危漏洞汇总》
!
微信号丨Hiddenfog001
