APP安全测试实战指南：从通用用例框架到高危漏洞挖掘

1. 安全测试从哪入手：先把通用用例的框架立起来

接到一个APP的安全测试任务，很多刚入行的同学习惯直接开工具扫描，或者拿固定清单挨个测。这样不是不行，但容易漏项，更麻烦的是测完不知道重点在哪。做了几年安全测试后，我的习惯是先搭通用用例框架，再根据APP类型做裁剪。

所谓通用测试用例，本质上是一套把APP安全风险按层次拆解的清单。我一般分成六个层面：客户端本地存储、网络通信链路、身份认证与会话管理、越权与访问控制、组件暴露面、逆向与完整性防护。这六个层面基本覆盖了APP安全测试百分之八十以上的常见风险点，不管是Android、iOS还是跨平台混合应用，都能套用。

把这六个层面映射到测试用例上，通用结构大致长这样：

这套框架的价值在于，它不只是罗列项点，而是告诉你风险分布在哪。实际测试时，我会先跑通用用例确认基线，再根据业务特点加专项用例。比如涉及支付的APP，重点补金额篡改和订单重放；涉及社交的APP，重点补用户关系链越权。通用用例是地基，专项用例是上层建筑，二者不能互相替代。

另一个值得注意的点是优先级。我习惯把用例分为P0、P1、P2三个级别。P0是直接影响用户资金、隐私或可被远程利用的问题，比如任意密码重置、水平越权、接口无鉴权，这类必须第一时间提缺陷单。P1是本地明文存储、日志泄露、证书校验缺失等问题。P2是加固缺失、混淆不足，可读性差这一类。优先级划分不是为了排序好看，而是为了在有限测试周期内保证高风险项被优先覆盖。

2. 逐项拆解核心高危测试用例与验证方法

框架立起来之后，关键是把每个层面的用例落到实处。下面挑几个我实际测过最多、也最容易出问题的高危项详细展开。

1.1 本地存储：比想象中的更容易翻车

本地存储这块，最容易出问题的是开发者图省事。Android开发者图省事把Token直接塞进SharedPreferences，iOS开发者把用户密码写进NSUserDefaults，这种事我见过太多次。

具体测法上，Android端我会先把APP安装到测试机上，正常登录并产生业务数据，然后用adb连上设备进入应用私有目录：

adb shell run-as 包名 ls -l files/ databases/ shared_prefs/ cat shared_prefs/xxx.xml sqlite3 databases/xxx.db .dump

这一步能直接把SharedPreferences里的键值对、SQLite数据库内容、缓存文件全看一遍。重点找关键词：token、password、session、user_id、phone、id_card这类。比如有些APP会把用户身份证号直接存在名为user_info.xml的文件里，字段还叫idcard，这问题基本实锤。

iOS端稍微绕一点，因为应用沙箱在非越狱设备上不容易直接进。常规做法是把iPhone连接测试电脑，使用备份工具抓取备份包，然后解析应用Document和Library目录。没有越狱环境时，用备份分析方法也能发现绝大部分明文存储问题。当然，如果团队有越狱测试机，直接用iTools或者文件管理工具进沙箱查看更直接。

这里有个容易忽略的坑：剪贴板。很多社交APP为了分享方便，会把邀请码、鉴权信息写到剪贴板，结果就被其他APP读走了。Android 10之后系统对剪贴板读取有提示，但iOS的通用剪贴板同步特性，某设备复制的内容可能出现在同一账号下的其他设备上。测试时我会手动复制关键内容，然后检查系统剪贴板历史。

日志泄露也属于本地存储范畴，但常被忽略。用logcat看Android日志，用控制台看iOS日志，重点过滤关键字：http、token、password、key、secret。有的APP调试日志里直接打印完整的请求响应报文，线上版本忘了关，等于把接口协议拱手送人。日志这块的P0判断标准很简单：是否包含可作为凭证的完整敏感字段。

1.2 网络传输层：抓包看过才算数

网络传输层是安全测试的门面，也是很多“以为是HTTPS就安全”的认知翻车现场。我见过某款APP全部接口都走的HTTPS，但客户端没有校验服务端证书，用抓包工具装个自签名证书直接就能解密全部流量。

测试方法分三步走。

