APP渗透

去年帮一个做电商的朋友看他的App，登录接口用Burp抓包，把手机号改成另一个测试账号，返回包里直接带出了对方的收货地址和订单记录。没鉴权。他愣了半天，说这App上线两年了。两年，没人发现。

App渗透和Web渗透最大的区别在于，你面对的是一个装在别人手机里的东西。服务器你看不见，代码你摸不着，只有一个APK或者IPA摆在那儿。但这个安装包本身就是一座金矿——反编译之后，硬编码的API密钥、测试环境的地址、注释掉的调试接口，全在里面躺着。

我习惯先跑一遍apktool d，把资源文件和smali代码倒出来，然后grep -r "http"。十次有八次能翻出几个没在文档里出现过的域名。有的是灰度环境，有的是内部管理后台，认证强度往往比生产环境低一大截。开发者总觉得这些地址藏得够深，但字符串搜索不答应。

抓包是另一道坎。现在稍微正规点的App都上了SSL Pinning，Frida脚本得备好。Objection一条命令android sslpinning disable能解决大部分情况，遇到Flutter或者React Native写的，就得换思路。有次碰到一个用Unity做的App，流量走的不是标准HTTP栈，最后是hook了libmono才拿到明文。

接口测起来跟Web差不多，越权、注入、逻辑漏洞，老三样。但App有个特殊的地方：客户端逻辑不可信。很多业务校验只在前端做，比如优惠券的金额计算、会员等级的判定。把请求拦下来改个参数，服务器照单全收。我见过一个签到功能，客户端判断“今天是否已签到”，服务器端压根不验证，重放请求就能无限刷积分。

还有一类问题出在本地存储上。SharedPreferences里明文存token算轻的，有的直接把用户密码写在SQLite数据库里。Root过的手机，adb backup一把梭，数据全出来。iOS稍微好点，但Keychain用错权限的情况也不少。

组件暴露是Android的老毛病。Activity、Service、BroadcastReceiver设成exported，其他App就能直接调。配合intent重定向或者pendingintent劫持，能玩出不少花样。Google这几年收紧了默认配置，但存量App里一抓一大把。

说个具体的。某次测一个金融类App，发现它有个WebView加载外部URL的功能，而且addJavascriptInterface注册了一个桥接对象。导出的JS方法里有个getUserInfo()，返回当前登录用户的身份证号和银行卡。只要诱导用户打开一个恶意页面，数据就到手了。这个漏洞的根因是开发图省事，把WebView当成了万能容器。

渗透测试报告写完，修复建议列了一长串。但真正落地的时候，开发团队往往只改最紧急的那几个。剩下的？排期排到明年。安全这事，永远是业务和风险之间的拉扯。你能做的，是把最要命的那条路径堵死，剩下的，交给时间和运气。

工具在变，Frida、Xposed、Unidbg，每年都有新东西。但核心没变过——找到那个信任边界被打破的地方。App再复杂，它终究是个客户端，而客户端的一切，用户都能控制。