别把漏洞分析想得太玄乎。我做移动端安全评估这几年最深的感触就是大部分App不是被什么天顶星技术打穿的而是倒在最基础的几个洞上——越权、明文存储、传输层裸奔、WebView乱开。漏洞分析说白了就是站在攻击者视角把App里里外外摸一遍在坏人动手之前先帮自己人排雷。这篇文章我尽量不堆术语用我平时实际干活儿的流程来拆解一套新手也能直接上手的分析思路适合刚接触安全测试的研发、测试同学也适合想系统性梳理自身产品风险的技术负责人。1. 先搞清楚漏洞分析到底在分析什么很多新手拿到一个App就急着上工具扫扫完一脸懵报告几百页不知道先看哪个。这不能怪新手因为漏洞分析本来就不是“跑一遍扫描器”那么简单。它更像一次体检得先知道这个人的生活习惯、既往病史才知道该重点查哪个器官。1.1 漏洞分析的本质不是找茬是控制风险从本质上看漏洞分析就是在回答一个问题如果我是攻击者有哪些路径能伤到这个系统的核心资产这里说的“核心资产”不只是用户密码还包括订单数据、余额、聊天记录、身份证号、甚至App本身的口碑和可用性。我习惯用一个特别朴素的分层模型来展开叫“数据入口—数据加工—数据存储—数据出口”。入口看的是网络请求、输入框、二维码扫描这些外部数据怎么进来的加工看的是业务逻辑像优惠券计算、越权校验是否安全存储看的是本地数据库、SharedPreferences、Keychain里放了什么不该放的东西出口看的是App往外传了哪些数据、传给谁、是不是加密的。把这四条线捋一遍基本就能覆盖大多数安全问题。对应的行业标准里也有现成的框架OWASP Mobile Top 10 就是很好的索引。里面列了不安全的日志记录、不安全的通信、身份认证机制缺陷、加密算法使用不当这些大类。我不建议新手一上来就死记分类但建议把这十类当作一个“检查清单”每条对照着自己的App问一遍“我这个会不会中招”思路会清晰很多。1.2 漏洞分析的正确打开方式先定边界再动手很多人都忽略这一步上来就抓包、反编译结果测到一半发现“这个接口是别的团队负责的”“这个风险属于服务端不归App管”白忙活。我自己的习惯是先花半小时把边界划清楚哪些是客户端本地风险哪些是服务端接口风险哪些是传输链路风险这个App是不是混合开发原生壳WebView页面占了多大比例核心业务是登录、支付、社交、还是内容展示不同业务对应的重点漏洞完全不同有没有用第三方SDK这些SDK的权限申请是否合理历史上是否出过安全问题。这套事儿做完你心里就有底了。支付类App重点盯越权和支付篡改社交类App重点盯用户数据泄露和内容安全工具类App重点盯本地敏感信息存储。方向对了后面的测试时间能省一半。1.3 漏洞分析是团队协作不是安全岗的独角戏新手还容易犯一个毛病觉得漏洞分析是安全团队的事自己测完写个报告就完事。真不是。一个漏洞从被发现到真正修复需要研发同学能看懂报告、产品同学愿意给排期、测试同学能验证修复效果这条链路缺一环都不行。所以现在很多团队把漏洞分析前移让开发者在需求评审阶段就参与进来。这其实是最高效的做法因为漏洞越晚发现修起来越贵。我自己在带新人时经常说漏洞分析这个活儿最重要的产出物不是漏洞列表而是让团队形成一个共识——哪些代码习惯是红线哪些数据必须加密哪些操作必须校验权限。思想工作跟上去了漏洞自然会少。2. 新手也能复制的信息收集与攻击面梳理流程这个阶段是整个漏洞分析的地基。地基没打好后面分析得再热闹也是空中楼阁。我见过太多新手连App有几个域名、调了哪些第三方服务都没搞清楚就闷头去破解签名纯属浪费精力。2.1 先回答“这个App在保护什么”拿到一个新项目我第一件事不是打开Burp Suite而是先自己装一个App注册个账号把核心流程从头到尾走一遍。为什么要这么做因为只有你自己知道正常业务长什么样后面看到异常数据时才有感知。比如一个运动类App核心资产就是用户的运动轨迹、健康数据和社交关系。那我分析的重点就应该是这些数据在本地怎么存的上传时加密了吗别人能不能越权查看我的运动记录相比之下这个App用的是什么字体、UI布局合不合理那都不是安全测试该关心的事。这个阶段我会顺手把以下信息记录到自己的笔记里服务器域名和IP列表用网络分析工具能看到第三方SDK清单包括地图、推送、支付、统计类看注册了哪些服务用户角色权限普通用户、会员、管理员分别能干什么关键业务流程登录、注册、找回密码、支付、分享等。2.2 客户端VS服务端漏洞从哪一端入手移动App的漏洞分布很有意思早期大家把宝都压在客户端加固上后来发现服务端接口才是重灾区。我的经验是两条腿走路客户端重点看本地存储逻辑、硬编码密钥、WebView注入面、组件导出服务端重点看接口鉴权、水平越权、垂直越权、数据校验、频率限制。这两块相对独立但又有千丝万缕的联系。比如你从客户端逆向拿到一个API密钥然后用这个密钥去调服务端接口如果服务端深信这个密钥那问题就是端到端的。所以正确的顺序应该是先用静态分析和流量分析把客户端摸清楚把所有的API域名、请求参数、加密逻辑、业务上下文搞明白然后再带着这些信息去测服务端接口。只测客户端不管服务端等于只看了一个壳。2.3 抓包实战从环境配置到流量分析流量分析是漏洞分析的核心基本功。我常用的工具链非常简单Burp Suite 真机 代理设置。Android模拟器也凑合能用但真机更接近生产环境尤其是遇到检测模拟器的App时真机能省很多事。Android抓包的坑特别多关键在证书信任。Android 7.0 以后App 默认不信任用户安装的CA证书直接导致Burp的证书无效抓不到HTTPS包。解决办法有两个把Burp的证书导入系统证书目录需要root设备适合自己测试机。修改App的AndroidManifest.xml在application标签里加上networkSecurityConfig允许调试模式下信任用户证书。这种方式需要重打包也要考虑到签名校验。iOS这边相对简单一些用iPhone抓包时把Burp证书安装到系统信任里再到“设置-通用-关于本机-证书信任设置”里打开开关就行。证书搞好以后不要急着乱点先把App的登录、浏览、支付等主要流程各操作一遍让流量跑起来。这一步我很看重因为后面做越权测试时这些录下来的请求就是我们构造测试用例的模板。2.4 静态代码审计不用看懂所有代码只看几个关键点很多新人看到反编译出来的代码就头大几万个类、几万个方法这怎么看我的答案是别全看但要会抓重点。我常用的检索关键词包括密码相关password、secret、token、api_key、private_key加密算法AES、DES、RSA、MD5、SHA1注意加密模式ECB这种不安全的协议相关http:// 明文链接、websocket、socket组件相关Intent、ContentProvider、Exported、BroadcastReceiver存储相关SharedPreferences、SQLite、getSharedPreferences、MODE_WORLD_READABLE这类。工具上我习惯用 jadx 做反编译查看它能把APK直接转成可读性很好的Java代码配合搜索功能定位关键逻辑非常快iOS用 class-dump 或者直接看逆向后的伪代码。找到这些关键字以后顺着它的调用链往下看往往能挖到硬编码密钥、弱加密逻辑、危险的外部调用这些典型问题。3. 常见漏洞类型拆解与实操判断要点知道了怎么收集信息接下来就是真正的硬仗在代码和数据中识别漏洞。我把移动端最常见的六类漏洞拆开每一项都给出我自己实际测试时的判断标准和套路。3.1 越权漏洞改个ID就可能拿到别人的数据越权漏洞绝对是移动端接口测试里最常挖到的洞没有之一。它分两种水平越权是普通用户A能访问普通用户B的数据垂直越权是普通用户能访问管理员功能。我对所有App的测试都会把越权当成必测项。操作手法很简单抓一个正常请求比如“获取我的订单列表”看到参数里有order_id12345直接把值改成12344、12343看看能不能返回别人的订单信息。如果返回了那就是典型的水平越权如果返回没有权限但把请求里的角色参数从user改成admin就能执行管理员功能那就是垂直越权。这个测试的关键在于很多App把用户身份放在服务端Session里你单纯改客户端参数没用但也有相当数量的App会把userId直接放在请求参数、请求头甚至加密字段里服务端没有二次校验这时候就能打穿。我的经验是别只看GET参数POST的JSON体、请求头、Cookie、签名参数全都要试一圈。3.2 不安全的本地存储明文密钥和敏感数据随手放本地存储是客户端分析的重点。很多App为了方便把用户登录的token、手机号、甚至支付密码的密文直接存到SharedPreferences里备份数据的时候全泄露了。更夸张的我还见过把数据库加密密钥硬编码写在Java代码里的这等于锁了个假门。我判断这个类型的问题有个简单标准如果手机丢了或者有人拿到了用户手机的文件系统备份能不能从中提取出关键账号凭证能提取出来问题就成立。要注意很多App说“我对数据库加密了”但加密密钥写死在代码里、且所有用户共用一把那这种加密在攻击者眼里形同虚设。真正靠谱的方案是使用系统级别的安全存储比如iOS的Keychain、Android的Keystore密钥由硬件级隔离保护攻击者无法简单提取。3.3 传输链路风险看到http://就值得警惕别以为现在都是HTTPS的时代了传输安全就万事大吉。我在测试中见过的情况包括部分接口仍然是明文HTTP、HTTPS证书校验不严甚至设置为Trust All、特定页面降级到弱加密协议、敏感数据日志被明文输出。拿到流量后先做两件事第一全局搜一遍URL把http://的请求全部标出来重点看有没有涉及登录、手机号、定位这些敏感数据接口第二把https证书校验关掉用中间人工具重新跑一遍流程看App会不会“默默接受”伪造证书。如果App没有任何提示、数据照常传输说明它的证书校验形同虚设。还有一种坑是WebView加载了外部HTTP链接中间可能被注入恶意脚本这叫会话劫持或注入也是传输层要关注的问题。3.4 WebView 相关的漏洞面JS Bridge 是把双刃剑混合开发现在是主流这意味着WebView相关漏洞面非常大。最典型的问题是给WebView开启了JavaScript支持并且注册了JS Bridge——一个可以让网页调用原生功能比如发短信、读相册、调摄像头的通道。如果没有做严格的域名白名单校验攻击者诱导用户打开一个恶意链接就能通过JS Bridge偷偷调用原生能力。我测试时会去代码里搜addJavascriptInterface找到以后看它暴露的方法再检查WebView加载页面的URL是否可控。如果可控我会尝试构造一个页面去调用那些危险方法看能不能成功。还有一类问题是WebView无视SSL错误setWebViewClient里重写了onReceivedSslError并且proceed这是非常常见的低级错误直接导致中间人攻击成为可能。这两个点新手一定要在代码里主动搜。3.5 组件暴露导出Activity和ContentProvider的风险Android的四大组件都有“导出”的概念。导出意味着其他应用可以主动拉起你的页面或读写你的数据。如果导出的Activity是登录页、支付页这种关键页面那就可能被恶意应用利用做界面劫持如果导出的ContentProvider提供数据库访问接口且没有任何权限控制攻击者App就能直接读取用户数据。我常用的验证工具是drozer一条命令就能列出App所有导出的组件。测Activity的话可以直接用adb shell am start去拉起页面看能不能绕过登录跳转到内部页测ContentProvider的话尝试用adb shell content query去直接查数据。这个检查对新手特别友好因为它是纯客户端行为不需要搭建复杂的服务端环境。我建议在每个Android App的分析中都至少跑一遍组件导出检查投入产出比非常高。3.6 加密算法和随机数隐蔽但致命最后一个点是加密技术。有些App确实做了加密但用的是MD5存密码、ECB模式加密、硬编码的固定盐值、可预测的交易流水号这些都属于“表面安全”。我判断加密实现是否合格主要看三件事是否使用了安全的哈希算法最少SHA-256密码存储还要加盐迭代是否使用对称加密时选了安全的模式GCM远好于ECB随机数和时间戳是否足够随机能否被预测。我记得有一次测试一个抽奖类App它的抽奖结果串是用固定的随机种子生成的。我找了好几个历史样本反推出种子后直接预测了后续每一期的开奖号码。这种问题比越权还恐怖因为它是业务逻辑层面的漏洞常规扫描器根本发现不了。4. 工具链选型与关键实操演示前面讲了很多“看”的思路这一节写点“干”的东西。工具不再多顺手才最重要。我自己留了一套固定的工具组合新手直接照抄就行。4.1 工具选型一览与各环节定位我没有用特别冷门或昂贵的工具全是开源或免费方案够用且稳定工具用途适合阶段Burp Suite Community代理抓包、改包重放、爆破弱口令流量分析、接口测试jadxAndroid APK反编译与源码阅读客户端静态分析class-dump / HopperiOS二进制分析与头文件导出iOS客户端分析Frida动态插桩、绕过SSL Pinning、绕过root检测动态调试、绕过机制验证objection基于Frida的运行时探索工具一条命令打天下快速评估、SSL Pinning绕过drozerAndroid组件暴露检测、四大组件攻击客户端攻击面测试MobSF一站式静态动态分析框架自动出报告快速沉淀基线报告新手最大的误区是想把所有工具都学会再动手其实完全没必要。先把手上的Burp和jadx用熟练能覆盖八成以上的日常工作。Frida和objection这类动态工具可以后面按需学“需要解决某个问题时再去查用法”比“先学完再干活”效率高得多。4.2 使用 objection 快速绕过 SSL Pinning 实录我举一个高频场景分析某App时Burp能正常设置代理但一旦打开App所有HTTPS请求全部失败这就是证书固定SSL Pinning在起作用。证书固定的本意是好的防中间人但在授权测试中会给分析造成障碍。用objection一行就能起一个Frida环境命令大概是# 如果没有安装先安装也可直接跑一条命令注入 pip3 install objection objection -g com.example.app explore进入objection的交互模式后输入android sslpinning disable执行完这条命令Burp就能正常看到这个App的HTTPS流量了。原理是objection通过Frida把App证书校验相关的关键函数返回值改掉了相当于“欺骗”App相信当前证书是合法的。这对分析人员开放了一个入口但也提醒我们单纯靠客户端证书固定防中间人是挡不住专业攻击者的服务端必须有完整的安全校验体系配合。如果你不想装objection写一个Frida脚本也行核心思路是通过Java.perform去Hook证书验证的代码路径。这里就不贴完整脚本了搜一下“frida ssl pinning bypass”能找到很多现成模板根据自己的App微调即可。4.3 用 drozer 一键探测导出组件组件导出检查我基本用drozer完成。先把手机连上电脑跑Agent后进入drozer控制台adb forward tcp:31415 tcp:31415 drozer console connect然后对目标App执行run app.package.attacksurface com.example.app输出里会列出这个App的导出Activity、ContentProvider、BroadcastReceiver、Service。逐个对导出组件做进一步测试比如扫描可读写的ContentProviderrun scanner.provider.injection -a com.example.app run scanner.provider.finduris -a com.example.app如果有内容提供者没有做权限控制这条命令能直接列出可访问的数据表某些表直接就能读出敏感字段。绕了这么一圈我想强调的还是那个观点工具只是放大镜真正的分析思路才是手术刀。4.4 用 jadx 定位硬编码密钥的搜索技巧jadx能把APK直接还原成接近原始的Java代码。打开后按快捷键“CtrlShiftF”调出全局搜索输入你关心的关键词。我用得最多的是搜“api_key”“secret”“token”这类词出来结果以后按“类名行号”定位到具体代码再右键选择“Find Usage”反查调用链。比如搜到一个硬编码的AES密钥通常格式类似String AES_KEY a1b2c3d4e5f67890; // 16位或32位我会先确认密钥的长度16位对应AES-12832位对应AES-256然后在代码里找这个密钥加密了什么数据、模式是ECB还是CBC。如果它加密的是用户上传的敏感参数服务端又完全信任这个数据那问题就大了——别人只要逆出这个Key就能伪造合法请求绕过一切客户端限制。这在业务风控里是致命问题。5. 常见问题与排查技巧实录测试过程最磨人的不是技术本身而是“怎么半天没效果”这种问题。我把踩过的坑整理成速查手册基本都是加密代码之外的“环境坑”。5.1 为什么抓不到HTTPS包这是新手问得最多的问题。除了证书信任问题以外还要注意几点第一代理是否配置正确。手机连上电脑WiFi后代理地址必须是电脑的局域网IP不是127.0.0.1否则手机端根本连不上。第二Android 7.0及以上的系统默认不信任用户证书要导出Burp证书为系统证书需要root或者用debug模式的networkSecurityConfig绕过。第三开启了“仅无线”或某些App自带代理检测普通代理直接被检测并拒绝。我建议新手排查顺序是先确认手机能正常访问外网再确认Burp监听的端口正确然后看App是否有代理检测最后再考虑证书问题。反过来排查会绕很多弯路。5.2 App 检测到 Frida 或模拟器怎么办不少App有反调试、反模拟器、反Frida机制。我最常用的绕过方式是换一个隐藏效果更好的Frida启动方式或者用objection的“android root disable”、“android simulate debug”这类命令临时关闭检测。如果App检测模拟器可以选用带谷歌框架的真机检测USB调试就尝试用Persistence模式启动。但要注意授权测试中绕过这些机制要把握尺度。客户端做这些检测本身属于合规的安全措施测试目的是为了评估它的强度而不是教大家怎么彻底破坏防线。在正式项目里如果检测机制做得很好其实应该记录为“良好的客户端防御”而不是非要弄破才罢休。5.3 自动扫描器报了上百个漏洞怎么处理这是新手最容易慌的场景。MobSF扫一个App出来几百条告警其实里面很多是误报比如依赖库里带了旧版本、但实际上没被应用路径引用。我的处理策略有三个层次低危且真实性存疑的先汇总成清单不单挑出来吓人中高危的要有代码或流量证据能贴出源码截图和复现步骤才放进正式报告修不了的要跟研发商量一个补偿方案比如升级依赖、加监控、加限制。记住漏洞分析的价值是排序和验证不是“报告越厚越厉害”。真正被研发认可的安全报告一定是每条漏洞都写清了“影响是什么、怎么复现、怎么修、要多久”。空谈风险没有任何意义。5.4 有没有推荐的自动化加固质检清单最后分享一个我自己的常规检查清单做客户端安全自测时可以直接照着过一遍是否使用HTTPS并有严格证书校验是否禁止了WebView的JS与文件访问是否针对加载URL做了白名单是否将敏感信息存储在系统安全存储中是否对导出组件做了权限控制是否对登录、支付等关键操作做了额外的服务端身份校验是否对高风险接口做了频率限制和异常检测日志中是否有敏感明文输出代码混淆和反调试保护是否有做基础处理客户端加签校验和接口签名是否做到了“即使改包也拿不到服务端有效响应”。这套清单看着简单但真能全过的App我测了这么多项目掰着手指头都数得过来。很多团队只是做到了其中几项就已经能挡住95%的“路人黑客”。安全本来就是一场持久战追求绝对安全不现实先把这九项落地你已经跑赢大多数同行了。我在实际测试中还有个习惯每次测完都写一份“给研发看的简短结论”前三行说清楚最严重的三个洞后面再用附件列细节。因为研发同学平时已经忙到飞起一份逻辑清晰、能快速定位到代码位置、附带修复建议的报告比一份洋洋洒洒但不知所云的报告受欢迎得多。漏洞分析做到最后拼的其实是沟通能力和对业务的理解能力。把这两个能力补上你的分析水平会再上一个台阶。