这两年移动端的业务越来越重很多公司的核心交易、用户数据都跑在App里。但不少团队的防御重心还在Web侧App端要么只做个混淆就上线要么测试的时候就测个功能流程安全测试基本靠运气。真正把移动端渗透当回事的团队并不多而这恰恰是黑产最爱下手的地方。这篇文章我就把移动端渗透测试的思路、常见漏洞类型和几个典型的实例分析整理出来聊点我实际测试中踩过的坑和总结的经验。先说明白所有渗透测试都必须在获得授权的前提下进行。下面提到的所有方法和技巧目标都是帮助开发者和安全工程师发现并修复问题而不是提供攻击教程。合规是底线这个红线不能碰。这篇文章适合三类人看一是刚接触移动端安全的测试同学需要建立完整的测试思路二是App开发工程师想了解自己写的代码在攻击者眼里是什么样子三是负责安全建设的技术管理者需要知道该往哪个方向投入。1. 移动端渗透测试的基础思路先想清楚测什么很多新手拿到一个App就开始装模拟器、开抓包工具看到接口就乱打一通。这种“无头苍蝇”式的测试效率极低而且很容易漏掉真正的风险点。我个人的习惯是拿到目标之后先花半小时到一小时做信息收集和威胁建模想清楚这个App最值钱的数据是什么、攻击者最可能从哪个入口进来、测试的优先级怎么排然后再动手。1.1 三个测试维度客户端、服务端、传输通道移动端渗透要覆盖三个维度缺一个都不完整。第一个是客户端本身。包括App的安装包APK或IPA能不能被逆向、代码里有没有硬编码的密钥和敏感信息、本地存储的数据库和SharedPreferences里有没有明文密码、WebView的加载逻辑有没有可控风险。这一层考验的是静态分析和动态调试能力。第二个是服务端接口。App只是个壳真正的业务逻辑大部分在服务端。登录注册、找回密码、订单查询、支付回调这些接口有没有做身份校验、参数校验、频率限制是攻击者最关心的。也是漏洞最容易出现的地方。第三个是传输通道。App和服务端之间的通信数据有没有加密、用的什么加密算法、SSL证书校验是否完整、有没有只校验域名不校验证书的情况。这一层经常被忽略但一旦出问题整个链路的保密性就都失效了。1.2 工具链选型静态分析、动态调试与抓包三件套工具不在多关键是每个环节都有趁手的家伙。静态分析我常用的是jadx和GDA。jadx负责把APK反编译成Java代码阅读性最好GDA是国产工具反编译速度极快处理加固样本的时候扫描速度快人一步。遇到混淆严重的样本再用JEB或Ghidra做深度分析。IDA主要用来对付So层的Native代码尤其是涉及加密算法和反调试逻辑的地方。动态调试和抓包这层Frida是目前的实际标准。它的Hook能力极强可以在运行时修改函数返回值、调用任意Java或Native方法、绕过SSL证书校验配合Objection这种基于Frida的自动化工具效率翻倍。抓包工具我主力用Burp Suite偶尔搭配Charles处理HTTPS流量。模拟器环境建议准备两套。一套是日常用的标准模拟器优点是启动快、操作方便、Xposed框架好装另一套是绕过检测的定制模拟器或实体机专门对付那些检测模拟器环境的App。真机调试建议常备一台Root过的Android手机很多时候模拟器过不了的检测真机直接就能绕过去。提示抓包工具装好之后第一件事是配置系统证书信任。Android 7以上版本默认不信任用户证书需要把抓包工具的证书装到系统证书目录否则只能抓到流量但解不了HTTPS。2. APP常见漏洞类型与成因剖析移动端常见漏洞的类型其实不算多翻来覆去就那么几大类。但每一类下面又有不同的变体和绕过方式。我按出现频率和危害程度排个序讲讲成因和判断方法。2.1 业务逻辑漏洞开发最常犯、测试最该抓的错业务逻辑漏洞是移动端渗透里性价比最高的类别因为不需要多高深的技术纯粹是开发在写代码的时候没有考虑攻击者的视角。典型的例子包括登录接口没有失败次数限制可以无限跑密码。验证码不失效同一个验证码反复用。密码找回流程里最后一步设置新密码的接口没有绑定会话攻击者可以构造请求直接给任意用户重置密码。支付流程里传金额的接口参数没有做服务端二次校验把1元的商品改成0.01元照样下单成功。这类漏洞的共同点是服务端过度信任客户端的输入。开发者觉得客户端已经做了限制服务端就不用管了结果就是攻击者只要绕过客户端直接构造数据包就能拿到预期之外的权限或结果。判断这类漏洞的核心方法就一句话多问几个“如果”。如果客户端不传这个参数会怎样如果传一个负数会怎样如果一个请求重复发三次会怎样测试的时候把正常的业务流程用Burp拦截下来然后逐字段去看哪些是客户端可控的哪些是服务端自己生成的可控的字段就是潜在的突破口。2.2 传输层与存储层风险数据在路上的保护传输层的核心问题是加密不完整和证书校验缺失。有些App只在登录接口用了HTTPS其他接口全部HTTP明文传输用户的订单信息、个人资料就在网络上裸奔。还有些App虽然全站HTTPS但代码里把证书校验写成了允许所有证书等于在门口挂了个锁但锁从来不锁。存储层的风险更是普遍。很多App把用户Token、甚至登录密码直接用SharedPreferences明文存储Root过的手机上任何一个App都能读取。有些数据库文件没有加密用SQLite打开就能看到全部表结构和数据。还有把日志打到Logcat里的用户的手机号、身份证号、银行卡号全写在调试日志里正常情况下开发完就该关掉的结果一路带到生产环境。这类问题有个共性都是在“数据生命周期管理”上偷懒。安全并不是只在传输或存储的某一个环节做加密就够了而是从客户端产生数据、传输数据、服务端处理数据、再到落盘存储的完整链条上每一步都要有对应的保护。2.3 WebView与第三方组件风险移动端的“网页后门”WebView是移动端一个非常特殊且风险密集的攻击面。很多App为了开发效率大量使用H5页面承载业务逻辑。这就意味着WebView的配置直接影响安全状态。最常见的错误是开启了setJavaScriptEnabled后没有做任何管控同时又在addJavascriptInterface里注入了可供页面调用的Java对象。如果App允许加载外部URL而攻击者能控制这个URL的内容比如通过URL Scheme注入参数就能在JavaScript里调用Java对象的方法轻则窃取本地数据重则直接执行系统命令。第三方组件的问题是引入成本低、排查成本高。很多App里集成了十几个甚至几十个第三方SDK有些已经很旧了CVE一查一大堆。测试的时候可以关注App包里的第三方库版本和公开漏洞库做个对照。组件虽然不是你写的代码但漏洞影响的是你的用户。3. 从零复现三个典型漏洞实例分析这一部分我挑三个实际测试中遇到过且具有代表性的漏洞实例按“发现过程-利用思路-结果验证”的顺序展开写。涉及的具体域名、App名称和信息都做了处理大家看思路就好。3.1 实例一登录接口的批量撞库尝试与风控缺失目标是一个创业公司的业务App登录页面是标准的账号密码模式。我怀疑测试的第一步永远是看看登录接口有没有防暴力破解机制。用抓包工具拦截正常的登录请求可以看到请求体里包含手机号和密码两个字段。我先把密码改成错误的连续提交5次每次都返回“账号或密码错误”。然后我把密码改成正确的确认能正常登录。这至少说明服务端对密码的校验本身没问题。接下来测频率限制。我用Burp的Intruder功能对同一个手机号跑一个包含50个密码的字典观察返回结果。一个很危险的现象就出现了50次请求全部返回了业务层的响应没有任何一个请求触发验证码、账户锁定或接口限流。用同一个账号在短时间内发出几十次登录请求服务端完全没有异常反应这基本就是撞库即用密码字典批量尝试登录可以直通的状态。为什么会有这个问题开发者在设计上可能默认了“客户端已经做了验证码校验所以服务端不用再做频率限制”。但客户端限制是防正常用户的攻击者根本不经过客户端直接构造数据包就能绕过。从修复角度看服务端必须独立实现登录风控策略同一账号短时间内失败次数超过阈值就锁定一段时间并强制验证码同一IP的请求速率也要限制超过阈值直接拒绝。而且这些策略要区分正常业务和异常流量不能因为加了限制就把自己的真实用户也挡在门外。3.2 实例二订单金额篡改——服务端不信任参数的代价这个实例更有意思是在一个电商类App的支付流程里找到的问题。正常下单流程是用户选择商品点击购买生成订单然后跳转到收银台支付。我用抓包工具拦截下单请求发现请求体里除了商品ID和数量之外还有一个“totalPrice”字段数值正好是商品单价乘以数量。看到这种客户端传价格的接口第一反应就是改价格试试。我把totalPrice改成0.01元其他参数保持不变转发请求。服务端返回了订单创建成功的响应订单号正常生成。再去看收银台的待支付订单金额显示的正是我改过的0.01元。问题出得更深支付成功后我查了订单详情服务端对这个订单记录的实际支付金额就是0.01元而不是商品原价。这说明服务端压根没有在支付回调里对订单金额做二次比对等于是完全信任了客户端上传的价格数据。这个漏洞的危害不用多说如果被批量利用平台每一单都净亏。修复的核心原则就是一条凡是涉及金额、数量、积分的计算一律以服务端数据为准客户端传上来的数值只能作为展示参考不能作为计算依据。订单商品的价格应该从服务端商品库获取支付回调时对比金额不一致直接告警并冻结订单。3.3 实例三越权访问数据——水平越权的定位与利用越权访问是我个人认为最值得重视的一类漏洞因为它的危害极其直接攻击者只需要改一个ID就能看到别人的数据。这次是在一个社交类App的私信功能里发现的。抓包拦截查看私信详情的请求请求路径大概是“/api/message/detail”请求参数里有个“messageId”字段。我把自己私信列表里的一条真实消息的ID记录下来正常请求能返回内容。然后我把messageId改成相邻的另一个数字比如原先是10086改成10087。结果服务端直接返回了另一个账号的私信内容。再往后一测这个接口完全没有做归属校验只要知道messageId就能读取任意人的私信全文。这类“水平越权”的设计误区在于开发者用了一个很难猜的ID或UUID当参数就以为安全了但实际上只要ID是连续的或者可预测的就能被遍历。而真正的防越权逻辑应该是服务端在处理请求时先获取当前登录用户的身份然后校验请求的资源是不是属于这个用户不属于就拒绝。所有涉及数据查询的接口都过一遍这道校验越权漏洞就能被堵住绝大部分。4. 渗透路上的拦路虎常见问题与排查技巧实战和理论之间最大的差距就是你会不会处理那些“救火”场景。移动端测试尤其如此环境问题、工具报错、App的对抗手段随时可能让你卡壳半天。下面这些是我遇到比较多的直接列出来分享。4.1 抓不到包HTTPS证书校验与代理检测抓不到包是移动端测试的头号问题。最常见的场景是手机设好代理、证书也装上了但App网络请求一到Burp里什么都看不到。第一反应先确认证书装的位置对不对。Android 7以上系统对用户证书的限制很严很多App在WebView或OkHttp里默认不信任用户证书。解决办法是把抓包工具的根证书push到系统证书目录。具体操作是先算出证书的hash文件名然后以root权限复制到/system/etc/security/cacerts/下重启手机。第二类情况是App做了SSL Pinning证书绑定。开发者在代码里只信任自己服务器的证书抓包工具的证书即使被系统信任也会被识别为无效。对付SSL Pinning最简单的方式是用Frida Hook掉证书校验的相关方法。常见的Hook点是OkHttp的CertificatePinner类或者WebView的onReceivedSslError方法。用Frida脚本在运行时把校验结果强制改为通过就能正常抓包。第三类更棘手是代理检测。App里用NetworkSecurityConfig或者在代码里明确检测了系统代理设置检测到代理就拒绝网络请求。这种情况下把流量转发到透明代理网关同时在手机上不设置代理。这样App感知不到代理的存在但流量依然经过抓包工具。注意以上所有操作都是针对授权测试的用在你有权限测试的目标上没有任何问题。请不要把这类技巧用于非法目的。4.2 动态调试被反调试拦下现在稍微有点安全意识的App都会在代码里加入反调试逻辑。Frida一启动App就闪退这是最常见的一个现象。反调试的基本原理是检测有没有Frida服务在运行、有没有调试器附加、文件系统中有没有Frida的特征文件。针对这些检测点规避思路也就对应着来改Frida的默认端口、用frida-server改名、Hook掉检测函数让它返回假结果、或者用一些更隐形的方式加载Frida脚本。比较通用的做法是先用静态分析找到反调试的核心逻辑通常是一个native方法然后用Frida在早期阶段就Hook住这个函数。但反调试和绕过反调试本身是一场攻防对抗游戏不存在一劳永逸的方案。我的经验是先把App跑起来、能正常进入主界面是第一目标不要追求一次到位一步一步破掉检测点。还有一个技巧是遇到反调试先检查App是不是做了系统签名校验。有些App检测到自己不是被官方签名就直接不启动或进入受限模式。这种情况下用Magisk的MagiskHide或者定制ROM的方案就能解决。4.3 加固与混淆后的分析思路现在主流的安卓App基本都会上加固。所谓加固简单理解就是给APK套了一层壳把原始的Dex文件加密之后藏起来运行时再动态解密加载。这导致jadx反编译出来的只有壳代码真正的业务逻辑看不到。面对加固App有两条路线。一条是从运行时入手App运行起来之后内存里一定存在解密后的Dex用Frida的DexDump或FRIDA-DEXDump这类工具把内存中的Dex脱下来再进行分析。这条路线成功率很高只是需要App能正常跑起来。另一条路线是重打包。有些App不做完整的反调试检测只是用加固壳保护代码。这时候可以用脱壳工具在模拟器上对APK进行一键脱壳拿到原始Dex后再用jadx分析。加固厂商也会不断升级方案来对抗脱壳所以这两条路经常要交替使用。混淆比加固温和一些但也很挠头。现在很多App用了代码混淆加上字符串加密类名和变量名全变成无意义的单字母核心字符串全部做了加密处理直接搜索关键词基本搜不到。应对方式是在运行时用Frida主动调用解密方法或者直接动态跟踪关键函数不依赖静态分析的结果。5. 从攻击视角再回到防御这些漏洞怎么修做渗透测试从来不是为了证明某个系统有多烂而是为了让系统变好。最后一部分聊聊修复策略我把前面几类漏洞的修复思路串起来讲这样测试和研发两边的人都能对得上。5.1 服务端永远不要信任客户端这句话我愿意重复一万遍。绝大多数高危漏洞的根因往回挖都能挖到“服务端太信任客户端”。具体落地的时候可以从三个层面去做首先是身份认证层面每次请求的会话校验必须完整不能因为App登录了就默认后续所有请求都是安全的。其次是参数校验层面所有客户端传上来的参数都要过一遍白名单校验数字就校验数值范围枚举就校验取值域。最后是重复校验层面关键业务节点比如支付、改密、提现要做二次校验甚至再次输入密码确认。服务端的“不信任”不是错觉而是默认所有网络请求都是可疑的只有通过了校验才算可信。这种思维转向是修复一切客户端安全问题的总前提。5.2 敏感数据的全链路保护数据传输要使用HTTPS并且证书校验必须严格开启。同时证书绑定的实现要合理不能因为加了绑定就导致证书更新困难也不能因为怕麻烦就彻底关闭证书校验。云端下发证书指纹列表是常见的折中方案。数据存储要分级Token和密钥放进Keychain或Keystore业务数据加密后落库图片文件放在应用私有目录。日志里不能出现任何用户隐私信息Debug级别的日志必须在发版时关闭。安全团队可以定期扫描构建产物检测有没有硬编码密钥和敏感日志。对用户敏感数据的明文存储建议上线扫码工具自动审计人工审核根本盯不过来规则是“不允许在SharedPreferences里出现password这类字段名”简单直接先挡住大多数问题。5.3 客户端加固与监控的平衡客户端加固确实能提高攻击者的分析成本但不要神话加固。代码混淆、反调试、反模拟器检测这些手段只能拖延时间做不到完全防住。真正的纵深防御应该把钱花在服务端风控和监控上。用户行为风控可以做起来新设备登录、常用设备变更、异地登录这些事件都应该有告警。业务风控系统可以实时识别异常行为比如同一设备短时间内大量注册、批量改密、高频下单自动触发人工审核或阻断。攻击者绕过客户端容易绕过服务端的风控模型要难得多。定期做外部测试、上线前做安全评估、对已知漏洞做修复闭环跟踪这三件事比堆砌一堆“看起来很安全”的加固功能更重要。安全不是买来的是持续运营出来的。我个人在实际测试中最大的体会是移动端渗透测试的产出价值不在于你发现了多少个漏洞而在于你能不能让团队真正理解“攻击者视角”。技术本身没有善恶但用技术的人必须心中有边界。合规获得授权、发现问题、推动修复这是每个安全从业者都应该坚持的基本底线。动手实践的时候先从自己的项目或者有明确授权的靶场练起一点点积累感觉。移动端安全没有一蹴而就的捷径但踩过的坑和总结的经验都会成为你长期的底气。