去年冬天，网站网站我帮一个做电商的渗透朋友看他的服务器日志。凌晨三点，测试有人用脚本在批量请求他的网站网站后台登录接口，每秒十七次。渗透这不是测试电影里的黑客画面，就是网站网站最朴素的暴力破解。他问我：能不能提前知道谁会来搞我？渗透我说能，但得先自己搞自己一次。测试这就是网站网站渗透测试最直白的逻辑——在坏人动手之前，自己先当一回坏人。渗透

很多人把渗透测试和漏洞扫描混为一谈。测试扫描器跑一遍，网站网站出一份报告，渗透满屏红色高危，测试你觉得天要塌了。实际上那只是敲门。真正的渗透测试是推门进去，看看能拿走什么。我见过一个案例，扫描器报了一个低危的信息泄露，说某个API返回了用户ID。测试人员顺着这个ID做了遍历，发现可以拉到别人的订单详情，包括收货地址和电话。一个低危变成严重数据泄露，扫描器永远不会告诉你这个。

先搞清楚你面对的是什么

做渗透测试之前，得先画一张地图。域名、子域名、IP段、开放端口、使用的中间件版本、有没有CDN、有没有WAF。这些信息拼起来，就是攻击面。我习惯用几个命令行工具来回倒腾，比如用subfinder拉子域名，再用httpx探活，最后用nmap扫端口。别急着上扫描器，手工摸一遍往往能发现自动化工具忽略的角落。有一次我在一个子域名下发现了一个测试环境的Swagger接口文档，没有鉴权，里面列了所有内部API。测试环境的数据和正式环境共用一套数据库。这种事扫描器不会主动去找。

漏洞利用不是炫技，是验证风险

找到入口之后，要判断这个口子能捅多深。一个SQL注入点，如果数据库权限是只读，和能执行系统命令，完全是两个量级。我见过有人发现注入点就直接上sqlmap跑数据，结果把生产库拖垮了。渗透测试的底线是不影响业务。所以验证漏洞的时候，能读一条数据证明存在就够了，别真把用户表全导出来。另一个常见误区是拿到webshell就收工。实际上从webshell到域控，中间还有提权、横向移动、凭据窃取好几步。每一步都要记录，因为修复方案不一样。

报告不是给机器看的

我写过最难受的报告，是给一个开发团队看的。他们只想知道哪个文件哪一行有问题，怎么改。你写一堆攻击路径和风险评级，他们没耐心看。所以报告得分层：给管理层看影响和优先级，给运维看修复步骤，给开发看代码位置。截图要带时间戳和请求响应，别用模糊的“存在漏洞”四个字糊弄。有一次我提交了一个SSRF漏洞，开发说“内网地址访问不了”，我贴了一张从他们服务器上请求内网Redis的返回结果，他立刻闭嘴去修了。

渗透测试不是一锤子买卖。你今天修了SQL注入，明天可能因为新上线的功能又开了一个口子。我自己的习惯是每季度对自己维护的几个站点做一次轻量级自测，重点看新接口和权限变更。工具用nuclei跑一遍已知漏洞模板，再手工看看逻辑漏洞。逻辑漏洞是扫描器的盲区，比如越权查看订单、修改价格、绕过支付。这些只能靠人脑去推演业务流程。

说到底，渗透测试网站这件事，心态比技术重要。你得假设自己是一个有耐心的攻击者，不放过任何一个异常返回，不跳过任何一个看起来没用的参数。同时你得守住底线，不破坏数据，不扩大影响。最后，别把报告锁在抽屉里。修一个漏洞比写十份报告都有用。