使用poc验证与检查漏洞的存在
用poc验证漏洞，使用本质上是证检把纸上谈兵变成真刀真枪的对抗。我见过太多安全工程师拿着CVE编号和漏洞描述就敢写报告，查漏存结果复现时连报错日志都对不上号。使用Poc（Proof of Concept）不是证检摆样子的玩具，它是查漏存漏洞存在的DNA检测试剂。
最典型的使用案例是去年某OA系统的任意文件上传漏洞。厂商公告里写着“攻击者可上传恶意脚本获取服务器权限”，证检但具体怎么绕过后缀名过滤、查漏存如何构造multipart数据包，使用公告一个字都没提。证检我拿到公开的查漏存poc脚本后，在测试环境跑了三遍——第一遍报404，使用第二遍报500，证检第三遍才成功上传了测试用的查漏存jpg文件。你看，连公开可用的poc都需要调参，更别提那些只存在于理论中的漏洞了。
验证过程讲究“三看”。一看响应状态码，200和302的含义天差地别；二看返回内容特征，比如SQL注入的报错信息里有没有数据库版本号；三看时间延迟，布尔盲注的响应时间差超过3秒基本就能确认。这些细节没有poc辅助，纯靠手工fuzz就像蒙着眼睛拆炸弹。
但poc验证有个致命陷阱——误报。去年某CMS的poc在检测目录遍历漏洞时，只要URL里出现“../”就判定存在漏洞，结果把正常功能模块也标记成了高危。后来发现是poc里用了过于宽泛的正则表达式，把静态资源路径也匹配进去了。所以我现在跑poc都会额外抓取完整请求包和响应体，人工核对关键特征，而不是只看脚本输出的“Vulnerable”字样。
真正专业的做法是分级验证。第一层用现成poc快速扫描，第二层根据漏洞类型手动构造变体payload，第三层直接看代码审计确认漏洞根因。遇到逻辑漏洞时，poc往往只能验证到“某个接口返回了异常数据”，但到底是因为鉴权缺失还是参数校验不严，必须跟开发要源码逐行排查。上个月测某支付系统时，poc成功绕过了折扣校验，但看了代码才发现是equals方法被重写导致字符串比较失效——这种深度只有人眼才能发现。
说到底，poc是一把钥匙，能开锁不代表你懂锁芯结构。安全报告里如果只写“已用poc验证”，那跟没写差不多。合格的验证应该包含触发条件、影响范围、修复建议，甚至要标注poc的适用版本。毕竟同一个漏洞在Windows和Linux环境下的表现可能完全不同，我就遇到过poc在Linux下能稳定复现，换到Windows服务器就失效的情况——因为路径分隔符差异导致payload构造失败。
最后说点实在的。如果你手头只有漏洞情报没有现成poc，别急着关掉页面。去GitHub搜项目名加CVE编号，去Exploit-DB翻历史记录，实在不行就自己写个简化版验证脚本。我认识一个白帽子，靠分析补丁diff自己写poc，效率比等公开poc高了整整三天。那三天里，他抢在其他攻击者之前帮客户堵住了漏洞。