去年秋天，渗透我帮一家做跨境电商的测试朋友看他们刚上线的后台系统。前端登录页做得挺漂亮，渗透验证码、测试密码强度提示一应俱全，渗透但我在地址栏后面随手加了个 `/api/v1/users`，测试页面直接吐出一串 JSON，渗透里面躺着三千多个用户的测试手机号和邮箱。朋友当场愣住，渗透说这接口前端根本没调用过，测试以为藏起来就没事了。渗透

这事说明一个很朴素的测试道理：渗透测试里，最危险的渗透往往不是那些看起来复杂的加密算法，而是测试开发者觉得“没人会知道”的角落。接口、渗透注释、备份文件、测试账号，这些东西在代码仓库里像杂物间一样堆着，攻击者不需要撬锁，推门就进去了。

我习惯把渗透测试点分成三类。第一类是“门没关”型，比如默认口令、未授权访问、目录遍历。去年有个金融类 App 的测试环境，管理员账号密码是 admin/123456，登录后能看到所有借款人的身份证照片。这种问题不需要什么技术，拿个浏览器就能干。第二类是“锁太假”型，比如前端做了参数校验，后端却裸奔；或者用了已知漏洞的旧版本组件。有个客户用了某开源 CMS 的 2.3 版本，我查了下 CVE，两年前就爆过 SQL 注入，他们运维说“内网系统，没事”。结果内网一台打印机被攻破后，直接横向连到了数据库。第三类是“藏得深”型，比如业务逻辑漏洞、越权访问、条件竞争。这类点最考验耐心，也最容易漏。

说个具体的。某次测一个预约系统，正常流程是用户选时间段、提交、系统扣减库存。我抓包后发现，提交订单的接口只校验了用户 ID 和时间段，没校验库存。也就是说，我可以用脚本同时发一百个请求，把同一个时间段全占了。系统显示预约成功，但实际库存已经变成负数。开发后来承认，他们觉得“用户不会那么快点击”，所以没加锁。这种就是典型的逻辑漏洞，扫描器扫不出来，得靠人脑去推。

还有一类点经常被忽略：第三方组件和云配置。现在很多项目用 Docker 和 K8s，开发图省事，把敏感环境变量直接写在镜像里。我见过一个镜像，里面藏着 AWS 的 access key，权限还是 S3 全读写。攻击者拿到这个 key，能把整个存储桶拖走。云上的问题更隐蔽，比如安全组开放了 0.0.0.0/0 的 6379 端口，Redis 没设密码，写个 SSH key 就能登录服务器。这些点不需要什么高深技巧，但杀伤力极大。

做渗透测试久了，会发现一个规律：越是被遗忘的地方，越容易出问题。开发忙着赶需求，运维盯着监控大盘，安全团队往往在项目上线前才被拉进来。那些临时接口、调试开关、旧版本备份，就像房间角落的灰尘，没人注意，但一直在那儿。我习惯在测试前先翻一遍 JS 文件，找找有没有硬编码的密钥、隐藏的 API 路径、或者注释掉的测试代码。十次里有三次能捡到东西。

最后说个个人判断。现在很多团队把渗透测试当成“过关考试”，扫一遍漏洞报告，改完就完事。但真正的风险往往不在报告里，而在那些“我们知道但觉得不重要”的地方。比如一个内部用的查询接口，没做权限校验，因为“只有运营会用”。可一旦运营的电脑中了木马，攻击者就能拿这个接口去查用户数据。渗透测试点的价值，不在于找出多少个高危漏洞，而在于帮团队看清：哪些地方他们以为安全，其实早就敞着门。

(责任编辑：娱乐)