信息安全渗透测试

去年秋天，信息我帮一家做跨境电商的安全朋友看他们刚上线的支付系统。凌晨两点，渗透我用一个普通的测试测试账号登录，在优惠券兑换接口的信息请求包里，把 coupon_id 参数从 1001 改成了 1001' OR '1'='1。安全页面没报错，渗透直接返回了价值 500 美元的测试代金券。朋友在电话那头沉默了十几秒，信息然后说：“这玩意儿上线前找外包测过，安全报告写的渗透‘无高危漏洞’。”

这就是测试渗透测试和普通安全扫描的区别。扫描器只会告诉你“这个参数可能存在 SQL 注入风险”，信息而渗透测试员要做的安全是真正拿到那张代金券，截图，渗透然后写进报告里。前者是体检报告上的“建议复查”，后者是直接切开了给你看肿瘤长什么样。

很多人把渗透测试和漏洞扫描混为一谈。我见过不少公司买了扫描器，每周跑一次，导出 PDF 就算完成了安全测试。这跟用体温计判断有没有得癌症差不多——发烧了确实可能有问题，但没发烧不代表你没事。扫描器依赖特征库，只能发现已知的、模式化的漏洞。一个逻辑漏洞，比如“修改订单 ID 可以查看他人收货地址”，扫描器根本理解不了，因为它不知道那个 ID 意味着什么。

渗透测试的核心是人。人知道业务怎么跑，知道哪个接口刚改过，知道开发在注释里留了测试后门。我见过一个案例：某 App 的登录接口做了频率限制，扫描器试了几次就放弃了。但测试员发现，注册接口没有限制，而注册成功后返回的 token 竟然和登录 token 格式一样。他用注册接口批量拿 token，再拿这些 token 去撞用户数据接口，最后拿到了三万多条手机号。这种路径，自动化工具写不出来。

做渗透测试这些年，我最大的感受是：漏洞往往不在代码本身，而在人对代码的假设里。开发觉得“这个接口只有 App 会调”，所以不做鉴权；运维觉得“内网很安全”，所以数据库密码用 123456；产品觉得“用户不会改这个参数”，所以价格直接放在前端计算。每一个“觉得”背后，都是一个可以被利用的缺口。测试员的工作，就是把这些“觉得”一个个戳破。

工具当然要用。Burp Suite 抓包改包，Nmap 扫端口，sqlmap 跑注入，这些是基本功。但工具跑完之后的思考才是分水岭。看到一个登录接口，我会想：能不能绕过前端校验直接发请求？能不能枚举用户名？验证码是不是在本地生成的？返回包里的 user_id 是不是自增的、能不能遍历？这些问题没有标准答案，得靠经验和对业务的理解去猜、去试。

如果你打算自己做一次渗透测试，别一上来就上工具。先拿张纸，把系统的业务流程画出来：用户怎么注册、怎么登录、怎么下单、怎么支付、怎么退款。每个环节之间的数据怎么流转，哪些参数是用户可控的。画完之后，挑那些“用户可控且直接影响业务结果”的点下手。比如价格、数量、用户 ID、订单状态。改它们，看系统什么反应。大多数漏洞就藏在这些地方。

最后说一句可能不太中听的：渗透测试报告不是用来交差的。我见过太多报告，列了二十个低危漏洞，凑了三十页，真正能打的就一个。与其这样，不如把那个能打的写清楚：怎么发现的、怎么利用的、能造成什么损失、怎么修。剩下的时间，去喝杯咖啡，想想如果你是攻击者，下一步会打哪里。