第一步是基础链路检查。把手机WiFi指向测试电脑的抓包服务，安装证书后，启动APP逐个操作核心功能模块，观察请求和响应报文。重点看三类内容：是否全部接口都是HTTPS；HTTPS握手是否正常完成证书可信；请求参数和响应体里有没有出现意外字段。

第二步是证书校验对抗。抓包工具装证书后，有的APP会直接报错或者请求失败，说明做了证书绑定或者SSL Pinning。这时候需要绕过校验继续测试，常规手法是用调试器附加进程后，在内存中定位并修改校验逻辑，或者用HOOK框架在代码层拦截校验证书的方法。这一环节的技术难度不低，但恰恰是能比普通测试多发现问题的关键。能绕过说明客户端校验可以被击穿，绕过不了说明这块防护到位，在报告里可以写“防护有效”。

第三步是看业务逻辑漏洞，而不是只盯加密。抓包不仅是看明文，更重要的是看请求能不能篡改、重放、绕过。比如一个领取优惠券的接口，抓包后把user_id改成别人的ID，如果服务器没有校验身份和资源的归属关系，那就是一个水平越权。再比如一个支付回调接口，把回调金额参数从100改成0.01再重放，如果后端没有做金额一致性校验，订单金额就失真了。

这里也提醒一个容易被忽略的细节：WebView页面的请求。很多APP内部打开H5页面时走的是系统WebView默认行为，如果页面请求没有接管和校验证书，同样存在被监听的风险。测试时要特意从APP入口打开H5业务，比如活动页、充值页、隐私政策页，抓包看这些子资源的加载链路。

1.3 身份认证与会话管理：业务逻辑的重灾区

身份认证这块，说句不夸张的话，安全测试里至少三分之一的高危问题都出自这里。弱口令只是最表面的，更麻烦的是会话机制本身存在漏洞。

先看认证绕过。典型场景是验证码接口，某号码几步之内及时发现验证码是否校验与后端，前端先校验，而后端未删除缓存内容。测试时用抓包工具拦住发送验证码的请求，反复提交同一手机号，观察返回结果和验证码有效期。有些接口确实没有频率限制，几分钟内可以无限发；有些验证码在未使用前始终有效，过期时间形同虚设。更离谱的案例是短信验证码就四位，没有错误次数限制，配合多线程爆破，几分钟就能撞开。

再看Token生命周期。测试点包括：登录获取的Token过期时间是否合理（比如超过七天不自动失效）；退出登录时Token是否被服务端作废，还是仅仅客户端删除了本地存储；修改密码或找回密码后，旧的Token是否仍然可用。这三个小场景分别对应会话固定、会话残留、会话未作废三类风险。亲手测过的项目中，至少有一半APP在“退出登录后旧Token仍可继续调用业务接口”这一点上翻车。

还有一类容易被忽视的，是把Token放在URL参数里。比如https://api.xxx.com/user/info?token=abcdef这种设计，Token会出现在服务端访问日志、CDN日志、历史记录中，形成严重的泄露面。测试时如果发现Token出现在URL里，直接定性为高风险并建议改成Header传递。

1.4 越权与访问控制：最值钱也最需要耐心的测试项

越权测试是我个人觉得性价比最高的一块。不需要太高深的技术，只要耐心抓包、改参、重放，往往能找到高危问题。同时，这也是最能体现测试价值的领域，因为接口权限设计通常隐藏在后端逻辑里，白盒代码审计不好发现，黑盒测试反而更直接。

越权分两类。水平越权是指同类用户之间越权访问，比如普通用户A能查看普通用户B的订单详情。垂直越权是指低权限用户访问高权限功能，比如普通用户调用管理员的删除接口。测试套路基本一致：用低权限账号登录，抓包拿到业务接口，把请求中的身份标识替换成目标用户的标识，或者直接重放高权限功能接口，观察响应结果。

实际操作时，我偏好用两个不同账号配合测试。账号A和账号B都是普通用户，A登录后访问自己的资源接口，抓包记录请求特征；然后把A退出，用B登录，把之前A的请求中身份相关信息依次替换重放。如果响应的资源不是B自己的数据，说明水平越权存在。

很多测试新手忽略的点是直接用内存风险指令绕过前端检查。比如一个领取积分接口，前端明明限制了只能领取一次，但抓包后直接重放请求，服务端根本没有幂等校验。这类问题本质是服务端信任了客户端的限制，把前端校验当作安全边界。测试时不要被页面交互限制住思路，抓包重放是基本动作。

