漏洞验证POC：不是漏洞炫技，是验证给漏洞拍一张X光片

一个POC（Proof of Concept，概念验证）写得烂，漏洞比漏洞本身更让人抓狂。验证上个月我拿到一个CMS的漏洞SQL注入报告，POC里只贴了报错页面截图，验证没给完整的漏洞请求包。我花了三个小时猜参数名，验证最后发现注入点藏在Cookie的漏洞某个加密字段里——这哪是验证漏洞，分明是验证考逆向工程。

真正的漏洞POC应该像法医的解剖报告，直接告诉别人“伤口在哪、验证怎么捅的漏洞、捅多深”。验证它不需要花哨的漏洞弹窗特效，但要能复现。我见过最干净的POC就三行：一个curl命令，一个时间延迟对比，加上一句“响应慢了4.2秒，说明sleep(4)被执行了”。没有多余解释，但任何人拿到就能复现。

写POC有个常见的误区，总想证明漏洞“有多严重”。有人为了演示RCE（远程代码执行），直接在目标服务器上跑了个反弹shell，结果把生产库删了。兄弟，验证漏洞不是搞破坏，你只需要证明“这个输入能触发异常行为”就够了。比如命令注入，执行个`id`或者`whoami`，把输出贴出来，比什么都直观。非要弹计算器？那是给自家测试机准备的仪式感。

另外，POC里的细节决定了它的价值。请求头里哪个字段是脏数据？是GET参数还是POST体？编码有没有绕WAF？这些都得写清楚。我见过一个POC，只写了“在参数x处注入payload”，但没说这个参数值会被URL解码两次。结果别人复现时直接传原始payload，被过滤得干干净净，回头骂作者是骗子。所以，写POC时把自己当导游，把每一步的坑都标出来，别让后来者掉进去。

说实话，现在很多公开的POC质量堪忧。GitHub上一搜一大把，但三分之一跑不起来，三分之一是环境特定的，剩下三分之一里还有一半是拿工具自动扫的，连漏洞原理都没搞懂。我印象很深的一次，某个知名框架的任意文件读取POC，居然把路径写死成`/etc/passwd`，换个Windows靶场直接废掉。写POC的人可能压根没想过，别人会在不同环境下用它。

POC最终要回答的问题是“这个漏洞是不是真的”。它不需要长篇大论的分析，但要让人信服。我自己的习惯是：先跑通最小复现，再补上影响说明。最小复现就是“给什么输入，得到什么异常输出”，影响说明则是“这个异常能不能被利用”。两样凑齐，这份POC才算合格。

说句得罪人的话，那些把POC写成论文的，多半是没抓过真实漏洞的新手。老手都明白，漏洞验证的本质就是“用最笨的方式证明一件危险的事”。别整那些花里胡哨的，直接、可复现、带上下文，这才是POC该有的样子。