app渗透测试：一场与开发者的渗试猫鼠游戏

凌晨两点，我盯着Burp Suite里那个加密的透测登录请求。用户名是渗试admin，密码经过了三层Base64和一次AES加密。透测这不算高明，渗试但足够让新手望而却步。透测我花了二十分钟才注意到，渗试那个AES密钥竟然硬编码在JavaScript文件里，透测注释还写着“TODO：上线前记得换”。渗试

这就是透测app渗透测试的日常。表面上是渗试跟代码较劲，实际上是透测在跟开发者的习惯博弈。大部分漏洞不是渗试技术不够，而是透测懒惰——把密钥写死在客户端，用HTTP明文传输，渗试或者干脆在日志里打印用户密码。我见过最离谱的，某银行app的调试接口没关，直接暴露了内部转账功能。

真正的难点从来不是破解加密算法，而是找到那些被忽略的业务逻辑漏洞。比如支付流程里，先创建订单再扣款，那我在创建订单后修改金额行不行？比如找回密码时，验证码只校验长度不校验内容——四位数字，我直接爆破，反正没有次数限制。

有一次测试某社交app，发现它的“附近的人”功能返回了用户的精确坐标。这不算漏洞，因为用户协议里写了会收集位置。但问题在于，它连隐身模式下的用户也暴露了。开发者显然没想过，隐身模式应该从API层面过滤掉位置信息。这种问题，静态扫描工具根本查不出来，只能靠人肉试。

我习惯把app装进模拟器，抓包、看流量、翻缓存。有时也直接反编译，看它混淆后的代码——大多数混淆只是把变量名改成a、b、c，逻辑还是明晃晃地躺着。曾经有个金融app，把安全密钥藏在一个叫“security_key.xml”的文件里，连文件名都没改。

做这行久了，你会摸清开发者的思维惯性。他们总爱把验证放在客户端，以为登录页多写几行if判断就万事大吉。可服务端才是最后一道防线，只要服务端信任了客户端的任何输入，漏洞就永远存在。有个经典案例：某电商app的商品价格存在客户端本地，提交订单时直接读取这个值。我改成0.01元，真买到了一台电视。

所以每当我拿到一个app，第一步就是看它怎么处理信任边界。先尝试绕过登录，再测越权，最后挖逻辑坑。这过程像解谜，也像心理战。开发者留下线索，我负责找茬。

说句实在话，很多app渗透测试报告写得再漂亮，如果开发者不改变“客户端什么都可信”的思维，漏洞还是会反复出现。你堵住一个SQL注入，他下个版本又用字符串拼接写了个新接口。安全不是一次性工作，而是持续对抗。而我，只是这场游戏里那个总在找钥匙孔的人。