同事问我越权测试要不要用自动化工具跑。说实话，自动化能做一部分，比如把所有接口的user_id字段批量替换成另一个值观察响应差异。但业务语义层面的越权、组合条件越权，还是得靠测试人员对业务的理解去构造场景。比如修改订单金额，不只是把金额参数改了发出去，还要考虑后端是否校验“下单金额”和“支付回调金额”是否一致，这种跨接口的状态关联校验，工具很难覆盖。

3. 环境准备与全流程实测记录

框架和用例都清楚了，但落不了地就是白搭。不少同学卡在“用例知道、工具不会配”，所以我把一套成熟可复用的环境搭建和实测流程整理出来，照着走就能跑通。

2.1 测试设备与网络环境的选择

移动端安全测试，最低配置是一台Android测试机、一台用于抓包的电脑、一条能连通的WiFi链路。Android 7以上系统默认不信任用户安装的证书，如果只是做常规抓包，建议优先选择Android 7以下的设备，或者对测试机型做系统级证书处理。没有旧设备时，用当前设备装证书后需要把证书移动至系统证书目录，但这一步需要root权限，多数情况下没root的设备做不了。

所以我的建议是团队常备一台已解锁root的Android测机，系统版本可选的低版本优先，因为低版本系统更容易做证书信任、HOOK、动态调试这些操作。iOS端同样备一台越狱机，配合调试插件做证书信任和代码分析。当然，如果公司重视合规，测试机需要走内部设备申请流程，这些都是环境之外的事。

抓包工具选型上，老牌工具有两类。一类是通用HTTP抓包工具，适合看请求响应、改包重放，界面直观，功能强大，也支持脚本扩展。另一类是终端命令行类工具，适合在测试机本地监听特定应用的通信，也适合配合脚本自动化的场景。两者不冲突，我通常抓包全流量用图形工具，特定场景定位用命令行工具。

网络环境的搭建核心就一件事：把手机流量导向电脑的监听服务，并让手机信任电脑证书。流程不复杂，但有一个关键点容易踩坑，就是流量方向问题。如果监听服务配置成全局接管，手机会上不了网，因为所有流量都在监听通道内死循环；正确做法是让监听服务同时承担转发功能，上游连接正常网络。这个配置理解透了，抓包环境基本一次就能搭好。

2.2 完整跑一遍安全用例的实测记录

拿一个全新的模拟项目X来演示整个实测流程。这是一款面向某特定用户群体的工具型APP，包含登录注册、个人资料、数据上传下载几个模块。

第一步，安装APP后先做基础信息收集。用压缩工具解开安装包，看AndroidManifest配置信息。这里我用一个比较直接的方式：把安装包后缀改成zip解压，直接看清单文件和资源目录。主要确认三件事：allowBackup是否开启、debuggable是否为true、usesCleartextTraffic是否允许明文流量。实测中发现这个APP的allowBackup没有设置成false，这意味着攻击者能通过备份接口把应用私有数据倒出来，属于中危风险，我可以直接用adb备份验证：

adb backup -f backup.ab -noapk 包名

备份完成后用解析工具解包，查看是否包含敏感文件。结果能翻到登录后的会话记录文件，虽然内容是加密过的，但能明确确认备份通道未关闭。

第二步，启动抓包工具配置好手机证书后，正常操作APP的注册、登录、资料上传流程。抓包看到登录接口返回了一串Token，而且这串Token在后续请求中一直放在Header的Authorization字段里传递，这个设计本身没问题。问题出在服务端是否校验该Token的有效期与状态。我把登录后拿到的Token拷贝下来，然后退出登录，再用这串Token请求用户信息接口。实测发现服务端竟然还返回了该用户完整资料，这就是典型的“退出登录后会话未失效”。

第三步，做越权验证。注册账号A和账号B，A登录后查看自己的资料，抓包定位到/api/user/detail请求，里面有个uid参数。把uid改成B的ID重放请求，响应返回的是B的资料。再试一个更实际的场景：A上传了一个文件，文件下载接口的参数包含文件ID，同样把文件ID替换成B上传的文件ID直接下载成功。两个接口都存在水平越权问题，分别记入缺陷单。

第四步，回到客户端本地存储。用root权限通过文件管理器进应用私有目录，看到上传的历史文件都以原始文件名存储，没有加密。更意外的是在缓存目录下发现一份包含明文请求参数的日志文件，里面记录了登录时提交的手机号和密码字段。这个比明文存储更严重，因为日志文件可能被备份、同步到云盘，泄露面被放大了。

