内容摘要：凌晨两点，我盯着Burp Suite里那条被拦截的HTTP请求，把参数从`id=1`改成`id=1' AND 1=1--`，页面返回了和之前一模一样的内容。再换成`id=1' AND 1=2--`，页

凌晨两点，渗透师我盯着Burp Suite里那条被拦截的测试HTTP请求，把参数从`id=1`改成`id=1' AND 1=1--`，工程页面返回了和之前一模一样的渗透师内容。再换成`id=1' AND 1=2--`，测试页面空了。工程就这一下，渗透师我心里有数了——这地方能注。测试

很多人以为渗透测试工程师就是工程坐在暗房里敲键盘、屏幕上一串串绿色代码往下滚的渗透师那种人。不是测试。这活儿更像装修队里的工程验房师，拿着小锤子东敲敲西敲敲，渗透师找的测试是承重墙上的裂缝。区别在于，工程我们敲的是别人家的系统，而且必须拿到书面授权才能动手。

先搞清楚“能碰什么”

授权书是这行的入场券。没有它，你干的叫黑客攻击，不叫渗透测试。我见过新人上来就问“怎么黑进某某网站”，这种问题本身就暴露了认知偏差。正规流程里，客户会划定目标范围——哪些IP、哪些域名、哪些接口可以测，哪些绝对不能碰。生产环境和测试环境往往要分开对待，因为一个不小心把生产库跑挂了，赔偿单能让你白干半年。

我习惯在开工前把scope文档打印出来，用荧光笔标出边界。测试过程中每发现一个漏洞，先截图、存请求包、记录时间戳。证据链完整，后面写报告才不心虚。

信息收集比漏洞利用更磨人

新手总想直接上扫描器，Nessus、AWVS一顿跑，然后拿着报告交差。这么做不是不行，但漏报率高得吓人。真正花时间的环节是信息收集：子域名枚举、端口扫描、目录爆破、指纹识别、GitHub上翻泄露的密钥。有时候一个不起眼的测试接口，参数里藏着数据库连接串，比主站好啃得多。

上个月做的一个项目，主站WAF厚得跟城墙似的，扫了半天没动静。后来在子域名里翻到一个`test.xxx.com`，上面跑着三年前的老版本CMS，默认口令没改。从那里拿到webshell，再横向到内网，最后摸到了主站的数据库。整个过程最关键的突破点，就是那个被遗忘的子域名。

漏洞利用是手艺活

SQL注入、XSS、文件上传、SSRF、反序列化——这些名词听着唬人，实际干起来就是不断试错。同一个注入点，WAF拦了union select，那就试报错注入；报错被过滤，那就试盲注；盲注太慢，那就试dnslog带外。工具是死的，思路是活的。

我包里常备几个自己写的小脚本，专门对付那些奇奇怪怪的过滤规则。比如某个站把空格全吃了，那就用`/**/`代替；把`select`关键字ban了，那就用`sel%00ect`绕过。这些招数网上都有，但能不能用上、什么时候用，靠的是对目标系统行为的观察。

报告才是最终交付物

挖到漏洞只是前半程，把漏洞讲清楚才是后半程。客户的安全团队可能不懂技术细节，但要知道风险等级和修复建议。我写报告的习惯是：每个漏洞配一张截图、一段复现步骤、一句人话解释。高危漏洞放最前面，修复方案具体到改哪行配置、升哪个版本。

有次交完报告，客户的技术负责人打电话过来，说按我给的方案改完之后，又自己跑了一遍扫描器，确认漏洞关了。那一刻比拿到项目款还舒服。

这行干久了，看什么都想点右键查看源代码。有回在便利店结账，盯着收银机的界面愣了半天——那玩意儿跑的是Windows CE，版本老得能进博物馆。当然，只是看看，没动手。