去年帮一个客户做渗透测试，全渗目标是透测一个看起来平平无奇的电商后台。登录框、试实验证码、全渗密码找回，透测功能齐全。试实我试了默认口令，全渗admin/admin，透测进不去。试实又试了SQL注入，全渗WAF拦得死死的透测。折腾半小时没进展，试实干脆换个思路，全渗去看它的透测密码找回逻辑。

输入手机号，试实点获取验证码。抓包，发现返回包里直接带了验证码——{ "code":200,"msg":"发送成功","smsCode":"483921"}。后端把验证码回显给前端了，这等于门没锁。用这个码重置了管理员密码，登录后台，拿下了整个站点。整个过程没用到任何高级工具，就是看了一眼HTTP响应体。

这就是Web渗透测试的日常。大部分漏洞不是靠什么0day打下来的，而是开发人员在某一行代码上犯了懒或者犯了错。

渗透测试到底在测什么

很多人以为渗透测试就是拿扫描器跑一遍，出一份报告。扫描器能发现的东西，比如过时的jQuery版本、缺失的HTTP安全头，有价值，但远远不够。真正有意思的漏洞，扫描器扫不出来。

举个例子。一个网站的用户资料页，URL是 /user/profile?uid=1024。你把uid改成1025，看到了别人的邮箱和手机号。这是水平越权。扫描器不会去改这个参数，因为它不知道1025代表另一个用户。只有人，理解了业务逻辑，才会去试。

再比如，一个转账接口，前端限制了单笔不超过5000元。你抓包把金额改成50000，后端没做校验，直接通过了。这是参数篡改。扫描器同样不会做这种事，因为它不理解“5000”这个数字在业务上意味着什么。

渗透测试的核心不是工具，是思维方式。你得站在开发者的角度想：他写这段代码的时候，假设了什么？然后去打破那个假设。

一个完整的测试流程长什么样

信息收集阶段，我一般先跑一遍子域名枚举。很多公司的主站防护严密，但测试环境、 staging 环境、旧版系统直接暴露在公网上，没有任何防护。有一次通过子域名找到一个 test.xxx.com，上面跑的是两年前的代码，SQL注入一打一个准。从测试环境入手，再横向移动到生产环境，这条路比正面硬刚高效得多。

拿到入口之后，常规检查清单会过一遍：SQL注入、XSS、CSRF、文件上传、命令执行、SSRF。但清单只是底线，真正花时间的是理解这个应用特有的业务逻辑。比如优惠券能不能重复领取？订单金额能不能改成负数？密码重置的token有没有时效？这些问题没有标准答案，得自己去摸索。

找到漏洞之后，写报告是另一回事。客户要的不是“你的系统有SQL注入”，而是“攻击者可以利用这个注入点读取用户表，影响约30万条记录，建议在search接口的keyword参数处使用参数化查询”。定位到具体代码行，给出修复方案，这才算完成。

一些个人体会

干了几年渗透，最大的感受是：安全问题的根源几乎永远是人的问题。开发赶进度，安全测试被压缩到上线前一天；运维图省事，数据库端口直接对公网开放；产品经理设计功能时压根没考虑过滥用场景。技术漏洞只是表象。

另外，别迷信自动化工具。Burp Suite的主动扫描我经常开着，但它报出来的“高危”有一半是误报，真正的高危它反而漏掉。工具是辅助，脑子才是主力。每次测试之前，花二十分钟把目标应用的业务流程走一遍，比直接上扫描器有用得多。

最后说一句，渗透测试必须在授权范围内进行。没有书面授权就去测别人的系统，那不叫渗透测试，叫非法入侵。技术本身没有对错，用在哪里才是问题。