第五步，测试组件暴露。使用组件调用工具尝试直接拉起安装包里的Activity。重点是把未导出的组件逐一拉起看是否有异常，以及测试DeepLink跳转是否存在开放行为。实测发现一个用于扫码返回结果的Activity设置了exported=true，虽然要求传参，但参数校验不严格，可以传入任意数据让页面崩溃。这个问题危害不高，但能证明组件暴露面管理不到位。

2.3 数据加密与完整性校验的专项验证

通用用例跑完后，针对数据加密和完整性防护做专项验证。这里的重点是“客户端声明的加密能力”和“实际防护效果”之间的差距。

先看密钥存储。用静态分析工具打开安装包，搜索字符串常量，最直接的方式是把安装包解压后对所有文件做字符串提取，再配合正则筛选出疑似密钥的内容。关键词包括：key、secret、aesKey、privateKey、BEGIN。实测那个模拟项目X的代码里真的出现了硬编码密钥，而且是AES加密密钥，长度为16位。再用这个密钥去解某个配置文件的加密内容，竟然能顺利解出来。说明密钥设计是全局统一的，没有任何基于设备ID或用户维度的动态派生机制。

再看完整性校验。模拟二次打包测试：用重打包工具对安装包进行解包、修改再签名。修改的内容可以很小，比如把某个布局文件的文字改一改，或者往资源目录塞一个文件，然后重新签名安装。如果APP没有做签名校验，改造后的包能正常运行，说明完整性校验缺失。实测模拟项目X重打包后依然能安装启动，且登录流程正常，说明缺少完整性校验能力。

这个专项里还有一个测试点是调试状态检测。用调试工具尝试附加APP进程，看是否有反调试逻辑。实测进程能正常附加，且能dump出运行时内存，说明没有检测调试状态。配合内存分析，能直接看到运行时密码框中的明文内容，这个属于客户端对抗能力缺失。虽然这类问题在攻击链中的利用门槛较高，但对核心资产型APP来说，仍是P1级别的加固缺口。

4. 高频问题排查与压箱底的避坑经验

安全测试做了几年，踩过的坑能写一箩筐。把出现频率最高的几个问题集中整理一下，当成一份自检清单来用，能少走很多弯路。

3.1 抓不到包的十大原因排障速查

抓不到包是安全测试新手最常见的卡点，而且原因五花八门。根据经验，90%的抓包失败都能从下面这个表里找到答案：

前三项解决不了时，直接换一个测试机或另一台电脑交叉验证，能快速定位是设备侧还是工具侧的问题。

3.2 漏洞定级与报告撰写的实战心得

测出了问题不等于工作完成，把问题讲清楚同样重要。这里最核心的是漏洞定级标准。

我给安全测试报告定级的原则是：以“可被利用的链条长度”和“影响范围”为核心判据，而不是只看技术含量。一个不需要任何前置条件就能水平越权查看所有用户手机号的问题，虽然技术含量一般，但影响面巨大，金额无法估量，必须定为P0。反过来，一个需要物理接触设备才能获取本地缓存的问题，即便技术含量稍高，实际利用门槛也决定了它通常只能定P1或P2。

报告中每个漏洞至少包含五要素：问题描述、复现步骤、影响范围、修复建议、风险等级。复现步骤必须精确到“哪个页面、点了什么、改了哪个参数、拿到了什么结果”，不能只写一句“存在越权风险”。因为这些报告不只是给开发看，后期审计、复测、安全合规检查都要用同一份记录，写不清楚等于白测。

还有一个实战心得是“复测留痕”。提交缺陷后，开发通常会修复，但有的只修了前端限制，没有修服务端校验。复测时不能只看原路径是否挡拦住，还要尝试绕过新限制，比如前端隐藏了入口、后端加参数白名单，可以用编码方式绕过或调整参数位置重新试。只有确认服务端确实补上了服务端校验，这个漏洞才能闭环。

3.3 容易被忽略的细节与建议补充的用例方向

通用用例框架更多是覆盖“已知的未知”，但安全测试有一个心照不宣的事实：真正杀伤力大的漏洞往往藏在非标准用例里。我建议在通用基础上，每个项目都额外补充以下几类用例。

