漏洞POC验证

凌晨两点十七分，漏洞我盯着屏幕上那个闪着绿光的漏洞id=1参数，手指悬在回车键上。漏洞这已经是漏洞第三十七次尝试了。目标站点的漏洞WAF像个尽职的保安，每次我注入到一半就被拦下来。漏洞但这次不一样——我换了个编码方式，漏洞把payload塞进了User-Agent头里。漏洞

回车。漏洞三秒后，漏洞页面弹出一个对话框，漏洞显示sql syntax error near '1'。漏洞成了。漏洞这不是漏洞报错，是漏洞胜利的号角。

POC验证这事儿，说白了就是拿一把钥匙去试一把锁。但没人告诉你的是，这把锁可能根本不在门上——它在天花板上，在排水管里，甚至在你以为的保险库墙上画着假门。我见过太多人拿着网上抄来的POC脚本，对着一个压根不存在的漏洞目录狂轰滥炸，最后只能对着404页面发呆。

真正有效的验证过程，往往像拆炸弹。你得先摸清线路：order by探测字段数，union select找显示位，再一步步把数据库版本、当前用户、表名给哄出来。每一步都可能触发警报，每一步都需要换个姿势。有时候你得像变戏法一样把payload拆成几段，塞进不同的请求头里，让WAF以为这只是几个无害的普通请求。

记得有一次测一个金融系统的登录接口，参数全被加密了。常规思路直接死路。我盯着抓包数据看了半小时，发现时间戳后面跟着一个固定长度的哈希值。试着把用户名改成admin'，哈希值变了。再改成admin'--，哈希值长度短了两位。那一刻我后背发凉——开发者把参数拼进SQL后做了哈希，但哈希前的字符串已经注入了。整个验证过程像在玩一场无声的密室逃脱，每解开一环都让人头皮发麻。

但POC验证最坑人的地方在于——它验证的是“能打通”，不代表“能利用”。打个比方，你发现了一把钥匙能开锁，但这锁后面连着的可能是个空房间。前几天测一个文件上传点，POC成功绕过了类型检查，传上去了一个.jpg后缀的脚本。可访问的时候才发现，服务器把上传目录的解析给禁了，文件在浏览器里直接以纯文本形式展示出来，代码原封不动地吐在屏幕上——这不算漏洞，顶多算个笑话。

真正实用的POC得带上“利用链”思维。上传点绕过了只是第一步，你得确认脚本能执行、能连接外网、能回连你的监听端口。每个环节都像多米诺骨牌，倒下第一张不代表后面全倒。我习惯在验证脚本里加上一个sleep(5)的时间盲注判断，如果响应延迟超过五秒，说明数据库确实执行了我们的语句——这种实锤比什么错误回显都靠谱。

当然，验证过程也得讲武德。拿到授权再测，这是底线。我见过有人对着一个政府网站跑全套POC，最后把自己送进了看守所。漏洞验证是技术活，不是莽夫行为。你得像外科医生一样精准，每一刀都切在病灶上，而不是把病人开膛破肚。

写POC验证脚本的时候，我习惯把每一步的关键输出都打上[+]标记。成功一个，绿色加号亮一个。那种感觉像在打街机游戏，每过一关屏幕就闪一下光。但真正的老手都知道，最刺激的不是最后的root shell，而是那些被卡住的瞬间——服务器返回500，日志里一片空白，你盯着屏幕怀疑自己是不是压根走错了路。

然后你换个参数，重新构造一个payload，页面正常加载，数据正常显示。你才发现，原来漏洞一直都在，只是你之前用的姿势不对。

这行当就是这样，没有银弹，没有万能脚本。每一次验证都是和系统的一次对话——你得听懂它说的话，还得猜它没说的话。POC验证不是终点，它只是告诉你一个可能性的存在。剩下的路，得靠你一步一步踩实了走。