渗透测试不是渗透拿着扫描器跑一遍就完事。我见过太多人把Nessus或AWVS的测试报告直接甩给客户，说“这就是概念渗透测试结果”。那顶多叫漏洞扫描。渗透真正的测试渗透测试，是概念模拟真实攻击者的思路和手法，在不破坏业务的渗透前提下，一步步撕开目标防御的测试过程。它更像一场有规则的概念入侵演习，而不是渗透自动化工具的输出。
去年有个做电商的测试朋友找我，说他们刚做完一次“渗透测试”，概念报告显示“无高危漏洞”。渗透我让他把报告发来，测试翻了两页就发现不对劲——测试范围只写了外部IP，概念连登录接口都没碰。我问他，你们后台的订单查询接口有没有测过越权？他愣住。后来我花了一个下午，用普通用户账号登录，改了个订单ID，直接看到了别人的收货地址和手机号。这种逻辑漏洞，扫描器根本扫不出来。
渗透测试的核心在于“渗透”两个字。它要求测试者像攻击者一样思考：哪个入口最薄弱？哪个接口可能没做权限校验？哪个参数可能拼接进SQL？工具只能帮你发现已知模式的缺陷，但业务逻辑的坑，得靠人脑去挖。比如密码重置功能，如果验证码回显在响应里，或者重置链接的token可预测，这些都不是CVE能覆盖的。
流程上，一般分几个阶段。信息收集排第一位。你得知道目标有哪些域名、哪些子域、用了什么中间件、员工邮箱格式是什么。有一次我通过一个招聘页面上的邮箱命名规则，猜到了管理员账号是admin@公司域名，然后配合弱密码策略直接进了后台。这跟技术无关，纯粹是信息拼图。
接着是威胁建模和漏洞发现。这时候工具可以上场，但别依赖它。手动测试的重点放在认证、会话、权限、输入验证这些地方。比如JWT令牌，有没有校验签名？能不能改成none算法？再比如文件上传，黑名单绕过了吗？解析漏洞试了吗？这些细节决定测试的深度。
拿到漏洞之后，利用和维持访问是下一步。但注意，渗透测试不是破坏。你证明能进数据库就行，没必要把数据拖走。我习惯用最小化的证明方式——读一条数据、执行一条命令、弹一个计算器。客户要的是风险证据，不是烂摊子。
最后是报告。别堆砌术语，说人话。每个漏洞写清楚：怎么发现的、怎么复现、影响是什么、怎么修。我见过一份报告把“SQL注入”写成“数据库查询语句未经过滤导致攻击者可能获取敏感信息”，客户看完问“所以呢？”。直接写“攻击者可以拿到全站用户密码哈希，包括管理员”，效果完全不同。
渗透测试的边界也很重要。授权范围、测试时间、禁止操作（比如拒绝服务、社会工程）必须提前书面确认。有一次客户口头说“随便测”，我坚持要了授权书。结果测试中触发了WAF告警，他们运维差点报警。没那张纸，我可能就得去喝茶了。
这行做久了会发现，最危险的漏洞往往不是技术层面的，而是人的惯性。开发觉得“这个接口内部用，不用鉴权”，运维觉得“这个端口只对内网开放”，产品觉得“用户不会改这个参数”。渗透测试就是去打破这些“觉得”。