去年冬天，洞检一个朋友让我帮忙看他们公司刚上线的洞检一个API网关。他给了我一个域名，洞检说“随便测，洞检老板授权的洞检”。我打开Burp Suite，洞检抓了个登录请求，洞检把用户名参数后面的洞检值换成一个单引号，服务器回了500。洞检再换成两个单引号，洞检正常返回。洞检经典的洞检SQL注入信号，前后不到三分钟。洞检

这就是洞检POC漏洞检测的日常。不是洞检电影里那种敲几行代码就黑进五角大楼的戏码，更多时候，它像用一把钥匙去试一扇门——你手里有几十把形状各异的钥匙，一把一把捅进去，看哪把能转动。转开了，就证明这扇门有锁的问题。至于门后面有什么，那是下一步的事。

POC这三个字母，Proof of Concept，翻译过来叫“概念验证”。听起来挺学术，实际操作中它就是一个脚本、一段请求、甚至一行curl命令。核心逻辑只有一条：用最小的成本，证明漏洞真实存在。注意，是“证明存在”，不是“利用漏洞”。这两者之间的差距，有时候比漏洞本身还大。

我见过太多人把POC和EXP搞混。EXP是Exploit，是武器，能直接拿到shell、拖走数据。POC更像是验孕棒——它告诉你“有了”，但不负责帮你养孩子。写POC的人往往比写EXP的人更克制，因为POC的使命是精确、可复现、不造成破坏。一个合格的POC，应该让任何人在任何时间跑一遍，都能得到同样的结果：漏洞在，或者不在。

拿Log4j2那个核弹级漏洞来说。2021年12月9日晚上，整个安全圈都在传那个${ jndi:ldap://}的字符串。第二天早上，我打开GitHub，已经有几十个POC仓库了。有的写得粗糙，直接发一个DNS请求就完事；有的写得精细，连不同JDK版本下的绕过方式都做了适配。我挑了一个stars最多的，clone下来，改了个参数，对着自己搭的测试环境跑了一遍。DNSLog平台立刻收到了回连记录。前后不到五分钟，漏洞确认。

但POC检测有个绕不开的麻烦：误报。你发一个payload，服务器返回200，这算不算漏洞？不一定。可能它只是把你的请求当成了普通字符串，原样存进了数据库。也可能它确实执行了，但执行的结果和你想的不一样。我见过一个POC，检测Struts2的远程命令执行，它发了一个sleep 5的payload，然后看响应时间。如果超过5秒就判定存在漏洞。听起来合理，但问题是——那个接口本身就要跑一个复杂的报表查询，正常响应时间就是6秒。这个POC的误报率是100%。

所以写POC的人，得有点“洁癖”。你得反复问自己：这个回显特征够不够独特？这个时间延迟能不能被其他因素解释？这个DNS请求有没有可能是服务器本身就在做解析？我自己的习惯是，一个POC至少要用三种不同的方式验证同一件事。比如检测命令执行，既要看时间延迟，又要看DNS回连，还要看能不能通过带外通道读到命令的输出。三条都中了，才敢写进报告。

工具方面，现在市面上不缺。Nuclei、Xray、Goby，每个都有自己的POC库。Nuclei的YAML模板写起来最舒服，一个漏洞一个文件，清晰明了。但工具用多了容易产生依赖。有一次我遇到一个站，Nuclei扫了一遍，啥也没报。我不死心，手工把参数挨个试了一遍，在一个不起眼的文件上传接口里发现了一个路径穿越。那个接口的响应永远是200，Nuclei的模板匹配不上任何关键字。工具是死的，人是活的。

说到底，POC漏洞检测这件事，技术含量有，但更多时候拼的是耐心和细心。你得愿意花两个小时去构造一个特殊的请求包，只为了确认一个可能根本不存在的漏洞。也得接受大部分时候你什么也找不到——这很正常。一个SRC项目，扫了三百个域名，最后只确认了两个低危，这才是常态。

那个API网关的SQL注入，最后我写了个POC，用sqlmap的--technique=T参数跑了一遍，确认是时间盲注。朋友问我危害大不大，我说得看数据库权限。他让我继续测，我说打住，POC的活干完了，剩下的你找专业渗透团队。他笑我怂，我说这叫职业边界。

POC是证明题，不是应用题。证明完了，就该交卷。