poc编写

凌晨两点，我盯着屏幕上那个返回401的响应包，咖啡已经凉透。隔壁工位的老张三天前就提交了他的POC，用的是网上抄来的模板，跑通了就发群里炫耀。我偏不。我要自己写一个，哪怕慢。

POC的本质是证明“漏洞存在”，不是证明“你会用工具”。那些直接拿exp改改就交差的人，根本没搞懂自己在验证什么。你复现的可能是漏洞，也可能是巧合——比如目标刚好重启，或者防火墙临时放行了某个IP。真正的POC要能区分这两者。

拿SQL注入举例。最烂的写法是：id=1 and 1=1 返回正常，id=1 and 1=2 报错，然后你宣布存在注入。屁。这只能说明参数没过滤，连闭合方式都没测。我见过有人拿这种POC去交SRC，结果被厂商驳回，理由是“无法稳定复现”——废话，你连数据库类型都没判断，人家一换WAF规则你就抓瞎。

我的习惯是先看响应差异的“指纹”。时间盲注就测三次延迟取平均值，报错注入就看数据库版本特征字段，联合查询必须数清楚列数。写POC不是写作文，每个请求都要有明确目的。你发出去的每个包，都该回答一个具体问题：这个参数是否进入SQL语句？进入后是哪种拼接方式？数据库是MySQL还是PostgreSQL？

但更重要的，是POC的“自证逻辑”。去年我测一个文件上传点，网上所有公开POC都是直接传个phpinfo.php。我试了，确实能解析。可这能证明什么？证明目标服务器配置不当？还是证明你运气好碰上了没开安全模式的PHP？我后来改写了POC，先传一个只包含echo md5('test')的txt文件，再通过包含漏洞去执行它，最后比对输出。这样就算对方删了文件，我也能从日志里确认执行路径。这才叫验证。

别跟我提什么“自动化批量检测”。POC不是扫描器插件。你写一百个请求塞进 nuclei 里跑，那叫撞大运。真正的POC要能在目标环境变化时告诉你“为什么失效”。比如你测的是一个RCE，目标从Apache换成了Nginx，你的POC如果还按老路子发请求，得到的结果只会误导你。好的POC应该包含条件判断——如果响应头里出现nginx版本，就自动切换利用链。这需要你理解漏洞根因，而不是背payload。

我见过最离谱的POC，是某人直接复制了Exploit-DB上的完整exp，只改了目标IP。跑通了，提交了，厂商问“请说明漏洞原理”，他答不上来。后来厂商查了日志，发现他利用的是旧版本漏洞，而目标系统早就打了补丁——他所谓的“成功”其实是exp里自带的延时函数碰巧撞上了网络抖动。那哥们后来被拉黑了。

写POC的过程，本质是逼自己回答三个问题：这个漏洞为什么存在？什么条件下触发？修复后如何绕过？回答不了第三个问题，你的POC就只是截图工具。我每次写完POC都会故意打上补丁再跑一遍，确认它不再生效。如果还能生效，说明我的验证逻辑有漏洞，得重写。

最后说点实在的。别用Python写那种带GUI的“一键POC工具”，没人用那个。命令行加几个参数就够了。也别在POC里写死IP和端口，用变量传递。更别把扫描结果直接打印成红色大字报——输出格式要能解析，方便后续对接其他工具。这些细节没人教你，但甲方看你提交的POC，第一眼就看你代码风格。缩进混乱、变量命名随意、连异常处理都没有的脚本，就算验证成功，对方也会怀疑你测试过程的严谨性。

凌晨四点，我终于把那个时间盲注的POC改成了自适应延迟算法。跑通的那一刻，响应时间稳定在2.3秒到2.5秒之间，对照组在0.1秒内返回。我截了图，附上代码，提交。这次没人能说我的POC是碰运气。