第一类是业务状态机异常。正常业务有流程顺序，但攻击者不会按顺序走。比如注册时填了邀请码、然后直接跳到实名认证、再绕回注册。测试时故意乱序操作、重复提交、并发提交，经常能发现服务端对业务流转缺少状态校验。典型的例子是一元购活动，正常流程是下单、支付、领取，如果直接调用领取接口且后端没有校验订单状态，就能白嫖商品。

第二类是并发与条件竞争。这个容易被安全测试团队忽视，但成功率不低。经典场景是优惠券领取接口，用多个请求同时打过去，如果服务端没有做幂等控制，同一用户可以领取多张。另一个经典场景是提现接口，同时发起多笔提现请求，后端余额扣减如果存在竞态条件，就能超额提取。这类测试需要多线程请求工具配合，单纯手点测不出来。

第三类是外部服务交互面。很多APP集成了第三方SDK，如地图、支付、客服、推送。这些SDK的调用链有时会绕过主APP的安全策略。测试时重点看第三方SDK是否使用独立的应用ID、是否在客户端保存密钥文件、SDK回调地址是否存在可篡改空间。曾有人通过替换支付SDK的回调地址，把支付结果伪造成成功，属于支付链条回调参数被篡改的典型风险。

第四类是卸载与数据残留。APP卸载后会清除自身沙箱，但部分数据会留在公共目录，比如Download、DCIM、外部存储的私有文件夹。测试时安装APP、登录、产生数据，然后卸载、查看公共目录是否有残留。这不算高危，但隐私合规检查时默认要求覆盖。

第五类是账号注销与隐私删除。互联时代常见的合规项，注销入口并不代表可注销真实数据。测试注销后重新用原手机号注册，看能否找回历史数据。若历史订单、聊天记录仍可恢复，说明删除逻辑未对用户数据做物理净化。这类问题普通安全测试容易漏，但合规检查必查。

5. 通用测试用例如何沉淀成团队资产

单独一份测试用例是“战术物资”，沉淀成团队资产才是“战略能力”。最直接的做法是建一份“安全测试基线用例库”，每次项目测试前直接拉取基线用例，跑完基线再按项目差异补专项。

这套基线库的日常维护一般遵循PDCA循环：新项目测完后，把新增的高价值用例回填到基线库；每周做一个用例覆盖率统计，对照近半年的线上安全问题反查用例缺失；对于漏测并导致线上故障的用例，不管多难都要补充进库并做全员研讨。经过两三个大版本迭代，后面的测试会越来越轻松。

用例库的格式上，建议统一使用表格化描述，包含用例编号、测试领域、前置条件、操作步骤、预期结果、风险等级、关联工具。不用做成多复杂的系统，一个云端表格或者内部知识库就够了。关键是“能执行”：新团队成员拿到用例后，不需要向人打听“这个怎么测”，照着步骤就能完成八成工作。

这里再补充一个团队协作视角：安全测试用例不应该只由安全测试人员维护。开发自测阶段的安全checklist、测试团队的回归安全用例、运维侧的基线巡检项，都应该在同一个库中相互引用。很多公司在安全建设上的隐痛是各方各自维护用例，结果同一个问题在研发、测试、运维三个团队各测一遍，标准还不统一，浪费人力的同时漏点依旧。

所以我在团队内部推过一个很朴素的做法：把通用安全用例按模块拆分，责任到人。比如网络传输层由测网络通信的同事维护，本地存储层由客户端专项测试的同事维护，越权与业务逻辑层由负责具体业务的测试工程师维护。安全测试人员负责统筹和差异分析，而不是什么用例都自己写。这样维护成本低，用例质量反而更高。

说到底，APP安全测试不是一次性的渗透测试，而是一个需要持续投入、不断迭代的工程活动。通用用例框架解决的是“从零到一”的覆盖问题，能不能真正变成团队的能力，取决于是否愿意在每一个项目结束后，回到用例库前做一次复盘、补一次用例、校准一次优先级。这些反复积累的动作，才是安全测试工作最有价值的部分。

根据我个人经验，刚开始做安全测试时最容易犯的错误是追求“测出漏洞数量”，恨不得把报告写满。但做久了会发现，真正优秀的测试工程师，是能在有限时间内找最关键风险、把问题讲清楚、并推动闭环的那个人。通用用例帮我们守住下限，而上限，永远来自对业务的理解和对细节的执着。